I'm trying to build functionality into my app for 'admins' to assign users from their AD group to certain groups that are further assigned to app-specific roles. Basically a simple management component.
Adding the user with the oid to a group is easy, the problem I'm facing is finding the actual user.
Currently, the only option I'm seeing is making multiple api requests to v1.0/users (999 items max) and grouping them all in memory and then provide a simple search function to narrow it down.
I have also used the v1.0/me/people endpoint to search for users but this does not reveal all users from the AD group, just relevant users they deal with, so not too useful.
Is there any other api endpoint I could tap into to do a search ONLY on members of the same active directory?
Using the startsWith filter on multiple properties is probably the closest we can get to user search in MS Graph at the moment:
https://graph.microsoft.com/v1.0/users?$filter=startswith(displayName,'sarah') or startswith(givenName,'sarah') or startswith(surname,'sarah') or startswith(mail,'sarah') or startswith(userPrincipalName,'sarah')
Ended up switching to the old AD Graph API and implementing a query on the endpoint as follows:
https://graph.windows.net/{ tenant ID }/users?api-version=1.6&$select=mail,displayName,objectId,givenName,surname&$filter=startswith(givenName,'SEARCH TERM') or startswith(surname,'SEARCH TERM')
If a function receives 1 single param, it will search for that parameter in both givenName and surname but you could configure this to search accross any other supported fields.
You could also completely ditch the $select= completely to get the whole data. I didn't want the clutter though and those keys are enough for me.
Instead of going with startswith You may get better experience using search keyword:
https://learn.microsoft.com/en-us/graph/api/user-list?view=graph-rest-1.0&tabs=http#example-6-use-search-to-get-users-with-display-names-that-contain-the-letters-wa-including-a-count-of-returned-objects
Related
I'm trying to get the preferred username of a user via the Graph API for Microsoft Office / Azure
If a user logs in via an enterprise application with an id_token I get the preferred_username claim.
This has the user's actual email address.
If I try to look up the user separately by ID, I can't find any way to get that username.
Seems related to Sign-in to Azure Active Directory using email as an alternate login ID (preview).
The user in question is using a GitHub linked account, it likely has an ugly UPN that I would prefer not to be seen anywhere. Instead I would like to use their preferred_username.
Example "ugly" UPN":
***_gmail.com#EXT##***gmail.onmicrosoft.com
To my knowledge, the preferred_username value isn't exposed by Graph in either v1.0 or Beta.
One potential workaround is to use the otherMails property. This is an array, so this may contain multiple entries for a given user. That said, any otherMails entry is likely to be less 'ugly'.
I have asked this question on ASP.Net Core github repo, but I do not think my query was sufficiently answered, so posting the question here.
I followed the instructions here to get a user's AD groups as claims. However, the user is member of a large number of groups, and I just see a single claim "hasGroups".
My question is: what is the suggested best practice/pattern to follow in such cases, as I am interested in retrieving only a few of the user's groups that match a string pattern. Where would I even write the code to perform this filter?
I know how to code the graph api query, but where/when exactly to make this call is unclear. And once I retrieve the groups from Graph Api, how do I reflect the group information into the token claims, so the client app can use regular Authorization mechanism, without knowing the details of how the user's groups were populated.
I'm not sure if this is the recommended way of doing it, but the docs here talk about adding groups and roles to use the user object claims for blazor. https://learn.microsoft.com/en-us/aspnet/core/security/blazor/webassembly/azure-active-directory-groups-and-roles?view=aspnetcore-3.1
I'm not sure if it's even possible, but in the customuserfactory, I would try to replace the
foreach (var group in account.Groups)
{
userIdentity.AddClaim(new Claim("group", group));
}
with some code to try to call the graph api (somehow get the token to call the api with, that's the part I'm not sure on), parse the groups and add them to the user claims,
then follow the rest of the example of how to incorporate that into the [authorize] mechanism.
again, I'm not super familiar with blazor wasm yet, and I couldn't find any docs other than this to add groups/roles into the authorization mechanism.
if anyone else has a better method of doing it or why this wouldn't work feel free to chime in, but I hope that this can at least give you some ideas and is slightly useful.
I am using the Graph API (beta) and getting a list of all users from /users. As expected, this returns a list of all users including service accounts and conference rooms. Is there any reliable way I can filter only human employees out from this list?
I've tried using the properties "assignedPlans" and "assignedLicenses" to try and pinpoint human users, but it doesn't work perfectly.
It seems that there are no such a property that well distinguishes human and other user type.
If you want to distinguishes room account, you can refer to this Microsoft Graph API: findRooms to get the room accounts and exclude them from your initial user list.
BTW, what do you mean by "service accounts"?
I'm trying to sync users/groups that sit behind Okta in Active Directory. Specifically, I'd like to get all groups a user belongs to, upon login to a third party application.
Looking at the Okta API documentation (http://developer.okta.com/docs/api/resources/groups.html) I see that I could accomplish this by performing the following operations (in pseudo-code):
FETCH ALL GROUPS (using List Groups operation)
FOR EACH GROUP
FETCH A LIST OF USERS (using List Group Members operation)
For my purposes this seems very inefficient, but I can't find a better way of doing this by looking at the documentation.
Ideally, what I would like to do is:
FETCH ALL GROUPS FOR A GIVEN USER ID
Is there any way I could accomplish this ?
Any help is appreciated. Thanks.
I found the answer: the Get Member Groups API call does this exact thing. It's under Related Resources here: http://developer.okta.com/docs/api/resources/users.html
https://developer.okta.com/docs/reference/api/users/#get-user-s-groups how about that?
[GET] /api/v1/users/$userid/groups
It's also possible to get this list when the user logs in into an app via SAML.
Add a Group Attribute Statement with filter Matches regex and value .*.
You will get the user's groups as part of the XML.
I need to add full-text search capabilities to my existing database. Of course first turn is to something like Solr or Elastic Search. And the blocking point I’ve got to is – how to securely display results returned from underlying search engine (let’s think about Solr or Elastic Search for now, however any other solution or engine that hit the point are also appreciated).
The tricky context is that I have, for example, in my system Personal Profile records that are to be indexed. One of the fields in personal profile is – manager’s feedback. Normally in the system that field is visible only to employee’s direct manager and higher hierarchy, i.e. ‘manager’ from another branch will not be able to see that field. However, I want that field to be searchable via full text search but only for people who actually can see it.
Now I query Solr for ‘stupid’ (that is query string) and it returns me N documents. When returning that to end-user I’ll remove the ‘Manager’s feedback’ field because end-user is not the manager of given people – but just presence of the document in resultset is already the evidence of ‘stupid’ guys …
The question is – what is workable approach to handle that use-case? Is it possible to plug into Solr/ES with home-grown security filter for outputs?
Caveats:
filtering out only fields do not work because of above mentioned scenario
filtering out complete documents will not work because of
search engine does not tell which fields matched – therefore no way to manually filter resultset by field http://elasticsearch-users.115913.n3.nabble.com/Best-way-to-return-which-field-matched-td2713071.html
even this does work, removing documents from result set will spoil down facets (e.g. number of matches by department) returned by the engine – I’ll have to either recalculate facets manually or they will not match to manually filtered records and will reveal what I actually do not want to show to end users
In Solr you can create multiValued fields. In your case you can use it to store de-normalized values of organization structure.
In described scenario you will create multi valued field ouId (Organization Unit Id) and store employee's ouId and all parent ouIds. In other words you will save allowed ouIds into this field.
In search scenario you will use FilterQuery - fq parameter filtering by ouId of manager.
Example:
..&fq=ouId:12
where 12 is organization unit id of selected manager.
Maybe this is helpful for you https://github.com/salyh/elasticsearch-security-plugin It adds Document level security to elasticsearch.
"Currently for user based authentication and authorization Kerberos/SPNEGO and NTLM are supported through 3rd party library waffle (only on windows servers). For UNIX servers Kerberos/SPNEGO is supported through tomcat build in SPNEGO Valve (Works with any Kerberos implementation. For authorization either Active Directory and generic LDAP is supported). PKI/SSL client certificate authentication is also supported (CLIENT-CERT method). SSL/TLS is also supported without client authentication.
You can use this plugin also without Kerberos/NTLM/PKI but then only host based authentication is available.
As of now two security modules are implemented:
Actionpathfilter: Restrict actions against Elasticsearch on a coarse-grained level like who is allowed to to READ, WRITE or even ADMIN rest api calls
Document level security (dls): Restrict actions on document level like who is allowed to query for which fields within a document"