I'm transforming a legacy system that stores its users in a database (including credentials) to use Azure AD B2C for authentication.
My first step is to rewrite the frontal API (the API that serves the web client directly)
Because many other systems and database tables depend on the users table and its columns, I've decided on creating a db user for every new azure ad registration.
This is the problem, the user id in the database is the primary key, an auto incremented number.
The id that I extract from the access token claims is a ad object identifier, a GUID.
To be able to relate an ad b2c user entity to a database user entity, I will have to create a new column in the users table, AzureObjectId.
The problem is that now I would have to constantly do the conversion between AzureObjectId which I extract from the access token, to the database users id, because other database tables and other internal APIs that I access expect a database user id.
What would be the right way to tackle this?
What I can thinks of is
Transforming AzureObjectId to database user id during every interaction with the database or another internal API.
Once my API creates the database user, use the Azure AD B2C Graph API to add a new claim, database user id, to the user.
Both of these I want to avoid.
Is there someway to enrich the access token with the database user id?
I would go with second option as its a one time operation and system doesn't need to do the conversion every time.
Update with details
This seems to be a migration scenario as well. Check samples here
You will also need to use Restful api feature of custom policies as well.
During the signup process, execute a restful technical profile which will call an api in contoso (your) service to create user. The contoso service will return the database user id of the newly created user. This new userId can be used as a subsequent claim for the user and AzureADB2C will create the user with that extension property.
The another approach is what we discussed earlier. After signup 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.
Yes - use custom attributes
You can add custom attributes via the portal and select these to return them as claims in the token.
The Graph API link above shows how to create them programmatically.
So if you populate the database user id into the custom attribute you'll be able to return it in the token.
Related
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 have an application that requires some records to exist in a database for registered users. I've created a custom Azure AD B2C policy that pushes this user information to the database through REST API claims exchange. This also allows the records to be updated when the profile is edited.
Now I'd like to remove records for users that are deleted from the B2C tenant.
Is there any way to receive a notification of some sort when users are deleted?
Have a look at differential query. You will need to use a batch service (using client credentials flow to get an access token) that periodically runs the query to get the deleted users.
I am trying to create a new user for an application which uses CosmosDB. From the documentation, it expose a service method to create a new user.
I believe the created user can access the Cosmos DB provided the users are updated with certain permission to the collections
And my query,
Is there a service method to create a user with password? If not, any alternatives to do the same?
Is there a way to see the created users in Data Explorer rather than List Users?
1.Is there a service method to create a user with password? If not, any alternatives to do the same?
As I know, no such method in cosmos db. Based on this document, Azure Cosmos DB uses two types of keys to authenticate users and provide access to its data and resources. User and permission is resource token type here. It's meant to avoid the risk of master key exposure. It is authenticated by token,can't be password.
If do want to use password for authentication, maybe you just have to protect the token by password with your own logical code. Other words, you get the above resource token first then manage the mapping relationships between user and resource token by yourself.
2.Is there a way to see the created users in Data Explorer rather than List Users?
It can't be found on the portal now.You need to list users and permissions using sdk or rest api. You could commit feedback here to ask azure cosmos team to add this feature.
one of our existing projects is running with a traditional authentication logic (having a user table in database). How the plan is to move the identity to AzureB2C with social IDPs integrated. But there are still some ares where we would need the reference of the existing user table. I need to find a way to map the logged in user from Azure B2C with the user table in database. I can read the email property from claims and try to map, but the challenge is user might have a different email for his social accounts. I know this actually defeats the purpose of the openId/oAuth to look back again in the user table after login. But this is a strange situation in running into. Any ideas how best this can be done ?
Copying response from: https://social.msdn.microsoft.com/Forums/en-US/221fce11-28ff-4236-a300-d6160ffc9379/azure-ad-b2c-how-to-map-the-user-logged-in-from-social-idp-to-a-local-user-table-?forum=WindowsAzureAD
Some facts are missing from your question so I will make assumptions which you can correct.
Assume that:
You do not use social IDPs today. So no existing connection between the social account and the local DB account.
This point is crucial because it is usually the user's prerogative (due to privacy) to make this link explicitly.
Assume that you will tell the user explicitly what you are doing as part of the transition.
To achieve this with b2c built-in policies you could:
1. Your app logs in the user the old fashioned way.(existing lookup DB)
2. Your app then invites users to register (in fact re-register) using a b2c signup policy which offers them social idp choices.
3. At the end of the b2c registration process, the user's email which was provided and proofed during the b2c signup and Object ID (newly created) is sent back to the App
4. The app uses the object ID and Graph to write the users existing id (old DB email or other unique user id you used today) to the new user's object in Azure AD B2C.
5. The app should note on the old DB that this user has been migrated so in the future the app does not present the option to re-register.
6. The app has to manage users in 2 different states.
Other alternative is to use custom policies and Account Linking
Here you could
1. Migrate all users into b2c using their old passwords. (assume you can get them from old DB in the clear) using Graph.
2. Point your app to b2c - users can login
3. Offer you users the option to link their b2c account to a social account. this requires custom policy and a policy path that is not public but its a simple sample we can provide.
I have developed a Web API, hosted in Azure, with OAuth 2.0 Authorization grant thru Azure AD. I have the token system working, I am able to request an authorization code, and use that to request access/refresh token, and then request data from the API in general.
The next thing I am struggling with is how do I allow user A to access Database A data and user B to access Database B data. We have different databases and each user has their own private data. Both user A and B are using the same native "client" desktop application. So here is my thought process:
We could make user A its own "application" in Azure AD, and user B its own "application" in Azure AD. They would have different access tokens then. But how do I know in my Web API that user A is calling my API, or user B is calling my API if Azure AD is the one doing the authorization? is there a way to extract which particular user is calling the API from which token is used or something, so I can pull data for only that user? All I have currently is the [Authorize] at the top of the ApiController for the different REST calls and then setting up the application in Azure AD, but that is just general authorization access to the API, not specific permission/authenticated access to private user data.
I assume that you are using OWIN/Katana with JWT support for authorization. If so, then you should find that if you get the ClaimsPrincipal.Current property there will be a ClaimsPrincipal object that represents the user that was authenticated. It will contain a set of claims that are returned from AzureAD. You can use those claims to retrieve an identifier for the user and map that to their associated database.
Take a look at the sample here:
https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet
In particular this file:
https://github.com/AzureADSamples/WebAPI-OnBehalfOf-DotNet/blob/master/TodoListService/Controllers/TodoListController.cs
line 80:
// A user's To Do list is keyed off of the NameIdentifier claim, which contains an immutable, unique identifier for the user.
Claim subject = ClaimsPrincipal.Current.FindFirst(ClaimTypes.NameIdentifier);
After this code the subject.Value property will contain an identifier for the authenticated user.
This link contains some documentation on the set of claims that Azure AD will return:
http://msdn.microsoft.com/en-us/library/azure/dn151790.aspx
Search for "Azure AD issues a fixed set of claims for the authenticated users."