I used this Walkthrough from Microsoft (https://learn.microsoft.com/bs-cyrl-ba/azure/active-directory-b2c/active-directory-b2c-rest-api-validation-custom) to configure a RESTful API claims exchange as a technical profile in my TrustFrameworkExtensions.xml file. I pass various InputClaims like objectId, email, etc. It works fine. The problem is that I have more than one custom policies that use TrustFrameworkExtensions.xml as a BasePolicy and I want to pass to the RESTful API which custom policy is calling the RESTful API by sending the PolicyId as a parameter.
I tried to add InputClaim like this:
<InputClaim ClaimTypeReferenceId="policyId" AlwaysUseDefaultValue="true" DefaultValue="{Policy:PolicyId}" />
but it throw the error that
policyId is not defined.
You need to define policyName as a ClaimType in ClaimsSchema so it can be referenced using ClaimTypeReferenceId in InputClaim in the TechnicalProfile.
<ClaimType Id="policyId">
<DisplayName>PolicyId</DisplayName>
<DataType>string</DataType>
<UserHelpText>PolicyId.</UserHelpText>
</ClaimType>
Then, this will work:
<InputClaim ClaimTypeReferenceId="policyId" DefaultValue="{Policy:PolicyId}" />
Related
I'm using Graph to query a user profile in Azure B2C. I'm able to query the users, but I don't see the Source field to determine the Source of Authority. What field is this?
I'm currently using the .28-preview of the Microsoft.Graph.Beta NuGet package.
And this is what I see in the debugger under Identities:
How would I tell the difference if that was a Google account or an Azure AD account?
Using Microsoft Graph, it’s the issuerId field within the Identities array and only returns on beta version.
Source is not included in the identities array, and is also not included in the properties.
As this issue with PowerShell shows, onPremisesSyncEnabled property will help.
I solved this by creating a custom attribute and then in the custom policies setting the custom attribute based on signup method (see alternative solution near the end).
How to define custom attributes and use them with the MS Graph API and custom policies is explained pretty well here. The hardest part is perhaps getting the custom policy right. I did everything in TrustFrameworkExtensions.xml. First defining an "extension_authoritySource" ClaimType:
<ClaimType Id="extension_AuthoritySource">
<DisplayName>AuthoritySource</DisplayName>
<DataType>string</DataType>
</ClaimType>
Then in <TechnicalProfile Id="Facebook-OAUTH"> I added an OutputClaim which sets this custom attribute to facebook, but this will only be persisted if a PersistedClaim is made in UserWriteUsingAlternativeSecurityId as shown below:
<OutputClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="Facebook"/>
To persist the custom attribute I added the following to ClaimsProviders:
<ClaimsProvider>
<DisplayName>Azure Active Directory</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="AAD-Common">
<Metadata>
<Item Key="ClientId">[b2c-extensions-app application ID]</Item>
<Item Key="ApplicationObjectId">[b2c-extensions-app application ObjectId]</Item>
</Metadata>
</TechnicalProfile>
<!-- Write data during a local account sign-up flow. -->
<TechnicalProfile Id="AAD-UserWriteUsingLogonEmail">
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="local"/>
</PersistedClaims>
</TechnicalProfile>
<TechnicalProfile Id="AAD-UserWriteUsingAlternativeSecurityId">
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="extension_AuthoritySource" DefaultValue="social"/>
</PersistedClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
Note that with the above email signups will always be set as "local", while UserWriteUsingAlternativeSecurityId sets it as "social", but is overwritten by the output claim from facebook.
My thinking here is that UserWriteUsingLogonEmail is only ever used by email signup, whereas UserWriteUsingAlternativeSecurityId could potentially be used by several federated logins, although at the moment I only use facebook.
Alternative without Custom Attribute
Alternatively, if you are not using custom policies or cannot use the approach above for another reason, you can use the MS Graph API and look in the "identities" array which contains the sign in type. So for a given user GET: https://graph.microsoft.com/v1.0/users/[Users objectID Guid]?$select=identities
In this array you can find for a local signup:
{
"signInType": "emailAddress",
"issuer": "[yourdomain].onmicrosoft.com",
"issuerAssignedId": "[email]"
}
and for facebook:
{
"signInType": "federated",
"issuer": "facebook.com",
"issuerAssignedId": "[number]"
}
Every user also has a "userPrincipalName" item in the identities array so you will have to have some logic to loop through the array and only look for the signInType which you want to support. Yet another reason for preferring using custom attribute and setting the authority source yourself.
Azure AD B2C Custom Policy is failing validation and there is no reference to what is causing the validation error.
I already had custom policies defined for my application to start with and everything works fine prior to my adding a simple companyName string to the signup process. I followed the steps detailed in this guide to add a field to collect at signup. I ran into issues uploading the singup_signing custom policy after successfully uploading the TrustFrameworkBase policy. It was telling me that
Validation failed: 1 validation error(s) found in policy "B2C_1A_SIGNUP_SIGNIN" of tenant "xxxxx".Output Claim 'companyName' is not supported in Azure Active Directory Provider technical profile 'AAD-UserReadUsingObjectId' of policy 'B2C_1A_signup_signin'. If it is a claim with default value, add AlwaysUseDefaultValue="true" to the output claim mapping.
So I did as suggested and added the AlwaysUseDefaultValue="true" and DefaultValue="" attributes to the OutputClaim in the 'AAD-UserReadUsingObjectId' technical profile. This allowed me to upload the policy file successfully.
However, when I test the signup_signin policy, I get a message stating
Unable to validate the information provided.
I have Application Insights setup for this tenant as well and see the equally vague error message
Error returned was 400/Request_BadRequest: One or more property values specified are invalid.
I added the claim type to the claims schema in FrameworkBase
<ClaimType Id="companyName">
<DisplayName>Company</DisplayName>
<DataType>string</DataType>
<UserHelpText>Your company</UserHelpText>
<UserInputType>TextBox</UserInputType>
</ClaimType>
I added the PersistedClaim to TechnicalProfile 'AAD-UserWriteUsingLogonEmail'
<PersistedClaim ClaimTypeReferenceId="companyName" />
I added the OutputClaim to TechnicalProfiles 'AAD-UserReadUsingEmailAddress'
<OutputClaim ClaimTypeReferenceId="companyName" />
and 'AAD-UserReadUsingObjectId'
<OutputClaim ClaimTypeReferenceId="companyName" AlwaysUseDefaultValue="true" DefaultValue="" />
I added the OutputClaim to signup_signin.xml as well
<OutputClaim ClaimTypeReferenceId="companyName" />
I expect that the user is successfully signed up but get the validation error above instead
That example uses "city".
"Your Azure AD B2C directory comes with a built-in set of attributes. Examples are Given Name, Surname, City, Postal Code, and userPrincipalName."
So "city" is in the schema.
I assume from the error that "companyName" isn't.
To add that, you use a custom attribute.
So it would be "extension_companyName".
I'm using Azure AD B2C.
I've created a Sign up v2 user flow with multifactor authentication enabled. When I run the user flow and go through the sign up process including MFA via SMS to my specified mobile phone number, I'm returned to the reply URL that I've configured - jwt.ms.
The id token has return claims including my email address as well as other attributes that I've configured to return, but nothing regarding the mobile phone number used for MFA. There doesn't appear to be a way to configure the user flow to include this in the return claims. Does anyone know if this is possible and if so, how to do it?
Cheers.
The phone number is read from and written to the strongAuthenticationPhoneNumber property of the user object.
Currently, this property is not available to a built-in policy (i.e. a user flow), but it is available to a custom policy.
If you use the custom policy starter pack for MFA, then you can add the strongAuthenticationPhoneNumber claim, as an outgoing claim in the ID token, as follows:
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignIn" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<OutputClaims>
...
<OutputClaim ClaimTypeReferenceId="strongAuthenticationPhoneNumber" PartnerClaimType="phone_number" />
</OutputClaims>
<SubjectNamingInfo ClaimType="sub" />
</TechnicalProfile>
</RelyingParty>
I followed the example in Set up sign-in with a Salesforce SAML provider by using custom policies in Azure Active Directory B2C
and was able to successfully SSO from Salesforce into Azure B2C. However, I would also like to retrieve the value of
the NameID element from the SAML Assertion as a claim. Is this possible?
For example, say that the incoming SAML 2.0 Assertion posted to B2C's assertion consumer endpoint looks
something like this simplified XML.
<saml:Assertion>
<saml:Issuer>https://mytestinstance-dev-ed.my.salesforce.com</saml:Issuer>
<saml:Subject>
<saml:NameID>emp99999</saml:NameID>
</saml:Subject>
<saml:AuthnStatement AuthnInstant="2018-10-04T16:56:44.192Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="userId">
<saml:AttributeValue>009f90000099zzz</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="username">
<saml:AttributeValue>user000#example.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="email">
<saml:AttributeValue>user000#example.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="">
<saml:AttributeValue>false</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
The TechnicalProfile lets you access any Attribute from the AttributeStatement as a claim by referencing its
Name in the PartnerClaimType in an OutputClaim element. For example, with the TechnicalProfile below, the socialIdpUserId claim is
set to the value of the userId attribute from the SAML Assertion, "009f90000099zzz". What I would like to have is
is a claim named employeeId that is set to "emp99999," the value of the NameID element.
<TechnicalProfile Id="salesforce">
<DisplayName>Salesforce</DisplayName>
<Description>Login with your Salesforce account</Description>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="RequestsSigned">false</Item>
<Item Key="WantsEncryptedAssertions">false</Item>
<Item Key="WantsSignedAssertions">false</Item>
<Item Key="PartnerEntity">https://mytestinstance-dev-ed.my.salesforce.com/.well-known/samlidp/TestB2C.xml</Item>
</Metadata>
<!-- <CryptographicKeys> -->
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="socialIdpUserId" PartnerClaimType="userId"/>
<OutputClaim ClaimTypeReferenceId="email" PartnerClaimType="email"/>
<OutputClaim ClaimTypeReferenceId="displayName" PartnerClaimType="username"/>
<OutputClaim ClaimTypeReferenceId="authenticationSource" DefaultValue="socialIdpAuthentication"/>
<OutputClaim ClaimTypeReferenceId="identityProvider" DefaultValue="SAMLIdp" />
<!-- We want the Subject/NameID value as a custom employeeId claim. URI reference doesn't work. -->
<OutputClaim ClaimTypeReferenceId="employeeId"
PartnerClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" />
</OutputClaims>
<!--<OutputClaimsTransformations> -->
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Noop"/>
</TechnicalProfile>
I tried using PartnerClaimType values like "NameID", "NameIdentifier", as well as the well-known URI for NameIdentifier
and none of these seemed to work.
I also saw some references to the use of the SubjectNamingInfo element and experimented with it,
but that only seems relevant in defining the token sent to a RelyingParty
and not in reading claims from a token received from an IDP.
Also, what about any other Assertion elements? For example, depending on how an IDP uses it,
I could see a need to read the AuthnContextClassRef value to make a decision about whether
to issue an MFA challenge.
The solution to use assertionSubjectName is definitely correct. In fact, MSFT updated their main documentation page on Dec 20th 2018 to add further information: Define a SAML Technical Profile. That being said - I wanted to add one more note that may help others who come across this behavior. It appears that Azure will NOT map the NameID to your output claim if the NameID element has a "NameQualifier" attribute.
Example - this will map to your output claim:
<Subject>
<NameID>foo#bar.com</NameID>
This will NOT map to your output claim:
<Subject>
<NameID NameQualifier="https://bar.com/realms/foo">foo#bar.com</NameID>
Hopefully this will be helpful to anyone who has run into a situation where "assertionSubjectName" does not appear to work. That being said - it seems that this behavior is not all that desirable and I have reached out to MSFT to find out if this is WAD or not.
For the SAML2 protocol, the value of the NameID element can be accessed by using a PartnerClaimType with the value "assertionSubjectName".
This is mentioned in the "Specifying a technical profile for a SAML 2.0 claims provider" section of
Features part 6
in the Advanced Policies Git repo.
For example, to map the NameID from the SAML Assertion to the "employeeId" claim, set its PartnerClaimType to "assertionSubjectName"
in the OutputClaim claim element.
<OutputClaims>
<!-- Other claims -->
<OutputClaim ClaimTypeReferenceId="employeeId"
PartnerClaimType="assertionSubjectName" />
</OutputClaims>
Another example can be found in
Specifying a technical profile for a SAML 2 excerpt from documentation.docx.
Edit
Per Adam C's answer, this is now documented at
Define a SAML technical profile in an Azure Active Directory B2C custom policy. He also notes that B2C will not map NameID to your output claim if the NameID element has a "NameQualifier" attribute.
In my case, I was trying to extract the NameID from a SAML response where the NameID element had an SPNameQualifier attribute. Using assertionSubjectName was not working.
However, what did work was using the SPNameQualifier attribute value.
For example, suppose your SAML response looks like
<saml:Subject>
<saml:NameID SPNameQualifier="https://bar.com/realms/foo">emp99999</saml:NameID>
</saml:Subject>
To extract the NameID value you can set your claim mapping as
<OutputClaims>
<!-- Other claims -->
<OutputClaim ClaimTypeReferenceId="employeeId" PartnerClaimType="https://bar.com/realms/foo" />
</OutputClaims>
I have set up an Azure B2C tenant and used custom policies to add azure ad as an IDP so that users can sign up with their domain accounts. I can build a custom page where ask them for their email and then redirect them to the proper policy(one for work domain accounts and another for personal emails), so that they do not have to make the choice between work and personal emails. The problem is that I do not want to make the user enter the email once again. Is there a way/option to do this? I basically want to achieve something similar to what the common endpoint of Azure AD does for all accounts.
For a custom policy, if you add the "login_hint" query string parameter to the OpenID Connect authentication request, then you can default the login field to this login hint by adding the "DefaultValue" attribute to the "signInName" input claim for the "SelfAsserted-LocalAccountSignin-Email" technical profile as follows:
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
<DisplayName>Local Account Signin</DisplayName>
...
<InputClaims>
<InputClaim ClaimTypeReferenceId="signInName" DefaultValue="{OIDC:LoginHint}" />
</InputClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="signInName" Required="true" />
...
</OutputClaims>
...
</TechnicalProfile>
The "DefaultValue" attribute references a claims resolver that sets the "signInName" claim type to the "login_hint" parameter of the OpenID Connect authentication request.
See the Set up direct sign-in using Azure Active Directory B2C article for more information about passing the "login_hint" query string parameter.