I'll try to make custom policy for Azure B2C to work with SAML 2.0 identity provider which require all requests to be signed. PartnerEntity parameter includes correct url which metadata defines IDPSSODescriptor element and WantAuthnRequestsSigned="true" attribute.
In custom policy TechnicalProfile I have these metadata elements but none of these seems not to make difference:
<Item Key="WantsSignedRequests">true</Item>
<Item Key="WantsSignedAssertions">true</Item>
<Item Key="XmlSignatureAlgorithm">Sha256</Item>
<Item Key="RequestsSigned">true</Item>
In CryptographicKeys I have SamlMessageSigning and SamlAssertionSigning keys with StorageReferenceId.
Trace logs shows that AuthnRequest is sent, but it doesn't have any Signature -elements so I guess that is the problem why sign-in process fails on identity provider side.
Any ideas how to proceed? Anyone know is it even possible to sign AuthnRequest with Azure B2C custom policy?
Just wanted to update that I got it working. Actual problem was not signing issue.
It seems that trace logs won't show that signed part of the request and I thought it was the problem.
Related
I am trying to use the following article to get ADFS working with Azure AD B2C in the start almost 3 weeks ago it worked and now I am getting this error.
AzureAD B2C ADFS Configuration
The Error I get after providing the credentials into ADFS.
AADB2C90168: The HTTP-Redirect request does not contain the required parameter 'Signature' for a signed request.
I removed my Custom policy and took on a vanilla policy from starter pack and configured ADFS but had the same result.
There is no guidance on AADB2C90168 on the Internet on this error.
For info
The ADFS is using a Public certificate and AzureAD B2C is using a self-signed certificate (as described in Pre-Requisites section).
Any help will be appreciated.
Turning off response signature checking weakens security, so probably not a good idea.
Azure B2C is expecting both the message and the assertion to be signed. By default, ADFS only signs the Assertion.
Run this on your ADFS Server:
Set-AdfsRelyingPartyTrust -TargetName <RP Name> -SamlResponseSignature MessageAndAssertion
In your technical profile for ADFS, add the following key <Item Key="ResponsesSigned">false</Item> to the metadata to see if this corrects your issue or not?
<TechnicalProfiles>
<TechnicalProfile Id="MyADFS-SAML2">
<DisplayName>MyADFS</DisplayName>
<Description>Login with your MyADFS account</Description>
<Protocol Name="SAML2"/>
<Metadata>
<Item Key="RequestsSigned">false</Item>
<Item Key="ResponsesSigned">false</Item>
<Item Key="WantsEncryptedAssertions">false</Item>
<Item Key="PartnerEntity">https://sts.myadfs.com/FederationMetadata/2007-06/FederationMetadata.xml</Item>
</Metadata>
...
</TechnicalProfile>
</TechnicalProfiles>
I am writing a custom policy for Azure B2C. A part of this policy is to use a custom claims provider to get some information from an Azure function and put it in the token. When calling this function a code is required to be put in as a query parameter on the call.
My policy works fine however I don't want to hard code that key or even the URL for the azure function. Is there anyway to set this URL/key as a policy key and refer to it within the policy. This way I won't need to maintain separate policies for each environment.
The metadata section of the claimsprovider in question.
<Metadata>
<Item Key="ServiceUrl">https://azurefuntiongoeashere/api/functionname?code=keygoeshere</Item>
<Item Key="SendClaimsIn">Body</Item>
If you secure your REST API with a conventional method like certificate/basic auth, or OAUTH, you can use a policy key.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/secure-rest-api
Is it possible to customize error messages for invalid credentials using azure b2c custom policy?
Ideally, we would like to show a different error message for invalid credentials, which is “Sorry, unrecognized username or password. Have you forgotten your password?”. Here the entire message is the hyperlink which should redirect to reset password screen.
P.S: We have changed the error messages using custom policy but facing difficulty in having the hyperlink and redirection to reset the password.
Any insight will be helpful.
Thanks in advance
You can customize the error messages by modifying the UserMessageIf* settings for the login-NonInteractive technical profile as follows:
<Metadata>
<Item Key="UserMessageIfClaimsPrincipalDoesNotExist">Email or password is incorrect.</Item>
<Item Key="UserMessageIfInvalidPassword">Email or password is incorrect.</Item>
<Item Key="UserMessageIfOldPasswordUsed">Email or password is incorrect.</Item>
...
</Metadata>
The UserMessageIfInvalidPassword can only hold text, if I am not wrong, so you'll have to resort to workarounds unfortunately. Do you have the reset password mechanism also as a policy/technical profile?
The policies in general link to other policies/technical profiles through links that contain a reference to the ClaimsExchanges. For example, a user SignIn page that has SignUp links at the bottom, will contain a reference to the ClaimsExchange that will be called when the user decides to SignUp instead of SignIn.
In your case, if the password reset mechanism is a separate Policy, it could be possible to convert the policy link to an HTML link, and use the same as the error message for "UserMessageIfInvalidPassword". The policy would show the text, which would be rendered as as an HTML link.
It should also be possible to perform some of this workaround through the JS in the page.
Using Identity Experience Framework and added two custom claims also configured the user inputs.
Changed TrustFrameworkBase based on https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-configure-signup-self-asserted-custom and able to view two text fields while signing up.
But after clicking on the "Create" button, getting the error:
"Unable to validate the information provided."
While signing up, if I am keeping both new fields empty, not getting this error and able to create the user.
i just ran into the same issue, and my solution was that I'm missing the Metadata tags in the "Azure Active Directory" claims provider, so B2C can read/write the extension attributes from the extension store app
<Metadata>
<Item Key="ApplicationObjectId">app object id here</Item>
<Item Key="ClientId">applicationId here</Item>
</Metadata>
See also: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-create-custom-attributes-profile-edit-custom
IT can either be the "default" extension app or your custom created one.
Background
I have an application in which users signup/sign through AD B2C. In the application, there is a link which will redirect to another application which works on SAML so want MS Azure to work as IDP and sends SAML to the third application.
We achieved this in AAD (not AD B2C) through the non-gallery application but getting problems in AD B2C.
We followed this document https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/blob/master/Walkthroughs/RP-SAML.md
but when we hit the URL then it says "AADB2C: An exception has occured".
Base file - https://www.dropbox.com/s/ro6arbs57c43el2/base.xml?dl=0
Extension file - https://www.dropbox.com/s/uqojtk432b3wny1/base_Extensions.xml?dl=0
SignInSaml file - https://www.dropbox.com/s/i950s4bwwagry5k/signinsaml.xml?dl=0
The best thing you could do is work with OIDC first and confirm the policy is working and then overwrite the step where you issue a JWT token with SAML
When working with SAML i have this format
Base
Base-extensions (if you want it - i tend not to)
policy-OIDC (This extends base)
policy-SAML (This extends OIDC)
In the policy SAML I then override my user journey orchestration step that calls the JWTIssuer and then call my SAML token creator
The reason for this approach is B2C has been designed to work with OIDC , you can confirm that the journey is working as expected in OIDC and then switch to your SAML
Id also use the journey recorder, I find the older B2C journey recorder you get better than app insights but both track the same data
After checking my SAML in the office your missing some META data to tell SAML how to behave in your policy
<Metadata>
<Item Key="IdpInitiatedProfileEnabled">true</Item>
<Item Key="RequestsSigned">false</Item>
<Item Key="WantsSignedResponses">true</Item>
<Item Key="ResponsesSigned">true</Item>
<Item Key="AssertionsEncrypted">false</Item>
<Item Key="WantsEncryptedAssertions">false</Item>
<Item Key="PartnerEntity">https://my-calling-application/authservices</Item>
</Metadata>
<SubjectNamingInfo ClaimType="UserId" />
Your SubjectNamingInfo will also need to be
http://schemas.microsoft.com/identity/claims/userprincipalname
as this is the SAAML name you defined in your base policy