As an example, I have added an Azure AD external identity provider to Azure B2C using OpenIDConnect.
I am interested in accessing claims from the external identity provider (Azure AD) that aren't present in the ID Token Azure B2C returns to my app. For instance, I know that there is an amr claim from the external identity provider. If I configure Azure B2C to pass thru the Access Token obtained from the external IDP like this:
<OutputClaim ClaimTypeReferenceId="identityProviderAccessToken" PartnerClaimType="{oauth2:access_token}" />
Then my application can see the Access Token, and if I decode it, I can see the claims I'm looking for are present.
However, I want to process these claims within Azure B2C to change it's behavior based on these claims. For instance, I would like to look at the amr claim and determine if multi-factor authentication should be enforced or not.
Is there any mechanism through which Azure B2C can handle the claims that are returned in the Access Token from the external identity provider? Some type of syntax that references a claim in the Access Token that Azure B2C retrieves from the IDP? The closest thing I can find might be to change from OpenIdConnect protocol to Oauth2 protocol in the claimsprovider configuration. But, I've seen mixed messages about this.
Related
I am working in a project where we are authenticating any REST API requests from UI or anywhere else using ADFS STS tokens. There are some direct calls from UI with ADFS STS token in header for authentication/authorization and there are some external 3rd party calls not from UI, but also using ADFS STS tokens in header. Now we are planning to migrate partially to Azure AD token, post which there may still be some applications that will keep using ADFS STS tokens, so there can be situation where an external application that is unaware of migration to Azure may still call an internal application using ADFS STS Token and we are supposed to be compatible with it. Similarly there can be a situation that an internal application that is migrated to Azure AD token is internally calling one of the legacy applications which is still not migrated to Azure AD and won't in future too.
I have two challenges now:
How to support the above design so that even if an Azure token is used the API is still able to call an external service (working on ADFS) by creating an ADFS token from within the code and setting it in headers ?
Header in a HTTP request seems to be an unmodifiable data and when i tried to modify it within a requesttemplate in an request interceptor code, it failed saying unmodifiable map.
How do I handle this ? Please someone help.
Unfortunately I cannot share code due to internal restrictions.
Please check if below references provide some idea in your case.
According to Mix ADFS and Azure AD for authentication - Microsoft Q&A.
If you have O365 federated with ADFS and you federate an application
with Azure AD, the authentication flow would be:
User accesses the application which is federated to Azure AD.
Application will redirect to Azure AD authentication endpoint (https://login.microsoftonline.com) for authentication.
User will be prompted for credentials.
Based on the UPN suffix (If the domain is federated with ADFS), user will be redirected to ADFS.
ADFS will authenticate the user and issue a WS-Fed token to Azure AD.
Azure AD will receive the token and issue a SAML token to the application.
User will finally get access to application.
References:
Configure AD FS 2016 and Azure MFA | Microsoft Docs
Azure AD Connect - Manage AD FS trust with Azure AD using Azure AD
Connect | Microsoft Docs
federating ADFS with Azure Active Directory (techdirectarchive.com) & reference- Solution Zone
I need help integrating Azure AD B2C and Google APIs. Briefly, I created a tenant on Azure AD B2C, policies and a Native App. Users can register to my app and sign in without any problems. Now I need to use Google APIs to access the logged-in account's information and manage some information (Google MyBusiness data). How can I achieve that. Is that possible ?
Furthermore, even if that is not connected to Azure AD B2C, how can I request to the user to accept that my app to view MyBusiness data?
UPDATE: I understand that I need to authorize my app to https://www.googleapis.com/auth/plus.business.manage Google scopes. Is it possible to request that scope during Google SignIn application authorization process?
Thanks everyone.
As part of the authentication exchange between Azure AD B2C and Google (as well as other identity providers), an access token is issued by Google for use by (and only by) Azure AD B2C, where this access token is used by Azure AD B2C to access the authorized information for the authenticated end-user.
Currently, Azure AD B2C does not pass this access token through to the relying party application (i.e. your native client application), therefore applications can't access the information for the end-user.
UPDATE on 20 June 2019
Using a custom policy, you can pass the access token from the external identity provider through Azure AD B2C to your relying party application.
From the official Azure AD B2C FAQ:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-faqs
Can I configure scopes to gather more information about consumers from various social identity providers?
No, but this feature is on our roadmap. The default scopes used for our supported set of social identity providers are:
Facebook: email
Google+: email
Microsoft account: openid email profile
Amazon: profile
LinkedIn: r_emailaddress, r_basicprofile
I have an ASP.NET Core Web API app and to secure it, I've implemented JWT Bearer authentication. The next step is managing user access and issuingJWT token.
Initially I considered using Azure AD B2C but it doesn't seem to support my business requirements. So I'm now considering using Identity Server 4.
Is Identity Server 4 run as a completely separate application? Also, am I understanding it correctly that it is used as:
A web interface for users to register and login
Also a web app with API that issues the JWT token
In other words, does Identity Server 4 "act" as my own Azure AD B2C service?
IdentityServer 4 is a Web app (Login & Logout pages) with an API that implements the OAuth 2.0 and OpenID Connect specifications. The samples provide a simple user login and logout views that you can change to your liking.
Regarding the user registration process, you may add that to your IdentityServer4 implementation or have that as a separate web application.
Similarities to Azure AD B2C
This came from another blog article
Authorization
Azure AD B2C allows you to model user roles as membership in groups
that you define. You can’t currently get a token containing those
claims, but you can use the Azure AD Graph API as a workaround to
retrieve the group memberships, and use them in authorization checks
inside your application. It’s a little tricky right now, but
improvements to this are on the B2C team’s roadmap.
API Authentication
Azure AD B2C can provide tokens for authenticating API access via
OpenID Connect, but beyond that the functionality is limited. The
OAuth 2.0 Client Credentials flow isn’t supported, and B2C doesn’t
include any API key management features, so you’ll need to roll your
own code if your services need to support API key authentication.
Another article with PROS for IdentityServer4.
IdentityServer 4 is an authentication framework capable of out of the
box Single Sign On (SSO) and security for your APIs, and most recently
support for implementing your own authentication protocols and tokens,
with a sample implementation for the WS-Federation protocol and SAML
tokens. SSO works across all applications regardless of whether they
are using OpenID Connect or WS-Federation.
Summary
IdentityServer4 is similar to Azure AD B2C with more functionality as noted in the linked articles.
I tried using the code provided here: https://github.com/Azure-Samples/active-directory-javascript-singlepageapp-dotnet-webapi-v2
It works for both MSA and Azure AD authentication. I need to know whether the email address entered was MSA or Azure AD. Is there a way to find that out from the response?
In the id_token you get back, there's a iss (issuer) claim.
This claim contains the user's tenant.
If the user used a Microsoft Account (MSA), their issuer claims will contain the following GUID for the MSA tenant: 9188040d-6c67-4c5b-b112-36a304b66dad
The full value of the issuer will be:
https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0
Any other GUID indicates that the user signed in using Azure AD and the GUID value will represent their Azure AD tenant.
For more information check out the id_token section of the Token Reference documentation.
We are currently using Azure Access Control Services (***.accesscontrol.windows.net) to allow customers with personally-managed Microsoft Accounts (Identity Provider) to sign in to our customer self-service portals (Relying Party Applications), which are Angular apps powered by Web API services. In our Access Control Services we are currently passing through the nameidentifier http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier claim from Windows Live ID to the relying party APIs, which match that token to an identity in our applications.
We are looking to support both Enterprise and Personal Microsoft Accounts with the Azure AD v2.0 service, but do not understand how to migrate our existing users to the new system. The code examples suggest that the OWIN middleware returns the NameIdentifier claim from the user's Identity Provider, but if that Identity Provider is the same Microsoft Account (aka Windows Live ID), will that be the same NameIdentifier we are currently receiving via Access Control Services pass-through?
Any help and/or documentation that clarifies how this transition is intended to work would be appreciated.
If the nameidentifier coming out of ACS is the randomly generated value then you're kind of stuck because that value is unique to the ACS/RP/User. If it's returning the actual Live ID then it'll obviously only match if the Azure AD user has the same email address.
I don't know if any documentation out there that describes how to handle this situation. My recommendation is to just require a one-time authentication from each source within the same session and marry the two results. That would basically mean
authenticate to Azure AD
Your app: Hey you don't have any user details, do you want to associate a Live ID?
Authenticate Live ID
Associate Live ID with Azure AD
Then if they want to sign in with either accounts in the future you have a link between the two.