Using OpenAM's REST API, i'm trying to get a realm on which a user is created. User attributes that are retrieved using /identity/attributes service don't retrive the user realm.
Is there a way to get a realm on which a user is created using OpenAM rest API?
I'm using OpenAM v13.
Users are not really "created" in a specific realm as OpenAM is not the owner of identity information but consumes identity information from configured user data stores.
So an OpenAM user identity object actually "belongs" to a realm.
The '/identity/' REST endpoints are deprecated and you should use the new REST services https://backstage.forgerock.com/docs/openam/13/dev-guide/chap-client-dev#rest-api-crud-identity
If you use https://backstage.forgerock.com/docs/openam/13/dev-guide/chap-client-dev#rest-api-read-identity and you get a successful response you can be sure the user identity belongs to the given realm.
Related
From the documentation it seems that using an application that is in the B2C tenant and thus hosts user accounts that there is no way to directly access Microsoft Graph API via a logged in user per their own context.
I want to establish the use case properly so that the solution is that which makes the most sense.
The use case is that if a user wants to edit claims for example such as permissions they would be able to do so while logged in through Azure B2C.
The flow would be. Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)
Is the proper way to do this is to build a proxy that will take the application's AD application permissions which are allowed to call out to Microsoft Graph and pass along user context so that the scope will be limited to that user only?
For example. User logs into the app.
The app has AD permissions that are granted admin consent
Create a client secret to prove application identity upon request of a token
Now can access Microsoft Graph api
Ref of Registering an app with Microsoft Graph api
What's not clear here exactly is the next part. My user is logged in with Azure B2C. Should I just pass along their id token which has their claims to the application? How do I put in scope/context of the logged in user of the app permissioned access to Microsoft Graph?
This part is not clear in any documentation.
I don't want a logged in user to have access to everything.
Is a proxy the only way to do this?
If a proxy is the only way to do this what identifier or id is what should be used to pass along to the query to assure only that user is in context?
Am I thinking of this incorrectly and or is there a better way to do this other than a proxy?
The documentation says this.
Apps that have a signed-in user but also call Microsoft Graph with their own identity. For example, to use functionality that requires more elevated privileges than the user has.
That doesn't fit exactly into my use case above or address it really but I think it is related. The functionality should be considered to be an elevated permission but to the scope of the user. This user can change this claim via their own logged in entity. What do you call that and what is the best way to solution this?
Lastly, is there anything that should be known in the MSAL library including Angular and React that would be useful in this process? It seems like I will have to converge the 2 to obtain the access token of the app and of the person and proxy those out to a backend service (the proxy) to then do a body of work.
Am I thinking of this correctly?
This Stack is the closest to relevance but doesn't ask or solution the entire use case as I have here. But is useful for illustrating the confusion.
"Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)"
Why can't you use the Profile Edit user flow? You can configure what attributes the user can change.
I have developed web application (Python/Django) for my client and he wants me to add SSO via Azure Active Directory that he setup. Also I need to fetch user profile information (email, upn) and update it when it changes in AD.
I managed to get SSO working using MSAL with auth code flow and able to send requests to Graph API on behalf of user to get profile information (/me).
To get profile updates I created subscription (webhook) to /users resource using app identity (client credentials grant flow).
The problem is that I can't understand how to correlate users I get from subscriptions with users I get from auth code flow via MSAL. Notifications from subscriptions give me ids i can find on azure portal (GUID), but profile information requests on behalf of user dont give me same ids. There are ids, but these ids are differenet (something like c66b9ba73bcba166)
As juunas mentioned, the object id is typically oid or sub.
Example using jwt.ms to examine the ID token:
Also, if your app needs to distinguish between app-only access tokens and access tokens for users, you can use use the idtyp optional claim.
I'm building a web app (SPA) that is a case management system. Each user (mainly external to organisation) has a case on the system. I've been told by an architect we should be able to use Azure AD B2C to allow the users to login on this so I've been investigating this.
From what I can see I will get a token back from B2C saying the user is authenticated. What I don't understand is what use is that? Ok the user is authenticated but I have no idea who they are i.e. I will need to identify their case ref somehow so I can bring back their details...
If i was doing this in the old days when they login they'd be checked against a user table then their ID would be used to get their case details .. a token and data object would be returned from an api.. job done
I don't see how this would work in Azure AD B2C... am i missing something?
The JWT that is returned contains a configurable set of claims.
You can use these to identify the user. Typically, this would be email or UPN.
In your case, you need a userID. If this isn't one of the supported attributes, you can use an extension attribute to store it.
B2C can also call an API (if you use custom policies) so you could call an API to get the userID from e.g. a table and then return it as an extension attribute in the JWT.
I have a multiple applications that use the same custom policy to authenticate user. In TrustFrameworkExtensions I defined two claims provider, one for local account and one for user of my company AD tenant (social account) , I have also a claims provider for retrieve custom attributes and for check if the user is enabled for the caller application, this claims provider is configured in user jorney like a orchestration step before the JWT token is created.
The API Application return claims with custom attributes if the user is enabled and return a response with HttpStatusCode.Conflict and error message if not.
How can show the error message in the login form before it back to the calling application?
PS: I have a custom UI login form
UPDATE
I found a right technical profile "SelfAsserted-LocalAccountSignin" and now works ! But I have 2 more questions.
1. In my api application, in input claims, extension property are missing , I think it's because the user not logged yet, is it possible obtain all claims ? If this isn't possibile I must read data in my api with Graph
by signinName.
2. My login form allows authentication as a local user and as a user of my company AD tenant (social account).
The ValidationTechnicalProfiles in "SelfAsserted-LocalAccountSignin"
works with local user only, I tried to configure a ValidationTechnicalProfiles for "SM-SocialLogin" TechnicalProfile but doesn't work
I have developed a Web API, hosted in Azure, with OAuth 2.0 Authorization grant thru Azure AD. I have the token system working, I am able to request an authorization code, and use that to request access/refresh token, and then request data from the API in general.
The next thing I am struggling with is how do I allow user A to access Database A data and user B to access Database B data. We have different databases and each user has their own private data. Both user A and B are using the same native "client" desktop application. So here is my thought process:
We could make user A its own "application" in Azure AD, and user B its own "application" in Azure AD. They would have different access tokens then. But how do I know in my Web API that user A is calling my API, or user B is calling my API if Azure AD is the one doing the authorization? is there a way to extract which particular user is calling the API from which token is used or something, so I can pull data for only that user? All I have currently is the [Authorize] at the top of the ApiController for the different REST calls and then setting up the application in Azure AD, but that is just general authorization access to the API, not specific permission/authenticated access to private user data.
I assume that you are using OWIN/Katana with JWT support for authorization. If so, then you should find that if you get the ClaimsPrincipal.Current property there will be a ClaimsPrincipal object that represents the user that was authenticated. It will contain a set of claims that are returned from AzureAD. You can use those claims to retrieve an identifier for the user and map that to their associated database.
Take a look at the sample here:
https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet
In particular this file:
https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet/blob/master/TodoListService/Controllers/TodoListController.cs
line 80:
// A user's To Do list is keyed off of the NameIdentifier claim, which contains an immutable, unique identifier for the user.
Claim subject = ClaimsPrincipal.Current.FindFirst(ClaimTypes.NameIdentifier);
After this code the subject.Value property will contain an identifier for the authenticated user.
This link contains some documentation on the set of claims that Azure AD will return:
http://msdn.microsoft.com/en-us/library/azure/dn151790.aspx
Search for "Azure AD issues a fixed set of claims for the authenticated users."