In recent months, we've managed to integrate our existing Identity Server 3 with AAD B2C. It's of course registered as a Custom Identity Provider by following this instructions. And everything works fine when it comes to authentication itself. All users from our existing database (which is behind our Identity Server 3) are able to sign-in with AAD B2C without any problem. And as you can guess all of them, once they sign-in for a first time, become Azure Active Directory (B2C Tenant) users as well.
But, we've just recently also noticed that none of them has correct User Name and Source values in the list of users in our AAD B2C Tenant (see picture).
Does anybody have any idea what we might be missing on either Identity Server or Azure AD B2C side (or both) and what could be a possible reason for not-populating these values?
When a User object for an external identity (e.g. an IdentityServer-managed identity) is created in the Azure AD B2C directory, it is created as follows:
{
"accountEnabled": false,
"creationType": null,
...
"userIdentities": [
{
"issuer": "...",
"issuerUserId": "..."
}
]
}
where the UserIdentity object is set as follows:
The issuer property is set to the string representation of the external identity provider that issued the user identifier, such as https://myidentityserver3.azurewebsites.net/identity.
The issuerUserId property is set to the Base64 representation of the user identifier that is issued by the external identity provider.
When the All Users menu is opened in the Azure AD B2C portal, then these external users are listed with the issuer value in the User Name column and "Unknown" in the Source column.
Related
I have an app that supports SAML 2.0. I want to configure Azure AD as Id Provider. I want to store my SP's unique identifiers in Azure AD user profiles. I could not find how to do that.
More specifically, I am able to select any of the user profile attributes as the value for NameId in the SAML response. But I do not want to use Azure AD standard user profile attributes. I could set up user.extensionattribute1 but where can I set the value for this attribute?
Note:
1. I am using trial Azure AD with Office 365 subscription. I am able to set up Azure AD as a SAML-based SSO Id Provider.
1.Navigate to Azure Active Directory > Enterprise applications and select the application from the list.
2.Under the Manage section, select Single sign-on.
3.Select SAML. The Set up Single Sign-On with SAML - Preview page appears.
You can configure User attributes and claims here.
Reference:
https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/configure-single-sign-on-non-gallery-applications
Have AzureAD application for authentication with appRoles defined in the manifest. The roles are assigned to users and they are included in tokens of authenticated users as claims. This is the case with members of the current tenant as well as newly added guest users of type "Microsoft Account" for the source of authority. (The signInAudience of the application is set as AzureADandPersonalMicrosoftAccount in the manifest.)
But for an existing guest user of type "External Azure Active Directory" for the source of authority, the appRole is not coming through the token claims. Is it worth trying to delete the guest user account and try readding it? Wouldn't this particular feature/behavior of appRoles be the same whether the source of authority for the guest account is "Microsoft Account" or "External Azure Active Directory"?
Or wondering might there be some additional/complementary setting that needs to be set or adjusted for the "External Azure Active Directory"?
PS: the authorization endpoint used currently is https://login.microsoftonline.com/common, and it authenticates just it's not getting the appRole, and it works with the appRole for the "Microsoft Account" type of guest account. Should that be changed however..?
Yup that was it. Based on suspicion tried changing the authority to tenant based https://login.microsoftonline.com/contoso.onmicrosoft.com and it worked... yes because guest user of type "External Azure Active Directory" would of course authentication against their tenant if using https://login.microsoftonline.com/common, and get their roles. So by forcing to authenticate against specific tenant where they are registered as guest users (where the roles are defined), the roles are added to the claims. Of course guest users of type "Microsoft Account" don't have their own tenants so were being authenticated against the tenant anyway... ha ha. Just found out this morning worked. First time using AAD, but kind of makes sense when think about it... Thnks!
I success configuring Azure AD as identity provider using OIC in Keycloack. But it ask email during the first connection with keycloak.
And I can't find how to create the mapper to populate email in keycloack with the one of Azure AD.
I figure that it's the userprincipalname that I get the email.
So I try that without success:
The UPN claim is upn. With v2 endpoint of AAD, you could also require the email scope and get the email in email claim. UPN and email can be different in some cases.
I had the same issue.
You need to create a new "Flow" in Authentication tab and "Add Execution" then add the Flow : "Create User If Unique".
In Identity Providers tab, you need to change the "First Login Flow" option, and pick the flow you've just created.
I have a multitenant ASP.NET application using OpenIdConnect and Azure AD as an Identity provider for Office 365. When the user is authenticated I receive my claims in ClaimsPrincipal.Current.
I wanted to identify a user and store this id reference in my database. I asked this question.
It was replied that
When trying to identify a user uniquely [NameIdentifier] should be your go-to choice.
But it seems that the NameIdentifier claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
depends on the application. Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user. Keep in mind that the we may have to create another Azure AD manifest (because we could need other scopes) and we should be able to find back the same end-users.
Meanwhile, I remarked another claim: ObjectIdentifier http://schemas.microsoft.com/identity/claims/objectidentifier
It seems that ObjectIdentifier, is the same for all Azure AD-secured application for a given Office 365 user.
Can you explain precisely the difference between those two claims? And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Precisely, if I create another application in Azure AD then, the NameIdentifier will not be the same for the same real Office365 user.
I made a quick test as following:
Register a multi-tenant-webapp and single-tenant-webapp in AD Contoso.
Log in with user1#contoso.onmicrosoft.com and get the name identifier in both web applications, it turns out the name identifier are the same in both applications. So the name identifier should be able to identify users cross applications, but it can not be used to identify the user in Azure AD.
For the object identifier, it is a GUID which you can used to identify a user in Azure AD. For example, you can use object identifier to query the user in Azure AD.
Powershell:
$msolcred = get-credential
connect-msolservice -credential $msolcred
get-msoluser -ObjectId "{guid:object_identifier}"
And more importantly, can you confirm that the ObjectIdentifier can be used as an "universal" identifier for a user in any Office 365 subscription.
Based on my understanding, the object identifier is a GUID which can identify for a user in Office 365 subscriptions.
Or to put it another way:
The NameIdentifier is the GUID of the Application which is registered in Azure AD. This won't change whether it's a single or multi-tenant application. It won't matter if you are using client credentials (i.e. AppId and AppSecret) to authenticate AS the application or using logging using real user credentials (i.e. delegated), the NameIdentifier will remain the same.
The ObjectIdentifier is the User Principal Name (UPN) for the user when using delegation or Service Principal Name (SPN) of the application when using client creds.
The reason you see different ObjectIdentifier values when an application is multi-tenant is that there is a separate and unique SPN in EACH TENANT which points back to the ApplicationGUID in the tenant where the application is registered. This SPN is used to assign rights to the application against resources in each tenant.
I have been trying to add a "virtual" claim provider (SAML 2.0 Identity Provider) in ADFS, I have another claim provider with same certicate. I get this error on ADFS2.0 in windows Server 2012
MSIS7600 Each Signing Certificate value for a claims provider Trust must be unique across all claims provider trusts in ADFS 2.0 configuration
Is there any workaround to avoid this issue?
No, I got the same thing here. Appearantly it must be unique. I tried to add 2 tenants (2 customers) coming from Windows Azure Active Directory where all claims of all tenants are signed with the same certificate.
The first one works perfectly but on the second one the MSIS7600 refuses to let me add the second Claims Party.
We had the same thing here and solved it by using this trick
We created a new Azure AD with the purpose that this is the one we are going to add in ADFS.
For each customer tenant we want users to be able to login, we asked asked for read permissions to this tenant; this way it it added in your own subscription. We then selected the users from the customer tenant and added it to the Azure AD we are going to use in ADFS.
We connected ADFS to this Azure AD
All our customers can now login to the ADFS using their own credentials. The only thing we have to do is adding the existing Azure AD users from their own tenant to our Azure AD.
This way it let's you to add as many customers or external Ad's if you want and also not "showing" all tenants in the list of the ADFS page. Because there is only one tenant in ADFS there is no complain of the error MSIS 7600 and you don't have to update all tenants seperately.
Philippe is right. You can use AzureAD B2B feature that allows you to login in any Azure AD user in any tenant to be able to login. This is done by invite. This feature is in preview. This is the simplest choice. However, from an ADFS perspective, policy is on only a single entity. Home realm discovery can be a little more tedious.
We've also fixed ADFS 2016 to relax this constraint for a few reasons. We now constraint it on "Cert + claims-provider-identifier". In this world you will be able to add any # of Azure AD tenants distinctly. This fix will be out in the next preview (should be out soon).