AD FS is configured with custom policies as a claims provider on Azure AD B2C using either WS-Federation and SAML 1.1 or SAML 2.0.
Do Azure AD B2C expose a metadata endpoint as relying party which can be used by the AD FS when configuring Azure AD B2C as relying party?
I'm interested in both WS-Federation/SAML and SAML 2.0 metadata.
** Edited **
The following metadata url do not work: https://login.microsoftonline.com/te/<yourtenant>.onmicrosoft.com/b2c_1a_<yourpolicy>/Samlp/metadata
When the metadata is called the following error is returned:
Azure AD B2C does expose a metadata endpoint when using Custom Policies.
It can be found at this URL:
https://login.microsoftonline.com/te/<yourtenant>.onmicrosoft.com/b2c_1a_<yourpolicy>/Samlp/metadata
EDIT: B2C as a SAML RP is not officially supported at this time, however it is possible to enable it via custom policies. If you are interested in this feature, make sure to vote for it in order to support it and get updates on its progress.
There is no good documentation on how to do this outside of these docs:
Outdated walkthrough, compliment it with the StackOverflow posts below.
Azure Active Directory - Custom Policy Error
Issue when calling New-CpimCertificate for Azure AD B2C custom policy
At the moment of writing SAML2 metadata endpoint works with this idptp=TechnicalProfile-id variabel:
https://login.microsoftonline.com/te/<yourtenant>.onmicrosoft.com/b2c_1a_<yourpolicy>/Samlp/metadata?idptp=<TechnicalProfile-id>
This TechnicalProfile must have the following definitions:
<Protocol Name="SAML2"/>
<CryptographicKeys>
<Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_ADFSSamlCert"/>
<Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_ADFSSamlCert"/>
</CryptographicKeys>
P.S. Microsoft should really document these features.
Related
I have an AAD B2C custom policy that has AAD and Microsoft as claims providers, I have tried adding "picture" as an output claim, but that doesn't work.
<OutputClaim ClaimTypeReferenceId="picture" PartnerClaimType="picture" />
Simply doing this for Google as the claims provider does work. What can I do to have a claim that will output the picture url in the token for AAD and Microsoft?
I am currently creating sign-up(CombinedSignInAndSignUp) page using custom policies. I was wondering if it is possible to have a sign-up page with the social IDP selection (Facebook, Linkedin) and SignUpWithLogonEmailExchange button.
Based on the Social IDP you are selecting, you have to create different technical profiles for each.
Technical profiles are the mechanisms that are used to interact with the party (Facebook/LinkedIn) defined within ClaimsProvider definition whereas ClaimsProvider defines a party that the custom policy interacts with.
To configure LinkedIn as an identity provider:
In the extension file of your policy, define a LinkedIn account as a claims provider by adding it to the ClaimsProviders element.
Open the SocialAndLocalAccounts/TrustFrameworkExtensions.xml file in your editor and find ClaimsProviders element
If ClaimsProviders element does not exist, add it under the root element
Add a new ClaimsProvider
Replace the value of client_id with the client ID of the LinkedIn application and Save.
To configure Facebook as an identity provider:
In the SocialAndLocalAccounts/TrustFrameworkExtensions.xml file, replace the value of client_id with the Facebook application ID:
<TechnicalProfile Id="Facebook-OAUTH">
<Metadata>
<!--Replace the value of client_id in this technical profile with the Facebook app ID"-->
<Item Key="client_id">00000000000000</Item>
Please find below links if they are helpful,
References:
Ref1
Ref2, Ref3, Ref4
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
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