I'm struggling to figure out a way to hook into the authentication/authorization/token issuance process.
I want to be able to authenticate users, as well as prevent users that are banned from logging in.
I want things to work this way:
Upon providing their username + password, users get logged in if the credentials are valid
If the credentials are valid, we do an additional check as to whether the users are banned or not (by checking their username in a custom database)
If the user is banned, deny login
I want to know whether Azure AD or Azure AD B2C supports this ability to hook into its processes, and if so, where can I find more about it? documentation? sample code? etc...
Thanks,
This is easily attainable by using the Identity Trust Framework, also known as Custom Policies.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-trust-frameworks
You can then use a REST API Technical Profile and use conditions within your User Journey that will allow your flow to occur as you have indicated.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/restful-technical-profile
I would also encourage you to review these samples from the Community Github Repo:
Demonstrates using an AAD B2C Extension Property to store an attribute that is then conditionally handled. - https://github.com/azure-ad-b2c/samples/tree/master/policies/force-password-reset-first-logon
Demonstrates how you can use a REST API call during your User Journeys. https://github.com/azure-ad-b2c/samples/tree/master/policies/rest-api-idp
It is worth noting that there are some features coming for API Connectors within the more simplistic User Flows, but I am unable to speak on those.
Related
From the documentation it seems that using an application that is in the B2C tenant and thus hosts user accounts that there is no way to directly access Microsoft Graph API via a logged in user per their own context.
I want to establish the use case properly so that the solution is that which makes the most sense.
The use case is that if a user wants to edit claims for example such as permissions they would be able to do so while logged in through Azure B2C.
The flow would be. Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)
Is the proper way to do this is to build a proxy that will take the application's AD application permissions which are allowed to call out to Microsoft Graph and pass along user context so that the scope will be limited to that user only?
For example. User logs into the app.
The app has AD permissions that are granted admin consent
Create a client secret to prove application identity upon request of a token
Now can access Microsoft Graph api
Ref of Registering an app with Microsoft Graph api
What's not clear here exactly is the next part. My user is logged in with Azure B2C. Should I just pass along their id token which has their claims to the application? How do I put in scope/context of the logged in user of the app permissioned access to Microsoft Graph?
This part is not clear in any documentation.
I don't want a logged in user to have access to everything.
Is a proxy the only way to do this?
If a proxy is the only way to do this what identifier or id is what should be used to pass along to the query to assure only that user is in context?
Am I thinking of this incorrectly and or is there a better way to do this other than a proxy?
The documentation says this.
Apps that have a signed-in user but also call Microsoft Graph with their own identity. For example, to use functionality that requires more elevated privileges than the user has.
That doesn't fit exactly into my use case above or address it really but I think it is related. The functionality should be considered to be an elevated permission but to the scope of the user. This user can change this claim via their own logged in entity. What do you call that and what is the best way to solution this?
Lastly, is there anything that should be known in the MSAL library including Angular and React that would be useful in this process? It seems like I will have to converge the 2 to obtain the access token of the app and of the person and proxy those out to a backend service (the proxy) to then do a body of work.
Am I thinking of this correctly?
This Stack is the closest to relevance but doesn't ask or solution the entire use case as I have here. But is useful for illustrating the confusion.
"Logged in user -> can change certain claims information such as address, surname, and other custom policy fields (SEO contact permissions.)"
Why can't you use the Profile Edit user flow? You can configure what attributes the user can change.
I'm building a web app (SPA) that is a case management system. Each user (mainly external to organisation) has a case on the system. I've been told by an architect we should be able to use Azure AD B2C to allow the users to login on this so I've been investigating this.
From what I can see I will get a token back from B2C saying the user is authenticated. What I don't understand is what use is that? Ok the user is authenticated but I have no idea who they are i.e. I will need to identify their case ref somehow so I can bring back their details...
If i was doing this in the old days when they login they'd be checked against a user table then their ID would be used to get their case details .. a token and data object would be returned from an api.. job done
I don't see how this would work in Azure AD B2C... am i missing something?
The JWT that is returned contains a configurable set of claims.
You can use these to identify the user. Typically, this would be email or UPN.
In your case, you need a userID. If this isn't one of the supported attributes, you can use an extension attribute to store it.
B2C can also call an API (if you use custom policies) so you could call an API to get the userID from e.g. a table and then return it as an extension attribute in the JWT.
I need help determining how to integrate the Azure B2C authentication with the authorization within my app. I got the susi (sign up sign in) user flow working, but I need to do two things. First, I need to validate the alias to ensure no other such alias already exists and I need to add the user to my sql server database to ensure they are available for authorization processes (eg: users can allow other users to view/edit their resources).
I saw this video, which seems to cover what I want to do, but I think I could use some explanation. This article also seems to come close, but it is returning keys from a database as opposed to inserting into a database. That seems like minor change.
It seems like I need to replace the susi user flow with a B2C Identity Experience Framework policy, but I still want the other steps to be completed. I think I should download the susi policy and edit it and upload it to the IEF, but I am not sure.
I previously was trying to capture the events in a web app in the Startup.cs file when configuring the service during the OnTicketReceived event, like this, but this didn't cover mobile apps, so I think the IEF solves for this by including the steps in the flow.
I just want to confirm this is the right way to accomplish what I am looking to accomplish and seeing if anybody has any step by step examples.
It seems like it would be a good tutorial to show starting with a working susi user flow and editing it to add integration with an Azure Function.
Using IEF by calling the REST API will be the right way to accomplish your requirement. During the signup process, execute a restful technical profile which will call an REST API service there you can validate the user existance in your local DB and create the user in the database and proceed the registration process in B2C tenant.
Another approach would be after signing up the user can be created by the service and for the first call, service can insert a claim for itself with new database user Id.
There is a sample showing how to implement RBAC in B2C using security groups. If the role model is very simple, you could also consider attaching them directly to the user object as custom claim.
I'm new to Azure ADB2C, and am confused by some of the terminology.
I am building a motorcycle ride monitoring website that I would like users to be able to log in to by verifying a social media identity (Google & Microsoft Account, for now).
But I only want users who are members of the site to be able to use certain features. For example, I'd like everyone who authenticates to be able to apply for membership, read about the benefits of membership, etc., but I only want members to be able to initiate ride monitoring.
Is the recommended approach here to only authorize (rather than authenticate, if I'm understanding the terminology correctly) certain authenticated users (i.e., members) to use the ride monitoring services?
If so, what's the best way to authorize a member? Look up their email (which I require to be returned from the authentication process) in a standalone database and proceed accordingly? If I go that way, what's the simplest way of adding their membership status to their credential, so I can access it throughout the site?
Apologies for not providing code here. I've got a bit of it hanging around :) but this is more of a design question than a coding one.
Azure AD B2C is primarily Authentication as a Service. There are ways in which it can be used for what you are trying to achieve here.
You can use custom (extension) attributes in AADB2C (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-custom-attr) in combination with AAD Graph apis (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet). So when user authenticates and applies for membership, you can call AAD graph api to set the custom attribute on user object. You can get the extension attribute in a the token after the authentication happens. This token will give you membership of the user.
You can also use AAD Groups instead of custom attributes. In the tenant, create membership groups. Once user authenticates, call AADGraph to set/get user's membership of a group and that will give the authorization information.
You can also do what you described, maintaining the info in a database store of your application. But the first two functionalities provide in-built functionalities for user management.
I don't understand how the 'Scopes' in Azure B2C are supposed to be used. They are associated with an API, but not a user. I'm sure I'm missing something, but I see no practical use for something associated with an API. I've used and implemented Claims-based authentication based on a user's role in the database.
For example: ordinary users of an API should not have the authority to delete an object, but administrators should have the authority. Does someone have a practical example of how these B2C 'Scopes' can be used to limit a users access to the API?
They are associated with an API, but not a user.
That is correct. I like to think of the association to the API as defining the 'surface area' of the API. For example, this API defines 2 scopes
read
write
Now, you could define two applications. One application that only has read permissions and one that has read and write permissions.
For the common use case of one Web App and one Web API it adds no value. I've been using a scope of no-op for such cases.
I've used and implemented Claims-based authentication based on a user's role in the database
You can use custom attributes to assign "role(s)" to the user. You can set them via the Azure AD Graph API to keep the setting of them secure. You can also set them during sign-up (this is much more involved though).
When you request an access token for that user, the custom attirbute(s) you defined and set will be readable in the API to check permission(s).
Comment Feedback
If I promote or demote a user, I need to change the endpoints (policies) they access at the client.
No need to change the policies. You would update the custom attribute for that user via the Azure AD Graph API.
My problem is that I'm mystified at the an authentication system that authorizes endpoints ("scopes") instead of users
Yeah, me too! I think it might have to do w/ the purpose of the product. B2C is about self-service sign-up, password reset and federating w/ other IDPs (like FB, Google, etc). Maybe Azure AD is a better solution when you want to control permissions on a user. Not sure, still learning!
I still don't see the practicality of splitting your API into several different parts based on the security. An API should be a collection of functionally related services
You don't split your API. You can split your app(s) that utilize the API. See above.
Documentation Reference: Requesting access tokens, GitHub Issue to improve the documentation.
Roles and scopes provide the two halves for this user access control.
Roles -- such as Administrator, Member, and Guest -- determine whether an authenticated user is permitted to delete objects.
Scopes -- such as read, write, and delete -- determine whether an authorized application can delete objects on behalf of an authorizing/consenting user if this user, through their role assignment/s, is permitted to do so.
Azure AD B2C doesn't have any current support for managing roles and assignments of them to users.
It does, however, have support for managing scopes and assignments of them to applications.