Identityserver4.admin: Find users by Claim in Admin.API

[b0]

Hi @skoruba

currently it's not possible to find users having some claim by using API.

Let's say i have 200 users having claim "EyeColor":"Blue". Currently you can find them only by getting all 200 users and then asking for claims for every user. That's 200 requests.

I have created PR #475 that solves this issues. Thank you

Best regards

[skoruba]

Hi @b0 - thanks for your PR, I will check it. 👍

[bravecobra]

Is that not a security issue? I don't think that is the responsibility of identityserver. You want an event published whenever someone gets that claim and record that in some other service where you can query it.

[b0]

So, idea is to remove event publishing?

[b0]

I have read your comment again. I don't see any security issue here because the added code is in the API project. To access the API the user already needs to have the Admin role.
Also, as we _now have_ an API for accessing the Resources, Clients, Roles, adding UserClaims etc. over REST it seams ok to have the ability to query those same UserClaims back via REST.
Or there is some other issues? Can you please elaborate? @skoruba

[bravecobra]

@b0 no, with the suggested rest call, you would be able to list users that have a claim. Listing the users is the security issue here. The only other way to list users is in the UsersController. What you suggest here is a further filter on claims. What better tool to give hackers to list out users that are vulnerable to attack because they have a certain claim. We're talking about Identity here, which is a very sensitive subject. We need to be careful about this. If you dig deeper, you find that the searchText only searches in Username and Email in IdentityRepository. Even those are both fields that are considered PersonalData. Remember that GDPR really is an issue to be reckoned with.
My suggestion, if you really need this feature, is to record whenever someone gets a certain claim and store this information behind a service that protects this information securely. Having this feature by default is a security concern that imho we cannot expose to the public.

[b0]

Hi @bravecobra

This data is already available to someone with malicious intent.

The point is that going through the /Users you can get all the user ids. You don't even need to use "search" in that GET request.
After that looping through the /User/{id}/Claims you can get all the users information.

This information is already available to anyone that has access to the API, be it an admin or a hacker.

I am looking for an easier/faster way to get some specific data that is already available to us...

Thank you

[petarkekez]

Hi, we are also having a similar issue and this API would help us.
We are using claims to store user’s tenancy information.

Because the search by claims is missing in the API we are connecting directly to Identity database and querying the user tables.

We would benefit greatly if the search by claims is added to API project.

[bravecobra]

Looking at the source, it would indeed be possible to list all users when leaving the search string empty. Tnx for identifying that security hole! I don't believe we should allow this.

[skoruba]

@bravecobra - the Admin Api is protected, for this endpoint you need have the admin role. If you need list of users, this is valid solution.
What is your idea - how to implement this method if you want to show a list of users in admin ui?

[bravecobra]

I would limit the search criteria at which the GET request would return any results. So either you know the email address or you know at least a partial username (with a minimum of x amount of letters). Empty search criteria should just return an empty collection. Don't consider the GET request as a list of users, but as a collection of search results, so you would need at least some form of search criteria.

Whether the API is protected is irrelevant. Accounts get hacked all the time and OAuth is not full proof. Close but not full proof. Certainly whenever identities of people are concerned, security should be considered paramount! No excuses!

[b0]

Hi,

I may be mistaken but this project is called IdentityServer4.Admin. Admin is short of Administration. So, you can't administer if you can't get to data or if you limit searching and filtering of data.

Even IdentityServer4 has official AdminUI for administering users and you can clearly see on included screenshot of their product list of all users.

Just for reference, here is screenshot of Active Directory administration, all users are listed...

There is no security issues. None.

[skoruba]

Hi guys,
I understand what @bravecobra meant, but I fully agree with @b0 - this endpoint is not security issue. As we discussed, auth0 has similar endpoint as well - https://auth0.com/docs/api/management/v2#!/Users/get_users

[bravecobra]

Sure, no problem then. I just wanted to point out that adding extra functionality should always be paired with the security consequence. The fact that we had the discussion and came to a conclusion, means we did consider the implication and that is the most important part.