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
Related
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.
I have 1 SPA-Application which uses another WebApi. (ASP.NET Core) Both are running in Azure and I am able to authenticate the user against Azure AD B2C with OAuth 2.0 Implicit Flow
Now I am asking myself how I can control the permissions of a single user. (Delete, Read, etc.) Do I have to work with claims? Do I have to leverage the graph API on the server side to check if a user has a certain permission? Can I use scopes? Where can I set the User <--> Scope relationship?
I have found several questions on SO, but I don't get the idea of how it should be done the right way? My current understanding is that I ask the authentication provider for certain scopes and I will get a token with this scopes which then can be checked by the API. But how do I manage which user can ask for which scopes?
I really have a problem to wrap my head around OAuth2 and permissions. Hope one can help me here.
Unfortunately, for one specific user, you cannot assign permissions/scopes to the user.
Because Azure AD B2C doesn't support Application Role. Generally, Azure AD B2C is for all users to access your App wit their account. Even Azure AD B2C can let you store and manage users, but it cannot assign different scopes/permissions to different users. Multiple scopes are the permissions granted to the resource. Multiple granted permissions will be separated by space.It's not for users access assignment.
If this important to you, you can upvote this idea in this Uservoice Page. Azure Team will review it.
Hope this helps!
You can implement this by creating a custom attribute of type String that stores a comma- or space-separated list of roles for a user.
You can then issue this custom attribute in the ID and access tokens or read it using the Azure AD Graph API.
We are trying to integrate Azure AD B2C into a SPA. We want to include Roles in the ticket so that we can use AuthorizeRoles & IsInRole in the api. We have looked at a couple of examples.
Example 1
Example 2
The first example isn't a SPA and doesn't include roles. It is accepted that including membership & groups in the ticket using Azure AD B2C isn't supported as per below link.
Azure AD B2C Group Membership Feature Feedback
The workaround as suggested above seems to be to use the "OnAuthorizationCodeReceived" event as per below to inject/add your own Role claims to the ticket.
Workaround
The issue we have is that we are using a SPA so we need to follow example 2, we also need to be able to add our own manged roles into the ticket which isn't a supported feature but Microsoft have said there is a workaround as shown. The workaround however doesn't work with MSAL.js as in example 2.
How can we include our own managed Roles into the ticket using the MSAL.js library so we can integrate Azure AD B2C into our SPA enabling us to use AuthorizeRoles & IsInRole in the api?
A few things first, you mentioned you are using the MSAL.js library and this means the v2 endpoint. Currently (as of 05/16/2018), the v2 endpoint has limitations on roles and groups, see v2 limitations where it states:
The v2.0 endpoint does not support issuing role or group claims in ID tokens.
ID tokens are used in the implicit flow with the v2 endpoint, see here Azure AD v2 Spa Guided Setup and read about half way down under More Information
Bottom line is to be absolutely sure the v2 endpoint (and MSAL libraries) can support your requirements.
For myself, we ended up going with the v1 endpoint and ADAL libraries in part because of limitations like this. But here are some examples of using roles in code. Note that these repos are fairly new and I'm still building out the documentation. There are two repos, one an stand alone angularjs ui project and another is a set of APIs (they are demos I used at a codecamp presentation). Read on below about roles in AAD. Only the UI example uses the ADAL libraries (note: the ADAL and MSAL libraries are about managing the tokens in the clients and are not the libraries used for locking down the back ends).
APIs: https://github.com/BgRva/aad_adal_api_dn_std/tree/Step_C
UI: https://github.com/BgRva/aad_adal_ui_ng_js/tree/Step_C
Some notes about Roles in AAD:
Roles are application specific, so in the examples above, the same
roles have to be registered for all the applications that will use
them (this includes the role Id as well)
You can give multiple roles to a user in AAD, you just need to add them multiple times to that application with a different role selected.
Manually adding users to roles will not scale and requires lots of clicks in the portal. It can be easier managed with groups but only at the AAD Premium Level 2 do you get this benefit
Supposedly there is a way to programmatically add roles but I have not found anything about it
Cheers
We want to create a MVC web application using claims-based authentication, expecting roles as one of the claims. We want to Federate authentication providers using the Azure Access Control Service to manage this federation. One of the authentication providers is our Azure AD.
The problem is that Azure AD doesn't seem to be able to generate role (or even group) claims. What is the appropriate method to manage group or role access in Azure AD and have role claims served by Azure Access Control Service.
Thanks.
Edit:
A previous comment asked for details: We want to provide access to our cloud application to 3rd parties using their active directory (to simplify user management for them). Our application has a few levels of access to information that the 3rd parties can configure. We were hoping they could do this in their AD (based on our instructions). Groups seemed like the obvious choice, but if there is another way that works, as long as we can provide instructions, it'll work.
We want our application to get claims for a user's level of access. If we had only one partner that was using Azure AD, we could use the graph API against that endpoint, but with multiple partners changing over time, we wanted to federate them so our application only needs to trust the federation server. We were assuming that we needed Azure ACS to manage the federation.
AAD does support roles / groups and you can administer them from the Azure Portal.
Howeve, these are not passed in the "canned" set of claims.
You need to use the Graph API and then convert them e.g. Windows Azure Active Directory: Converting group memberships to role claims.
Update:
ACS requires something to federate with. You can't hook a customer AD up to ACS - you need something like ADFS on top of their AD.
I assume your cloud app. runs in Azure?
Then make your app. multi-tenanted. If your customers have their own Azure tenant, it will work. You just need to add the Graph API code to your app. ACS is not required.
Your customers then run DirSync. This keeps their Azure tenant in sync. with their AD changes.
So two options:
Customer does not have Azure tenant. They install ADFS and federate with AAD.
Customer's who do have Azure tenant use DirSync.
Good news: we have recently turned on the Application Roles and Groups Claim features in Azure AD.
Get a quick overview here: http://blogs.technet.com/b/ad/archive/2014/12/18/azure-active-directory-now-with-group-claims-and-application-roles.aspx
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/roles-based-access-control-in-cloud-applications-using-azure-ad/
Deep dive post and video on app roles feature is here: http://www.dushyantgill.com/blog/2014/12/10/authorization-cloud-applications-using-ad-groups/
Hope that helps.
Groups aren't the best choice because they are unique within each directory. Unless you get your customers to define a set of groups that have well-known names and match against the strings, that is (the object IDs of a group is different per directory even if they have the same name). I'm actually from the Azure AD team and we are seriously considering releasing a feature to allow you to define roles in your app that your customers can assign their users to. Please stay tuned on this. In the meantime, unfortunately groups are the only way to go. You would have to call "GetMemberGroups" using the Graph to retrieve the groups that the user is assigned to.
What are your timelines for releasing this application? You can contact me directly to see if we can work with your scenario.