I have been working on azure and for Signin process I was uploading the policies.
But I'm getting error while uploading.
alternativesecurityid is not in the output claims azure
Can anyone guide me in this.
In Azure Active Directory B2C (Azure AD B2C), social account identities are stored in a userIdentities attribute of a alternativeSecurityIdCollection claim type.
we need to create a JSON representation of the user’s alternativeSecurityId property that can be used in the calls to Azure Active Directory.
Use this claims transformation to generate a alternativeSecurityId ClaimType. It's used by all social identity provider technical profiles, such as Facebook-OAUTH
The following claims transformation receives the user social account ID and the identity provider name.
<ClaimsTransformation Id="AddAnotherAlternativeSecurityId" TransformationMethod="AddItemToAlternativeSecurityIdCollection">
<InputClaims>
<InputClaim ClaimTypeReferenceId="AlternativeSecurityId2" TransformationClaimType="item" />
<InputClaim ClaimTypeReferenceId="AlternativeSecurityIds" TransformationClaimType="collection" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="AlternativeSecurityIds" TransformationClaimType="collection" />
</OutputClaims>
</ClaimsTransformation>
Related
I have integrated Azure authentication in my project, it working good so far but, when I checked my azure ad users the username is showing unknown, I search every where but I can't found any suitable result that tells me what is the reason and problem, Azure signin_signup policy working good, when I was testing the policy first I signup and then I sign-in, when login is successfully I decode the token of the azure token and I found both name but not azure ad user name is unknown.
• Since, you are using Azure AD B2C custom policies regarding ‘Signup and Signin’, which are working fine but when you are trying to decode the token received for information in it, you are not getting information on the ‘username’ of the signed in user, it is because of the ‘Validation Technical Profile’ section being executed before the ‘OutputClaimsTransformation’ section. Thus, when signing up with an Azure AD local user account, the ‘LocalAccountSignUpWithLogonEmail’ technical profile is used which includes ‘AAD-UserWriteUsingLogonEmail’ technical profile as the validation technical profile. As a result, if you check the ‘AAD-UserWriteUsingLogonEmail’ technical profile in your signin-signup policy, you can see that in your ‘PersistedClaim ClaimTypeReferenceId="displayName" DefaultValue="unknown" />’ is stated. As a result, since the validation technical profile runs before ‘OutputClaimTransformation’, you are getting the ‘DefaultValue’ of ‘unknown’.
Thus, the claims transformation profile should be as below in your signup-signin policy: -
<ClaimsTransformation Id="CreateDisplayNameFromFirstNameAndLastName" TransformationMethod="FormatStringMultipleClaims">
<InputClaims>
<InputClaim ClaimTypeReferenceId="givenName" TransformationClaimType="inputClaim1" />
<InputClaim ClaimTypeReferenceId="surName" TransformationClaimType="inputClaim2" />
</InputClaims>
<InputParameters>
<InputParameter Id="stringFormat" DataType="string" Value="{0} {1}" />
</InputParameters>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="displayName" TransformationClaimType="outputClaim" />
</OutputClaims>
</ClaimsTransformation>
• Accordingly, ensure that the ‘Technical profile’ is also updated in your ‘LocalAccountSigninSignup’ custom policy as shown below and add ‘Validate-DisplayName’ technical profile as validation technical profile under ‘LocalAccountSignUpWithLogonEmail’ technical profile as mentioned below (in same order): -
<ValidationTechnicalProfiles>
<ValidationTechnicalProfile ReferenceId="Validate-DisplayName" />
<ValidationTechnicalProfile ReferenceId="AAD-UserWriteUsingLogonEmail" />
</ValidationTechnicalProfiles>
Thus, this would help you to resolve this issue of getting ‘unknown’ in the username. For more information, kindly refer the below link: -
https://learn.microsoft.com/en-us/answers/questions/713037/display-the-name-of-user-in-ad-b2c-instead-of-unkn.html
I am already using B2C custom policy to let employees signin using external IdP,
now I want to use my organization's Azure enterprise AD app as IdP.
All employees are already registered using external IdP but external IdP subscription will expire soon, so I need to move them to Org's Azure AD IdP.
When registered user sign in using Azure enterprise AD app with same email Id, it should find the existing users based on email and associate the existing user's objectId with new Azure IdP. It should not create a new ObjectId for same email user for new IdP.
In my case it is creating new objectId for different policy and I don't want new objectId created for different IdP because then it will duplicate the user in database due to new object Id Instead I want the same object Id, can you please provide info how this can be achieved?
I followed this while updating my policy - Link user journey
<TechnicalProfile Id="AAD-UserReadUsingEmailId-Link">
<Metadata>
<Item Key="Operation">Read</Item>
<Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">false</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaimsTransformations>
<InputClaimsTransformation ReferenceId="CreateOtherMailsFromEmailFromADAccount" />
</InputClaimsTransformations>
<InputClaims>
<InputClaim ClaimTypeReferenceId="email" PartnerClaimType="signInNames.emailAddress" Required="true" />
</InputClaims>
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="displayName" PartnerClaimType="displayName" />
<PersistedClaim ClaimTypeReferenceId="objectId" />
<PersistedClaim ClaimTypeReferenceId="otherMails" />
<PersistedClaim ClaimTypeReferenceId="userPrincipalName" />
</PersistedClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectId" />
<!-- Optional claims -->
<OutputClaim ClaimTypeReferenceId="userPrincipalName" />
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="otherMails" />
</OutputClaims>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>
but when I am searching with email I am getting below error in app insight log:
"Statebag": {
"PROT": {
"c": "2021-07-13T08:10:25.3600788Z",
"k": "PROT",
"v": "AAD Request to https://graph.windows.net/494db189-1a11-4de4-a4d0-7ba7003b4fbd/users?api-version=1.6-integrationOnly&%24filter=logonIdentifiers%2fany(x%3ax%2fvalue+eq+%27Prashant.Kumar%40gmail.com%27) using method GET as request body is malformed.\r\nResponse: \n{\"odata.metadata\":\"https://graph.windows.net/494db189-1a11-4de4-a4d0-7ba7003b4fbd/$metadata#directoryObjects\",\"value\":[]}\r\n",
"p": false
}
Why its giving malformed request, am I doing something wrong in policy file? any suggestions?
Although your request URL seems to be well-formatted as per Azure AD Graph API requirements, there is -integrationOnly value appended to the {api-version} which can only be one of the following values:
"beta"
"1.6"
"1.5"
"2013/11/08"
"2013/04/05"
which invalidates the request URL. Remove it and try again.
One other possible cause is spaces in the URL. Spaces in the query string should be URL-encoded before sending a request.
For example, your query string,
https://graph.windows.net/494db189-1a11-4de4-a4d0-7ba7003b4fbd/users?$filter=logonIdentifiers/any(x:x/value eq 'Prashant.Kumar#gmail.com')&api-version=1.6
should be URL encoded as:
https://graph.windows.net/494db189-1a11-4de4-a4d0-7ba7003b4fbd/users?$filter=logonIdentifiers/any(x:x/value%20eq%20'Prashant.Kumar%40gmail.com')&api-version=1.6
Although this is already done as in your error message, it is worth noting since it is mentioned at the bottom of the Azure AD Graph API Supported queries, filters, and paging options page.
Finally, as a side note, Microsoft recommends that you migrate your apps to the Microsoft Graph API since Azure AD Graph is deprecated but won't be retired until the end of year 2022.
Read more about Graph API Version {api-version}
I am using Azure AD B2C and custom policies to manage users and give sign in experience. I noticed that there is an inbuilt(not a custom extension) attribute name companyName which i am updating with user's company information. I am able to update this filed value via graph API and retrieve it respectively. Once this value is updated i am trying to include this in claims and send to client application however i am running into an issue. I have made sure to include a claim in TrustFrameworkBase policy like below
<ClaimType Id="companyName">
<DisplayName>companyName</DisplayName>
<DataType>string</DataType>
</ClaimType>
Also i have updated AAD-UserReadUsingObjectId techincal profile which is responsible for making a graph call (after successful authentication) and get all user attributes. here is definition for AAD-UserReadUsingObjectId technical profile
<TechnicalProfile Id="AAD-UserReadUsingObjectId">
<Metadata>
<Item Key="Operation">Read</Item>
<Item Key="RaiseErrorIfClaimsPrincipalDoesNotExist">true</Item>
</Metadata>
<IncludeInSso>false</IncludeInSso>
<InputClaims>
<InputClaim ClaimTypeReferenceId="objectId" Required="true" />
</InputClaims>
<OutputClaims>
<!-- Optional claims -->
<OutputClaim ClaimTypeReferenceId="signInNames.emailAddress" />
<OutputClaim ClaimTypeReferenceId="displayName" />
<OutputClaim ClaimTypeReferenceId="mobile" />
<OutputClaim ClaimTypeReferenceId="country" />
<OutputClaim ClaimTypeReferenceId="postalCode" />
<OutputClaim ClaimTypeReferenceId="state" />
<OutputClaim ClaimTypeReferenceId="company" />
<OutputClaim ClaimTypeReferenceId="companyName" />
<OutputClaim ClaimTypeReferenceId="surname" />
<OutputClaim ClaimTypeReferenceId="givenName" />
<OutputClaim ClaimTypeReferenceId="email" />
<OutputClaim ClaimTypeReferenceId="objectId" />
<!--Adding custom attribute start-->
<OutputClaim ClaimTypeReferenceId="otherMails" />
<OutputClaim ClaimTypeReferenceId="extension_UserGuid" />
<OutputClaim ClaimTypeReferenceId="extension_StatusFlag" />
<OutputClaim ClaimTypeReferenceId="extension_EZUserName" />
<OutputClaim ClaimTypeReferenceId="CurrentTime" />
<!--Adding custom attribute end-->
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="GetSystemDateTime" />
</OutputClaimsTransformations>
<IncludeTechnicalProfile ReferenceId="AAD-Common" />
</TechnicalProfile>
and finally i have included this companyName claim in user journey output claims.
Even after doing all this i noticed that companyName claim is not inside the token returned by azure AD B2C.
To trouble shoot further i enabled application insight for my policies and i observed a weird behavior.
When Azure AD B2C makes a graph call while executing AAD-UserReadUsingObjectId technical profile it forms a query something like below
https://graph.windows.net/f17d6207-7c3a-4d29-b802-ad5429b2a8d8/users/77669822-8034-4666-9800-8b614c0ccbfc?api-version=1.6-integrationOnly
and output of this graph api call does not include companyName attribute at all however when i make graph api call with similar query using my application id and secrete i do see companyName in the response. The only difference in the query which Azure AD B2C call vs i am calling the last part in api url. Azure AD B2C has -integrationOnly at the end where as i dont. I am not sure why graph API call response is differnet when Azure AD B2C makes it vs when i make it.
I can solve this issue by simply adding a new custom extension field and using that instead of companyName but my point is why i should create a custom attribute when one is provided out of the box and more importantly it will require me to fix about 1 million existing users.
has anyone come across this type of issue. Any help would be great!
Thanks in Advance!
CompanyName is an O365 built in attribute. B2C uses integration-only api version in the backend for its own calls as you’ve seen. The only solution is to use the extension attribute. A script to PATCH the users can fix 1million users in around 12hrs.
When using custom policy, stick to your own custom attributes, there is no real advantage trying to use default attribute names, only sometimes you find disadvantages. Custom policy only needs you to declare the attribute name as extension_ and it works just like any built in attribute.
We're investigating a migration of our existing authentication system to Azure AD B2C. Our current system accepts both MSA and Google logins, and we use an in-house developed service based on IdentityServer, which stores the IDs from the third-party IdPs in Azure Table storage.
I've followed the instructions for setting up MSA as an ID provider and for migrating users with a social account, and have converted my existing MSA IDs to base64 when posting them as userIdentities to the AD Graph API (in line with the sample code from the second link above). But when I sign in with an MSA, instead of recognizing my account, it directs me to the sign-up page (as part of the Sign-in/Sign-up policy I have defined).
If I follow through with creating the user, and then inspect the newly created user with the /users/<new-user-id> endpoint in the Graph API, I get back a strange-looking issuerUserId when compared to what I have stored for my Microsoft users currently.
My existing users have ids that look something like 1234ab56789cde01, and the IDs being sent to me via B2C are formatted as something like AAAAAAAAAAAAAAAAAAAAAAbCdEF12GhIj_KlM34nOPQwhen base64 decoded. (Values altered to avoid any potential privacy issues.) The capital 'A's are always there at the beginning, and I get characters from the full range of alphanumeric values in the new format as compared to the original IDs that only have a range of hexadecimal characters.
I've managed to get the Google accounts working just fine. All that's necessary there is to convert them to base64 and they just work. But I'm struggling to figure out how to migrate the MSAs. Either I'm doing something wrong on the app registration side, or there's another step to generating the AAAAAAAA-prefixed IDs that I'm just missing. Any help is appreciated. Thanks!
The built-in identity provider for Microsoft Account maps from the sub (subject) claim for the Microsoft account to the issuerUserId property of the userIdentity object.
If you are wanting to migrate identities that are mapped from a different claim (such as the oid (object identifier) claim) of a Microsoft account, then you must use custom policies and then add a custom identity provider for Microsoft Account with the following modification:
<ClaimsProvider>
<Domain>live.com</Domain>
<DisplayName>Microsoft Account</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="MSA-OIDC">
<DisplayName>Microsoft Account</DisplayName>
<Protocol Name="OpenIdConnect" />
<Metadata>
<Item Key="ProviderName">https://login.live.com</Item>
<Item Key="METADATA">https://login.live.com/.well-known/openid-configuration</Item>
<Item Key="response_types">code</Item>
<Item Key="response_mode">form_post</Item>
<Item Key="scope">openid profile email</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="UsePolicyInRedirectUri">0</Item>
<Item Key="client_id">Your Microsoft application client id</Item>
</Metadata>
<CryptographicKeys>
<Key Id="client_secret" StorageReferenceId="B2C_1A_MSASecret" />
</CryptographicKeys>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="live.com" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication" />
<!-- ORIGINAL: The following output claims maps from the "sub" claim to the "issuerUserId" property. -->
<!--<OutputClaim ClaimTypeReferenceId="socialIdpUserId" PartnerClaimType="sub" />-->
<!-- MODIFICATION: The following output claims maps from the "oid" claim to the "issuerUserId" property. -->
<OutputClaim ClaimTypeReferenceId="socialIdpUserId" PartnerClaimType="oid" />
<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
<OutputClaim ClaimTypeReferenceId="email" />
</OutputClaims>
<OutputClaimsTransformations>
<OutputClaimsTransformation ReferenceId="CreateRandomUPNUserName" />
<OutputClaimsTransformation ReferenceId="CreateUserPrincipalName" />
<OutputClaimsTransformation ReferenceId="CreateAlternativeSecurityId" />
<OutputClaimsTransformation ReferenceId="CreateSubjectClaimFromAlternativeSecurityId" />
</OutputClaimsTransformations>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
For information about getting started with custom policies, see Azure Active Directory B2C: Get started with custom policies.
Following this example https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-setup-aad-custom we have managed to federate an Azure AD directory ('AD') with an Azure AD B2C directory ('B2C'), so we can have social and self-asserted sign up to a public application, which our work users can also sign into with their normal work IDs. This works well and solves a complex scenario for us.
In the application which is secured with B2C, we need to show AD users content that is relevant to their work identity (specifically we need to filter products based on their work role), but this information is not available to us, since the process of signing up to the app generates a new B2C identity for the user (effectively a proxy for their AD identity).
What we need to do is to map the user's original AD identity onto the new B2C identity. Other properties of the AD user such as Given Name and Surname are already mapped, and that seems to take place here, in the ClaimsProvider element of our custom policy, via the PartnerClaimType property:
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="socialIdpUserId" PartnerClaimType="oid"/>
<OutputClaim ClaimTypeReferenceId="tenantId" PartnerClaimType="tid"/>
<OutputClaim ClaimTypeReferenceId="givenName" PartnerClaimType="given_name" />
<OutputClaim ClaimTypeReferenceId="surName" PartnerClaimType="family_name" />
<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="name" />
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="contosoAuthentication" />
<OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="AzureADContoso" />
</OutputClaims>
Indeed, it even appears that the ID we're looking for might be mapped to a property (oid) - but when we later query the B2C graph for the user, this oid property is not returned.
So - how can we map the user's Object ID from the work AD directory onto a property on the new B2C identity that is created?
CREATED on 28 Nov 17
Currently, the object identifier for the Azure AD user (or any external user) is saved to the "alternativeSecurityId" attribute in the Azure AD B2C directory, but this built-in attribute can't be queried via the Azure AD Graph API.
You can, however, create a custom attribute and map the "oid" claim from the Azure AD identity provider to a custom claim that is associated with this custom attribute.
Creating a custom attribute and using this as a custom claim is described at Azure Active Directory B2C: Creating and using custom attributes in a custom profile edit policy.
For your specific scenario, you should:
1: Add a <ClaimType />, declaring the custom claim, to the base policy:
<ClaimType Id="extension_AzureADUserObjectId">
<DisplayName>Azure AD User Object ID</DisplayName>
<DataType>string</DataType>
</ClaimType>
2: Map the "oid" claim in the "SignInWithContoso" technical profile:
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="extension_AzureADUserObjectId" PartnerClaimType="oid" />
</OutputClaims>
3: Add the application and object identifiers for the extensions app to the "AAD-Common" technical profile which is required to read and write the custom claim to the Azure AD B2C directory:
<TechnicalProfile Id="AAD-Common">
<DisplayName>Azure Active Directory</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.AzureActiveDirectoryProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<Item Key="ApplicationObjectId">Insert the object identifier for the b2c-extensions-app application here</Item>
<Item Key="ClientId">Insert the application identifier for the b2c-extensions-app application here</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="TokenSigningKeyContainer" />
</CryptographicKeys>
...
</TechnicalProfile>
4: Write the custom claim in the "AAD-UserWriteUsingAlternativeSecurityId" technical profile:
<PersistedClaims>
...
<PersistedClaim ClaimTypeReferenceId="extension_AzureADUserObjectId" />
</PersistedClaims>
5: Read the custom claim in the "AAD-UserReadUsingAlternativeSecurityId" technical profile:
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="extension_AzureADUserObjectId" />
</OutputClaims>
6: Issue the custom claim in any relying party policies or query it via the Azure AD Graph API.
UPDATED on 15 Feb 18
Since this announcement on 5 Feb 18, the external issuer (i.e., the Azure AD tenant) and the external user identifier (i.e., the object identifier of the Azure AD user) can be read from the "userIdentities" property of the user object in the Azure AD B2C directory, where the "issuerUserId" property contains the Base64-encoding of the external user identifier:
{
"userIdentities": [
{
"issuer": "contoso.com",
"issuerUserId": "Mjk2NzdlNTAtY2MwZS00MmU5LWJhNWMtZjFmMDdkZTUwMDhm"
}
]
}