In Azure B2C there are several identity providers, for this example I'm going to use local accounts and Google accounts:
A new user signs up with a local account using the email address user#gmail.com. They use the site, next time they return, they instead decide to sign in using the Google identity provider with the same email address and they then use the site.
Currently this would have created two user accounts - each using one of the identity providers.
Instead, is it possible to set B2C up so that in this scenario we end up with a single user account, which is linked to both identity providers? Therefore regardless of which method they use to authenticate, they will be signed in as the same user.
You can achieve it by working with Identities property.
When the user signs in/up using external identity provider the alternative identity is used (created from external identifier and external issuer). In most cases a single alternative identity is used but the property in the user object is always a collection. You can manipulate the collection using proper claim transformations - AddItemToUserIdentityCollection, RemoveUserIdentityFromCollectionByIssuer, etc.
You can find a ready to use sample doing the linking and unliking identities to the account in an official samples repository:
https://github.com/azure-ad-b2c/samples/tree/master/policies/account-linkage-unified
Related
I've successfully implemented the following sample/custom policy in our B2C configuration:
A B2C IEF Custom Policy which links a Federated login against a pre-created Local Account
Users from an Azure AD are allowed to login to our application if a Local Account exists. This Local Account includes a custom field that points to the oid of the AD user that wishes to login.
However, the sample is for single-tenant. I'm in the process of adjusting it for multi-tenant.
When linking an Azure AD user, is it okay to depend on the uniqueness of the guid/oid? Is the fact that a guid could be generated twice (even though it's really unlikely) a security risk? I.e. a second user with the same guid could have access to data they're not supposed to see?
I'm assuming it's not an issue within a single tenant - each user inside a single Directory needs to be unique. But is that true across all Azure AD Directories? Could one machine generate the same guid for two users across two different Directories?
Am I better off figuring out how to compare against the issuer and the issuerUserId in combination?
• The ‘issuer’ and ‘issuerUserId’ input claims values represent the ‘socialaccountprovider’ or the ‘identityprovider’ and the ‘value’ of the key claim in base64 encoded format respectively. Thus, the issuer value represents the social identity provider which provides the identity details for logging in to the Azure AD B2C application while the issueruserID represents the secret value that is used by the IDP or that social identity provider for providing the identity details in an acceptable encrypted format to Azure AD B2C.
• And AFAIK, GUID for an Azure AD user is unique as it itself abbreviates for Globally Unique Identifier. Also, in Azure, every user has a unique object ID no matter where the user comes from because the object ID is GUID format, and it will generate a unique GUID for each user when adding a user to Azure AD.
But there could be two same object id(guid), but it's a very small probability (very very small, for example if you have 100,000,000 users in all your AAD domains, then the probability of existence of two same object id is about 1/3.4×10^30, so you can ignore that). You need to perform a validation to guarantee the uniqueness of object ID and GUID in a domain, so in AAD, the GUID is generated based on machine information, current time, and other factors.
Thus, when you are talking about generating the same GUID for two users across different directories, you should think that for identifying a user, the object ID as well as tenant ID is used. In this case, if the object ID is unique then the tenant ID is useful to find the user in a multitenant scenario. For more information, kindly refer to the below links: -
Azure Active Directory User Object Id (Guid) uniqueness across all AAD domains
https://learn.microsoft.com/en-us/azure/active-directory-b2c/social-transformations
I have created Azure B2C Sign-In and Sing-Up policy as Built-In policy. Where i need to collect User First Name, Last Name and Country information.
Above built-in policy support below two identity provider login..
We need Country attribute information only when local User sign-up very first time. But as we have made Country as mandatory attribute, so it is coming for Azure AD user as well when they login very first time and we don't want to collect any country information for Azure AD users login.
How can we handle this scenario that within Single Built-In policy handle mandatory attribute differently.
Not able to get any thought though whether this will work using custom policy or not. Because User needs to login either sign-in/Up over login page by using above two Identity Providers.
I'm currently setting up Azure B2C tenancy. As part of the setup, I'm integrating with external identities for the User to login. However, the requirement I have is that once signed-in using their external identities I want a corresponding user record to be created in my tenancy which I want to use later for application-specific role management & fine-grain access.
Thanks in advance for your help.
The described behavior is default and only supported one, for Azure AD B2C.
Once a user signs-in with their social identity provider, a "local" profile will be created - indicating basic info, like which social IDP the user is using, any info provided by the provider, any additional info that you explicitly required from the user (via user attributes).
You can later use this "local profile" for manage user's info. Here is an example of such user profiles in a B2C tenant:
You see some users coming from Gmail, some from Facebook, some from "other" (which is actually Microsoft365 in my case).
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
I saw a post today on linkedIN to say Azure B2B now accepts Google IDs (e.g. people with a Gmail account)
It said this is achieved via Federation, (using google as the identity provider)
As far as I am aware you have been able to do this for a while (or was that because it was in public preview), whereby someone could enter their gmail account but in the background (after the simple on boarding process was completed) this gmail account is linked to a place holder Azure AD account (represented by a GUID).
So in the announcement of Azure AD now accepts google IDs, is this the case where a preview service is now main stream ? or is this something new?
My main question is below
As far as I understand federation (please correct me if I am wrong) although your own Identity provider together with your own STS (secure token service, which is trusted by the replying party) provides you with a token (signed SAML/JWT) with is then presented to the replying parties STS (which then creates is own token from the information in the token you provided), you still need an instance of an object (user/group etc) in the Replaying parties system to check if said instance is allowed access to a resource based on the token (looking at the ACL on the resource and the information in the token). So although the replying party does not need to maintain the users password to authenticate them (done by the trusted Identity Provider) an instance of an object still needs to be created/exists on the Relaying Party system (to match the token information e.g. group membership for example) to the ACL on the actual object trying to be accessed
is the above correct?
Thanks very much
A User is always created in Azure AD, as it is in this case as well.
This applies to users created in Azure AD, synced from on-prem AD, invited from other AAD tenants, personal MS accounts, and now Gmail accounts.
Before Google B2B, if you invited a Gmail user, a personal Microsoft account would be created for them in the background, which would then be added as a Guest in the AAD tenant.
Now if you enable Google B2B, when you invite a Gmail user, they'll log in on the Google login page instead of the AAD login page.
So now instead of creating an MS account invisibly, the Google account itself is added as a Guest User, and AAD relies on Google to authenticate the user.