Currently our team is struggling with propper architecture of Azure B2C solution for our multi tenant app.
Here is what we want to achieve. We want to enable users from certain Azure AD to authenticate. This is nicely described here with restricting tenants we want to enable.
We just want to enrich this solution with google authentication. We do not want to enable all users to be able to sign up. Is there a possibility to create google federated user programatically? We basically recieve list of emails from customer company and we create accounts in tenant). As far as I know there is no possiblity to achieve this using ms graph API when I don't have issuerUserId of user.
Do we have any possible solutions for this type of scenario? Like invitation email or so? Or maybe B2C is not a propper solution in this case.
Thanks in advance
A solution would be create the allowed users in b2c as a local account in graph api with accountEnabled as false and some generated password. Since the accountEnabled is false, user will not be able to sign in or reset the password as the default set of custom policies verify that attribute.
In the federated flow in custom policy,
Let the user complete federation.
Read the account using email address received.
If a local account exists, then link the federated account (Write alternateSecurityId to the account using objectId).
If a matching local account cannot be found, block the user by showing a selfAsserted page saying you are not allowed to sign up/in to this application.
You could also have some custom boolean extension attribute set to the local account to have an extra validation and update it's value once user completes the signup.
Related
I need to configure a SignIn (no SignUp) custom policy on an AAD B2C tenant, but I'm lacking the experience of the IEF to design/develop and test it properly. The policy should read (logically) as follows:
Present UI to user to enter email only (using a self-asserted TP?)
Use custom logic to determine whether the user represents a local account or to any of the known clients of ours. A single client could have multiple possible domains to be authenticated in the same IdP. The only option I know for doing this step is an external REST service, but this is something I would like to avoid if there is any other option to include custom login running inside the custom policy engine, using C#, JS, or event a simple dictionary from email domain to IdP domain.
Depending on the IdP automatically selected in step 2, branch to different journeys where the user will be sign-in
For local-account sign-in journey, the user will need to use MFA if he/she belongs to admin group. Only email, DisplayName, FirstName, LastName and UserId are needed as final claims.
For other IdPs I would have to add ClaimProviders and sub-journeys to allow for signing the users in
Finally the JWT Token should be issued to the relying party.
No storing back to AAD storage is required because there is no sign-up process. User are created from the application and invited (if local account) or already exist in their corresponding IdPs.
The wording you should look into is "home realm discovery".
There is a custom policy example on GitHub. However this example requires the application to provide the email hint. You need to extend it in a way that captures the email in a self-asserted step.
For scenarios where you need to implement a sign in journey, where the user is automatically directed to their federated identity provider based off of their email domain. And for users who arrive with an unknown domain, they are redirected to a default identity provider.
In this example, users who enter an email with the suffix contoso.com, they will be redirected directly to their federated identity provider to sign in. In this case that is Azure AD (SAML2).
Users who enter an email with the suffix facebook.com, they will be redirected directly to their federated identity provider to sign in. In this case that is Facebook (OAuth).
Where a user comes from an unknown email suffix, they will be redirected directly to a default identity provider, in this case that is Azure AD (OpenId).
This is another sample.
It first asks for the domain and then redirects to the appropriate IDP.
To add IDP, refer to this.
For MFA, start with the MFA starter pack.
In short: how to set up Azure B2C to pre-create users and invite them to set their initial password (rather than reset it).
We have public facing website that an organisation can pay for and it gives them access to their own area. We add one or more user's email addresses to our database to grant them a login. Privileged users at the organisation can invite other users to grant them access to their organisation's area.
We wish to move our authentication, session and password management from a home grown solution to Azure AD B2C.
A new user currently receives a friendly invitation email with a hyperlink that contains a token that gives them permission to set their password.
We could create a custom policy to handle this but I really don't want to go down that route due to their complexity and shelf life.
The only way that I've found "out of the box" is to create the user in Azure AD (not problem with that), set a temporary password and email them an invite asking them to "reset" their password. The reset part is very unclean as they are not resetting their password, they are setting their initial password and this will be confusing.
Also note that we do not want the user to be able to change their email to something like a hotmail account, as the admin must be in charge of this to ensure they use their work email.
All help appreciated.
Andy
• In your scenario, I would suggest you configure an application registration in Azure AD B2C and configure user flows in it for resetting the password for every user logging in it. Also, while registering an application in Azure AD B2C, you can select the option for ‘Accounts in this organizational directory only (Default Directory only - Single tenant)’ and integrate it with your website in the frontend API such that the user flow to reset the password after verifying the email address comes up for every user.
For the above said configuration, kindly refer to the below documentation link for more details as it describes the configuration for registering users of a single tenant/organization: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-single-tenant?pivots=b2c-user-flow
Also, refer to the below documentation link for resetting the initial temporary password using the user flow section as setting up a user flow is a very simple process as described below: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-password-reset-policy?pivots=b2c-user-flow
I have a custom policy that allows a handful of users the ability to authenticate as themselves but then enter an email address of another user they need to impersonate (for help desk calls, etc). The users in the AAD B2C directory are of two types -- 1) local users (third party partners) and 2) federated users from our internal, corporate AAD. Impersonating the local users is working. The solution is based off of sample github.com/azure-ad-b2c/samples/tree/master/policies/
What is not working is impersonating federated users. What I'd like to do is read the user based on otherMails (which will be unique among active users)but when I attempt to upload a custom policy with a step to Read the user from the B2C directory by the otherMails claim I get a validation message '.Input Claim 'otherMails' is not supported in Azure Active Directory Provider technical profile 'SelfAsserted-TargetEmailExchangeFederated' of policy 'B2C_1A_Impersonation'.
'otherMails' is defined in the base policy so it seems it is just not supported to 'Read' on. I get this same error message if I try the mailNickname attribute. I can successfully upload and run the policy searching by other attributes such as employeeId, or immutableId however these have other limitations (size, uniqueness) that don't make them viable to store email addresses in.
Is there a way to read a user profile by otherMails?
If not, is there another field I could use? (I tried adding an extended attribute, policy would run but the account would not be found).
Short of either of those, is there a way to read the account from our corporate AAD by email from the custom policy? (calling the graph api, etc?)
If it helps anyone, what I ended up doing was creating a custom api that wrapped the graph api to look up identities based on entered email and then called out to the api from the impersonation policy.
similar to:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-rest-api-netfw
for reference:
Find a User by Email Address
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 would like to pre-register a limited number of users which can use my application.
This are the requirements:
Users should be able to reset their password on their own
No other users than the preregistered users can sign up
Ideally, the user can choose the login email address by himself (no #app.onmicrosoft.com login).
Now I'm having trouble to have all requirements fullfilled together.
I was able to preregister #app.onmicrosoft.com users in the Azure Portal. But since the user can't get emails on #app.onmicrosoft.com, a password-reset-policy would not make sense. I tried to specify alternate-email and a phonenumber in the user-profile, but unfortunately the password-reset-policy is not using it for verification.
Let's say I create a sign-up policy: This is nice - the user choose his own email. Password resetting would also work. However, I can't control who's signing up and getting valid access tokens. In the portal, under Enterprise Applications, I found my registered application (All Applications) where I can set an option "User assignment required?" to true. But this does not seem to work in the B2C context, right? I expected, that until I assign a user to this application, the user is not getting a token on sign-in, but this wasn't the case. Here I found a similar question about creating users. Any advice on creating users including passwords etc. using Microsoft Graph (since it's recommended to use it over Graph API)?
I also tried to invite users as guests. They have to create a microsoft account, resetting passwords would be solved through microsoft, but unfortunately, no redirect to microsoft login happens after entering the microsoft account email address.
Deleting the signup policy after initial registration is a bad option if more users have to be onboarded.
Ideally, I would like to preregister users as if they signed up by their own - but with no signup policy.
Any advice? What do I miss?
You can implement the activation/invitation scenario that is described here and implemented here.
This scenario activates/invites a new user by creating/pre-registering a local account in the Azure AD B2C directory through the Azure AD Graph and then sending a signed redemption link to the email address for this local account.
This redemption link directs the new user to the Password Reset policy.
Currently creating users in a B2C tenant with a "local account" is not supported in Microsoft Graph. For this you'll need to use Azure AD Graph for now (see creating a user with a local account). Please see this blog post for details and line item 12 in the table.
We hope to add this capability as soon as we can to Microsoft Graph.
Hope this helps,