I am using B2C custom policies, to get a third party token and then creating an Azure AD B2C token with that, which contains the claims of the third party. I am using ClaimsEndpoint in the Technical Profile in the policy.
The problem I am facing is, that I need multiple claims, and I can't obtain all of them using a single value of 'ClaimsEndpoint', and I need to specify multiple of those in my policy.
I couldn't find any relevant way to do so. Is there any way of doing that, using Azure AD B2C ?
Related
I am wondering if it is possible to let's say connect the Azure AD with the Azure B2C, in order that the Azure AD users are able to login in my custom policy. I already implemented one, including MFA.
I was reading this article, but I am not sure if it is the right way. If so, I see I have to specify the client-id. What if I have more than one application using this policy, do I have to create a policy for each one?
The linked approach is correct. You specify a clientId which represents AADB2C user-flow/custom-policy as an “Application” to the AAD IdP. So this relationship can be used per AAD B2C user-flow/custom-policy or shared across all your custom policies and user flows.
It can be useful to have separate registrations at AAD so that you could target them individually for conditional access.
This a (mostly) theoretical question from a new B2C user.
If all of the claims I send to the RP are available from an OIDC ClaimsProvider, I seem to be able to create a "pass through" custom policy that doesn't actually require an Azure AD user to exist - token is just created from claims.
Are there any ways in which this will break B2C processing? I haven’t found any during limited testing. Does it pose any long-term headaches for B2C support?
Well, at the very least it is unexpected. And that means you will be on a path where you are mostly on your own.
AFAIK (which is certainly not everything) the benefits you get from B2C, self-service for example, you will not get without having a set of registered users in your B2C tenant. And with that, my question back would be: why not authenticate to that OIDC directly ?
Is It possible to create a multi step sign up custom policy in azure ad b2c ?
I mean I need to capture personal details and verify them against my database if valid? Then second page to create a username and password and store them in azure active directory.
Since I already have a design implemented for these pages I don't want to change this by using ad b2c.
Please help.
Yes, this is possible, see the Wingtip sample for Azure AD B2C custom policies which contains a sign-up or sign-in policy that includes multiple orchestration steps.
You will have to validate the personal details via a REST API.
What are ways to include custom claims (user subscriptions or roles list as example) in a token before issuing it in Azure AD B2C, provided that claims are stored somewhere on own server (not available in B2C)?
Goal to have claims in the token to avoid additional round trip to the storage on every request.
Investigation on the topic brought me to following ways:
Add custom attribute via Graph API, configure to include in JWT. Attribute values should be kept in sync with our datastorage.
Custom Sign-In Policy like in this article https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-rest-api-step-custom but if I got it right, additional Step 6 is a user journey to publicly available API in non restricted way (request not secured by secret, might be used to get user claims by presented UserId)?
IdentityServer4 Federation gateway http://docs.identityserver.io/en/release/topics/federation_gateway.html that will allow to add any claims before issuing.
The first two mechanisms you outlined are the most common and recommended ways to include custom claims in an Azure AD B2C issued token:
Add a custom attribute and include it in the JWT. You can enable the custom attribute via the B2C UI or via the Graph API. You'd need to build your own mechanism to keep the value of this attribute in B2C in sync with your external source via the Graph API.
You can use a custom policy to add a step in your authentication flow to call a Rest API to obtain the claim and include it in the token. This call to the Rest API will be performed by the Azure AD B2C service and NOT the user's browser, so it'll be a service-to-service call (versus a client-to-service call), keeping any secrets you use for authentication with your Rest API safe (such as a Azure function code).
I am trying to cater for a broad set of auth and identity management requirements, homogenizing this area of functionality across different legacy applications, and looking into Azure AD B2C as an option.
It seems as though there may be a need for maintaining contact information on a group. For example, we may need to group users according to their 'reseller,' and we may wish to have additional info about the reseller within Azure AD B2C.
Is this possible in AD B2C?
It is possible to add custom attributes to a group in Azure AD B2C using the same mechanism that's available in regular Azure AD via the Azure AD Graph: Directory schema extensions.
Note that while you can use groups in Azure AD B2C, sending group claims in the token isn't yet supported, so you'll need to make a separate call to the Azure AD Graph to obtain a user's group membership and details about the group. You can always vote for this ask in the Azure AD B2C feedback forum: Get user membership groups in the claims with AD B2C