I have an Azure AD Tenant that is federated with ADFS.
ADFS has an attribute called "employeeNumber".
When a user authenticates against AAD for accessing our custom Web API, i would like the jwt provided by AAD to contain the claim "employeeNumber".
Once the user is authenticated against the custom Web API, the code must check the presence of this claim and its related value.
I've found some tutorials for doing something like this but they refers to SaaS applications.
Attribute sync tutorial
Custom applications registered in AAD don't have the option "provisioning" that the above link refers to.
Thank you.
Are you using AAD Connect?
That needs to be configured to pass the attribute.
Then you need to tell Azure AD to pass the attribute by modifying the manifest.
Related
How do I use Azure B2C with Entity Framework, or any other back-end system?
The documentation for Azure B2C does not seem to discuss integration with back-end systems, and I'm at a loss as to how this is achieved.
I do not need the user to authenticate against the database, but I want to store user-specific data in the database. This could entail the use of a Users table, for example.
The design of the DB is up to you.
The normal way is to add the DB primary key of the user as an extension attribute for the user in B2C.
When the user logs in, get the extension attribute and pass it to an API that handles all the DB activity.
See MS documentation Use API connectors to customize and extend sign-up user flows and custom policies with external identity data sources
you can verify that the email address provided by the user exists in
your customer's database, and if not, present an error.
Your RESTful service can receive the user's email address, query the
customer's database, and return the user's loyalty number to Azure AD
B2C
You can use an example
A B2C IEF Custom Policy which authenticates to AAD and calls a REST API for more claims
Azure.Containers.ContainerRegistry.ContainerRegistryClientOptions has a parameter credentials that accepts any TokenCredential instance. There is a long list of options available, but all lead to actual Azure AD credentials. Even the username/password type is actually the username/password of an Azure AD user
Is there a way to provide the user/password combo one would use when using the (in preview) feature of ACR scoped tokens (which is effectively "users for ACR"), or is this SDK only intended for apps that have a managed identity? For username/password API access, would we then need to user a .NET SDK around the Docker API?
thanks in advance
We are using azure ad as an idp for authentication, We want to add additional attributes like roles etc. to the access token. These additional attributes are coming from existing application.
What is the correct way to get these attributes from existing system and add to the access token?
You can build your own custom claim mapper as presented in here. Which reads the custom claims from the application and adds them to the token.
Alternatively, you can also use script mappers. Finally, you can also have a look at UMA flow and use the feature of pushing claims.
My project is a MVC Core 3.1 web application.
The autentication is based on the Microsoft.identity.web template to sign-in users in Azure AD B2C.
You can find the samples here: https://github.com/AzureAD/microsoft-identity-web/wiki#samples
Users can register/login as standard users on B2C or login with the corporate account (azure AD, so an openID Connect Identity Provider).
When Users signs in with the corporate account, I get a JWT token with a claim named "idp_access_token" which contains the access_token from Azure AD. It contains some claims I need for the application (for some reasons I can't even see the emailAddress/unique_name in the B2C token so I need to get it from here...).
But I'm not sure how (and where) I'm supposed to deal with this token and how to access the claims inside it. Can I map them in the claimPrincipal? Because I would like to use the email as the "User.identity.name".
Should I write a service (transient?) and Inject it where I need it?
Sounds like you are using a feature you don’t actually need. Usually the embedded IdP access token is used to call the services that the IdP hosts. For example, a user logs in with Facebook and your app wants to call the Facebook API to post to their Facebook wall.
You as the app developer should not inspect or use the token for your own self, as you cannot trust it. If you want data from that token, then perform the relevant claims mappings in your B2C policy/user flow, as B2C does validate the token and can trust it. You cannot. Services provided by the IdP will verify it, so also can trust it.
What are best practices for maintaining roles (e.g., a user-provisioning role) in a Web application that uses OAuth 2.0 authentication against a Google App domain? These are roles that are tied to a specific Web application, rather than to the domain as a whole.
Is role management at the application level typically done using the application's backend database, once the OAuth Web flow authorization has been completed? I was thinking of using a Google App group to stand in for each role and then verify membership in the group using the Directory API before allowing an action to be carried out. Is this a suitable approach? This requires either a service account with a group-membership privilege or the assigning of such a privilege to each user in the domain with that role, which are steps that would be nice to avoid.
Is there an API to read information about Google App's native domain-level roles for this? Should custom properties on the user's profile be used? If the latter, is there a straightforward way for a domain admin to set these up when provisioning a new user in the domain, or will a separate UI need to be built out? I've noticed that in the user profile information there is a isDelegatedAdmin field, but that field is a boolean, and I have not found anything with more granular information on the roles delegated to the user account.