When working with Custom Policies in Azure AD B2C, you will typically see two kinds of applications being registered:
a web API, often called IdentityExperienceFramework
a native app, often called ProxyIdentityExperienceFramework
To quote from the tutorial on Custom Policies:
Azure AD B2C requires you to register two applications that it uses to sign up and sign in users with local accounts: IdentityExperienceFramework, a web API, and ProxyIdentityExperienceFramework, a native app with delegated permission to the IdentityExperienceFramework app. Your users can sign up with an email address or username and a password to access your tenant-registered applications, which creates a "local account." Local accounts exist only in your Azure AD B2C tenant.
What I have not found yet is a motivation why both applications are needed. All tutorials but also the official documentation skip over it. They only explain the steps for creating and registering the apps, but not their exact purpose.
Questions:
What is the difference between the IdentityExperienceFramework and the ProxyIdentityExperienceFramework?
Why are both applications needed in typical flows (e.g., sign-up/sign-in)?
Are there use cases where Custom Policies require only one of these applications? Or more then these two?
You need both and this is the only option. Services on our side are designed to work using this Native App+Resource app on our end. Also means you don’t need a client secret to be sent as part of the ROPC call that login-noninteractive makes. No, there is no other combination ever used or required.
Related
I'm using Microsoft Graph API to access data from a variety of tenants' ADs. This is with a multitenanted Azure app hosted in my Azure tenancy. Authentication is handled using application level tokens and the client credentials flow; customer admins authorize the collection of data for their tenancy using OAuth. A customer is asking whether it's possible for me to restrict access to my Azure app based on location, so that our app dispenses tokens only to clients who are inside our data center.
It seems to me that this is not going to work. Microsoft recently added the possibility of conditional access based on workload identities; but are pretty clear that this only works for single-tenant apps, where the same tenancy hosts both the enterprise application and the app registration:
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/workload-identity
Note
Policy can be applied to single tenant service principals that have
been registered in your tenant. Third party SaaS and multi-tenanted
apps are out of scope. Managed identities are not covered by policy.
But, I am not an expert and may be working on incorrect assumptions. Can anyone confirm or disconfirm what I have posted here? Is there some way I can provide what the customer is asking for?
As mentioned in the document that it is applicable only to the single tenants, If you want this feature to be available for the mutlti tenants as well you can raise a feature request for same here: https://techcommunity.microsoft.com/t5/microsoft-365-developer-platform/idb-p/Microsoft365DeveloperPlatform
We have a scenario where in mobile app(Xamarin Forms IOS APP) logs into the Azure ADB2C and generate a JWT token if the user is a valid user(user is configured in Azure AD B2C). We have a requirement where in, we need to generate a token based on the role i.e. based on the role with which user logs in, we want to generate a token and that token we are trying to use it in subsequent Web API calls.
Articles which we found out on this particular scenario was having web application as a client where in some mechanism of secrets were explained. In the mobile app client scenario, its not possible to have a secrets.
Followed the below mentioned article, but couldn't get any concrete information also
https://codemilltech.com/adding-authentication-and-authorization-with-azure-ad-b2c/
Any pointers on this particular scenario would be very much helpful to us.
Thanks!
There is no out-of-the-box support for RBAC / Roles in Azure AD B2C. However there are a lot of samples in the official GitHub repository. For example the "Implementing Relying Party Role Based Access Control" by this method you can add the groups to JTW token and also prevent users from sign-in if they aren't members of one of predefined security groups.
I'm looking at the B2C API demos, and API documentation and I'm unable to determine the preferred method for managing authorization.
Azure AD supports assigning AD Users/Groups to apps, and also roles. Seemingly B2C doesn't support this. (I experimented by using AAD tasks against a B2C tenant. Hopefully I did it correctly)
Given that a singular B2C tenant will offer web sign in, and most likely API access as well, what is the benefit of creating more than one scope as exhibited in the TodoList:TodoListScope.
Can I conditionally add additional scopes? Using B2C or store it in the graph/application somewhere?
https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master/4-WebApp-your-API/4-2-B2C
Or more abstractly, how should I perform authorization to the many different APIs (and apps) when an id_token is exchanged for an access_token?
Perhaps API Management will give me ideas on how to perform RBAC or other permissioning. Added them as a tag as well
There is an RBAC Github sample here that requires you to use work accounts which are called "B2C Users" in the portal below.
Users created this way, can be added to groups located within Azure Active Directory (by script). Testing still in progress
We have a simple scenario but technologies(or implementation) have made things bit complex -
We have Sitecore as CMS for client's main web site and for business functionality we have Dynamics 365 Portal and we are using Azure AD B2C as identity provider for both.
We have heavily customised B2C custom policy to cater specific requirements.
We are using same custom policy in Sitecore and in Dynamics 365 Portals so sign in individually and works perfect without any issues.
With regards to SSO, we have kept the configuration as OOTB as you can find it here.
Only 1 or 2 user journeys are absolutely perfect as good as seamless journeys. In specific journeys we need user to be logged in both ends to make it work (we can force user to go to sign in page, but it is not required on all the pages).
In order to understand how real and proper SSO should work in Azure AD B2C, I have no idea or experience to relate this process to. so I am looking for guidance and help here.
I found very good information in this about how B2C works in terms of signin and providing tokens process but it bit old question and things have changed a lot since then specifically UI and some of the operations.
Use the following docs when configuring sessions management for a custom policy. Session Behavior section is where you define which SSO behavior. Specifically:
<SingleSignOn Scope="Application" />
If you want your users to get SSO between all applications, then define this value as "Tenant". There are several useful scenarios in creating separation between sessions - such as a company that has multiple brands that do not want to conflict each other. Or a separation of experiences.
Follow the exact format and location to be placed in your policy or you will not get the desired result.
Another concept that is important is the understanding the session provider:
SSO session management has two parts. The first deals with the user's interactions directly with Azure AD B2C and the other deals with the user's interactions with external parties such as Facebook. Azure AD B2C does not override or bypass SSO sessions that might be held by external parties. Rather the route through Azure AD B2C to get to the external party is “remembered”, avoiding the need to reprompt the user to select their social or enterprise identity provider. The ultimate SSO decision remains with the external party.
Session providers are used to define maintain what goes into generating the session when your policy is being executed (inside the Identity Experience Framework). If marked incorrectly, this could lead to undesirable results such as wrong claims being sent, additional MFA prompts, parts of your policy not being maintained when ran or just general errors.
This is for those who are interested in how we achieved this -
Sitecore also does offer OOTB Azure AD B2C configuration however the supplier of Sitecore delivery side decided not to use OOTB configuration approach and hence it caused lot of issues. From what I have read about Sitecore configuration for Azure AD B2C it does work smoothly with B2C with careful configuration.
Work Around: We had to rely on external triggers(e.g. cookie) which will indicate and trigger that a user has signed on either sides and accordingly the sign in process on both side kicks off.
I have an Azure AD B2C tenant and with that i have implemented sign-in/sign-up flow in multiple applications and all are hosted.
In those applications some premium applications are restricted which means who bought some membership from our portal can only access it but the problem is whoever registered with our other applications (via AD B2C) can able to access the premium applications too.
The B2C tenant allows all users to access all applications. How to restrict some users who not having our membership from accessing premium applications?
Note:
In Azure AD, Enterprise Application option used for Role Based Authorization but i dont see equivalent option in AD B2C.
With built-in user flows you'd probably have to do the check in the app itself. With custom policies, you could implement a validation technical profile to the login flow. But going to custom policies just for that isn't worth it in my opinion.
As juaans mentioned, there is no direct way in built-in user flows. But there is a way which can make it easier. If the membership is stored as a custom attribute, the apps get the membership in a claim in the token. Once you have it in the token, its a very simple check in the authorization layer of the app. I am assuming app will be implementing some authorization for sure.