We integrate a SAML Application to Azure AD B2C with a custom policy. The user journey works well.
We have a Claim which holds an ErrorStatus and ErrorMessage as well of a hasError claim based on different checks and mechanisms. For all of our apps which works with an JWTIssuer we can check the claims and reply with an OAuth2Error (described in OAuth2 custom error).
How can we implement a custom samlp:Status response?
We could not found a similiar approach for a SAML App.
We can use the approach of a SelfAsserted-BlockLoginPage (described here).
In this case the user need to click on cancel and will then be redirected to the app with the following SAML Response.
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:AuthnFailed" /></samlp:StatusCode>
<samlp:StatusMessage>The user has cancelled entering self-asserted information.</samlp:StatusMessage>
</samlp:Status>
</samlp:Response>
We want to use a direkt SAML response with a custom status message other then a SelfAsserted-BlockLogin approach, but we can't find SAML2 custom error technical profil.
Related
I've followed the steps from https://learn.microsoft.com/en-us/azure/active-directory-b2c/saml-service-provider?tabs=windows&pivots=b2c-custom-policy
While testing receiving the error "Application registered corresponding to IssuerUri "">xyz.com/suite" in AuthRequest does not have assertion consumer service URL "">xyz.com/suite/saml/AssertionConsumer" specified in its metadata.</samlp:StatusMessage>"
Using SAML tracer, I can see both my SAML Request and Response contains same AssertionConsumerServiceURL.
MS document says: If you choose to configure the reply URL and logout URL in the application manifest without populating the application's metadata endpoint via the samlMetadataUrl property, Azure AD B2C will not validate the SAML request signature, nor will it encrypt the SAML response.
I can some workaround of specifying the PartnerEntity in the SP metadata URL for the Relying Party in the B2C_1A_signup_signin_saml custom policy.
https://github.com/MicrosoftDocs/azure-docs/issues/61603
Unfortunately my web application security compliance does not allow to provide SP metadata endpoints.
Do I need to host the SP / Appian SAML metadata file on Azure Storage account OR Is this mandatory to provide SP meta data endpoint to refer from Idp application registration manifest?
Second question, just want to make sure on the below.
From MS Ref. doc: You can change the value of the IssuerUri metadata item in the SAML token issuer technical profile. This change will be reflected in the issuerUri attribute returned in the SAML response from Azure AD B2C. Your application should be configured to accept the same issuerUri during SAML response validation.
My question on the above paragraph,
IssueUri example can be .onmicrosoft.com/c3bcfc1c-1234-4a3b-96e6-db0933071234 (application / client id) Is this correct?
Thanks.
"The username or password provided in the request are invalid" - This issue has been resolved by granting "IdentityExperienceFramework" (User_impersonation - Delegated Type) API permission. I could not see this solution on MS documents guidance, however this has resolved my issue. thanks.
The cx needs to set up a dynamic response in the sign in policy, B2C, that depending on the scenario, a custom message is displayed / triggered. Specifically:
I need to create new IDs with new message. Is it possible? Thanks.
ID Default message Localized / customized message
UserMessageIfInvalidPassword Your password is incorrect
UserMessageCustomID1 Your trial has expired
UserMessageCustomID2 No license aliable. Please contact support#...
This is what the cx is trying, and have done already:
This actually is piece of code in the REST API (in PHP). I defined the following ClaimsProvider which reference to that PHP file and then included it in the TrustFrameworkExtensions.xml file. I hope this information helps. Thank you.
So, it loops back to my question, I don't know how to display a custom error message either from a REST API call or with a predefined ID (e.g., a self-defined ID UserMessageNoEnoughLicense just like a predefined ID UserMessageIfInvalidPassword).
I'm referring to this document https://learn.microsoft.com/en-us/azure/active-directory-b2c/localization-string-ids.
You can make use of your RESTful API in your SISU policy/flow. Design the integration with the RESTful services in the following ways:
Validation technical profile: The call to the RESTful service happens within a validation technical profile of the specified self-asserted technical profile, or a verification display control of a display control. The validation technical profile validates the user-provided data before the user journey moves forward. With the validation technical profile, you can:
Send claims to your REST API.
Validate claims, and throw custom error messages that are displayed to the user.
Send back claims from the REST API to subsequent orchestration steps.
Claims exchange: A direct claims exchange can be configured by calling a REST API technical profile directly from an orchestration step of a user journey. This definition is limited to:
Send claims to your REST API.
Validate claims, and throw custom error messages that are returned to the application.
Send back claims from the REST API to subsequent orchestration steps.
You can add a REST API call at any step in the user journey defined by a custom policy. For example, you can call a REST API:
During sign-in, just before Azure AD B2C validates the credentials.
Immediately after sign-in.
Before Azure AD B2C creates a new account in the directory.
After Azure AD B2C creates a new account in the directory.
Before Azure AD B2C issues an access token.
Then, use the error message response from the API to override the message IDs mentioned here.
RESTful error messages can be found here.
You can visit this link for more information on how to implement it: https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-rest-api-intro#sending-data
We created an application in Azure B2C to use the OIDC implicit Grant flow. We have configured the Userflow policy(SignIn and SignUp) to customize the homepage layout and to get the custom claims in response. We are using Azure B2C as External Identity Provider (IdP) in our application. When user clicks the Login Button in our application we are redirecting the user the Azure B2C for Authentication and we are able to get the Access Token in response. But we are facing constrain in Getting the User Profile through the UserInfo enpoint. We have tried out both the Graph API endpoint and Azure B2C OIDC userinfo enpoint but neither of them are compatible with the Userflow policy.
I believe the workaround suggested is applicable only if we need to grab some extra input from user (during sign-up) or input validation and then pass that claim to application. It will unnecessary require using "Identity Experience Framework" feature which is ideally required for custom login/signup journey and is not available under free license.
What I understand from you requirement is you need to pass built-in Azure AD attributes to application and which shall be doable by selecting extra claims from "User Flow" signup-SignIn policy. Is not there any alternative to make call to "userinfo" endpoint out of box ?? Any Microsoft expert here, please clarify.
As of now, Azure AD B2C does not support the UserInfo endpoint through User-flow policy.
Right now, it is being supported only through Custom Policies.
You can vote for this feature on Azure AD User Voice.
A workaround is that you could integrate a Rest API to retrieve the extra claims.
See reference here.
I have a multiple applications that use the same custom policy to authenticate user. In TrustFrameworkExtensions I defined two claims provider, one for local account and one for user of my company AD tenant (social account) , I have also a claims provider for retrieve custom attributes and for check if the user is enabled for the caller application, this claims provider is configured in user jorney like a orchestration step before the JWT token is created.
The API Application return claims with custom attributes if the user is enabled and return a response with HttpStatusCode.Conflict and error message if not.
How can show the error message in the login form before it back to the calling application?
PS: I have a custom UI login form
UPDATE
I found a right technical profile "SelfAsserted-LocalAccountSignin" and now works ! But I have 2 more questions.
1. In my api application, in input claims, extension property are missing , I think it's because the user not logged yet, is it possible obtain all claims ? If this isn't possibile I must read data in my api with Graph
by signinName.
2. My login form allows authentication as a local user and as a user of my company AD tenant (social account).
The ValidationTechnicalProfiles in "SelfAsserted-LocalAccountSignin"
works with local user only, I tried to configure a ValidationTechnicalProfiles for "SM-SocialLogin" TechnicalProfile but doesn't work
Background
I have two applications registered in azure, one is a web-based client and the other is a web-based service. The setup is similar to the example found here: https://github.com/Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi
The user logs in to the client via azure b2c, and then the client queries against the service, authenticated via azure b2c, to obtain its data.
The Problem
The service is not receiving the expected claims in the bearer token.
Specifics
Azure B2C says that the claims you select for a given policy will be included in "a token", which I assumed would be the bearer token. Below is a screencapture of some of the claims I have selected.
However, on the service when I extract the claims from the bearer token, I get none of the promised claims. Instead, I get the claims shown below.
I am using UseOAuthBearerAuthentication identical to the example provided by microsoft on github (linked above).
Am I missing something?
How do I get the claims that b2c promises?
Application Claims are included in the id_token, not the access_token (aka bearer token).
This means that the Select application claims will allow your client application (native app or web app) to access these custom claims.
If you want to access custom claims from your back-end service, you'll need to call the Azure AD Graph using the client credentials flow and call the user endpoint like so:
https://graph.windows.net/<yourtenant.onmicrosoft.com>/users/<userId>
And retrieve the property with the following format:
extension_<b2c-extensions-app_appId>_<customAttributeName>
For example:
extension_e5bf5a2db0c9415cb62661a70d8f0a68_MyCustomAttribute
You can obtain the id of your B2C tenant's b2c-extensions-app via the Graph as well:
https://graph.windows.net/<yourtenant.onmicrosoft.com>/applications?$filter=displayName eq 'b2c-extensions-app'
See this post for more info:
Moving Azure AD B2C custom user attributes across new environments