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.
Related
We have an on-premises (self-hosted) app which supports sending email notifications to users by providing SMTP mail server settings. Our users are all in Azure AD and are the only users of this on-premises app. Our users want to be able to receive email notifications from this app.
What is the recommended/best practice method for achieving this? Ideally the solution wouldn't require any additional subscriptions or added cost. It would be nice if the sending email address could be branded to match the app service it is coming from.
Here are some options that I've come up with:
Create a new user in Azure AD solely for sending email
Seems wasteful, and we are billed monthly per user
Use an existing user (i.e. my own) to provide authorization to the SMTP server
Rather not tie my own user credentials to this, and will break if I ever change my password
Use an entirely different email account (e.g. gmail?) for sending email
No relation to Azure AD tenant at all, harder for others to manage
Some existing method/service in Azure that is meant for this purpose, if it exists
Here's my idea on your case.
I watched this document, and I found that we can use API Key to initialize 'new SendGridClient', and it mentioned that we can stored this key into azure key vault.
So if you just wanna use azure ad to achieve the goal of protect your local app from unauthorized user, you may try my idea. First, create azure key vault in azure portal, and you could create a new secret to store your SendGrid Api key. Next to create an azure ad application used to achieve authentication, such as 'ROPC' flow(use user account and password to get access token). Now we can set access policy in azure key vault, added the azure ad app and all your user accounts so that every one could access API key via that azure ad app. After that, your app could send email.
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.
I have an Azure B2C service which serves to signing-up/signing-in users for my external apps (not hosted on Azure). The problem is that I have a few apps using this and I'd like to notify each of them when any user data change occurs in Active Directory (eg. email). Is there any functionality on Azure which could trigger some notifications to my apps about the change so the app could update its database?
Short answer is yes.
Long - probably too complex and definitely not within the scope of Azure AD B2C.
Can you live without this notification? Changing an e-mail address has no influence on core user data (unique identifier, oid claim). If you keep local user profile data in your application (which seems to be so), then you have to make sure you are referencing users by the oid claim you get from B2C and not by their e-mail addresses. Thus, any time a user signs-in you can check whether you have up to date info.
Do not forget, that changing e-mail address in Azure AD B2C is technically an execution of a B2C policy. Each execution of B2C policy ends with user being redirected somewhere (usually the application which triggered that policy) with a new token. A (relatively) simple solution would be to handle the callback of this authentication request (policy) and do what you want with it. For example have a notification service that would inform all applications about a change (think of EventGrid Topic where all your apps have a subscription to).
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.
Will the Azure AD UserInfo.UniqueId property always have the same value coming out of the Azure AD instance?
Once a user is Authenticated via Azure what can I use to fetch the roles and privs from our side (we have an existing structure). Since we don't have a password, I was thinking that we could store the Unique Id of the Azure AD User and look up the roles and privs that way....thoughts?
The UniqueId is sourced from the "best" identifier we receive from the service. In the most common case today that is the ObjectId of the user - which can indeed be used for retrieving more info. Please refer to https://msdn.microsoft.com/en-us/Library/Azure/Ad/Graph/api/api-catalog for more info on the queries you can perform.