I configured a custom b2c policy for the sign-up/sign-in flow that uses SAML for token exchange.
I would like to understand how to control the token lifetime (SAML) and session duration.
The session duration should be 4 hours, to prevent the user from continuing to re-enter credentials I would like to be able to configure an idle timeout so that the session is disconnected if there is no interaction.
Also I would like if the user closes the browser without logging out, when reopened it will prompt for credentials
Is all of this possible? At the moment I'm not using offline_access scope on app registration.
offline_access scope app registration not enabled
At the moment I have only tried putting this in my RP file:
<RelyingParty>
<DefaultUserJourney ReferenceId="SignUpOrSignInMFAOption" />
<UserJourneyBehaviors>
<SingleSignOn Scope="Application" />
<SessionExpiryType>Rolling</SessionExpiryType>
<SessionExpiryInSeconds>900</SessionExpiryInSeconds>
</UserJourneyBehaviors>
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2" />
PFB answers to your ask as follows:
Control the token lifetime (SAML) and session duration
To define a session duration for SAML you could use "TokenLifeTimeInSeconds" in Saml2AssertionIssuer technical profile metadata.
As per https://learn.microsoft.com/en-us/azure/active-directory-b2c/saml-issuer-technical-profile#metadata TokenLifeTimeInSeconds specifies the life of the SAML Assertion. This value is in seconds from the NotBefore value referenced above. The default value is 300 seconds (5 Min).
I would like if the user closed the browser without logging out, when reopened it will prompt for credentials
This could be achieved for local accounts only by removing /excluding Keep me signed in (KMSI) claim, when you enable the feature, users can opt to stay signed in, so the session remains active after they close the browser. The reference sample could be found https://github.com/azure-ad-b2c/unit-tests/blob/main/session/Session_KeepAliveInDays.xml
Also, the SAML IDP metadata should have ForceAuthN set to true
Passes the ForceAuthN value in the SAML authentication request to determine if the external SAML IDP will be forced to prompt the user for authentication. By default, Azure AD B2C sets the ForceAuthN value to false on initial login. If the session is then reset (for example by using the prompt=login in OIDC) then the ForceAuthN value will be set to true. Setting the metadata item as shown below will force the value for all requests to the external IDP. Possible values: true or false. Ref: https://learn.microsoft.com/en-us/azure/active-directory-b2c/saml-identity-provider-technical-profile#metadata
Please do let me know if you have any further queries for me in the comments section.
Thanks
Related
I am looking to capture an email address from a specific internal domain during signup, but I don't want to users to enter the domain portion of the address. However I am trying to figure out the best way to signal the user to NOT enter the domain.
I would like to customize the default login page to include the domain shown after the textbox, something like below.
I know I could write a whole custom UI page to do this, but I was hoping to be able to do this with just a simpler customization of the default UI. Is this possible?
• I would suggest you to please use the ‘login_hint’ and ‘domain_hint’ query parameters in the 2C custom policy regarding the need to show a domain name during the signup user flow. By specifying the ‘login_hint’ parameter in the signup custom policy, Azure AD B2C automatically populates the sign-in name while the user only needs to enter the password for his credentials though the user gets the option to change the sign-in name that is automatically populated from the custom policy to enter the sign-in name of his choice.
Similarly, regarding the domain, the ‘domain_hint’ query parameter provides a hint by auto-populating the domain name for the social IDP for which the sign-in is recommended. These two options mostly satisfy your requirement of not requiring a user to enter the domain name during login. Kindly find the below samples of the above query parameters for your reference: -
Domain hint: -
<ClaimsProvider>
<!-- Add the domain hint value to the claims provider -->
<Domain>facebook.com</Domain>
<DisplayName>Facebook</DisplayName>
<TechnicalProfiles>
...
Login hint: -
<ClaimsProvider>
<DisplayName>Local Account</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="SelfAsserted-LocalAccountSignin-Email">
<InputClaims>
<!-- Add the login hint value to the sign-in names claim type -->
<InputClaim ClaimTypeReferenceId="signInName" DefaultValue="{OIDC:LoginHint}" />
</InputClaims>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
For more information on the above, kindly refer the below documentation links: -
https://learn.microsoft.com/en-us/azure/active-directory-b2c/direct-signin?pivots=b2c-custom-policy
Azure B2C with domain hint instead of IdP buttons
I created my Azure AD B2C custom policies to authenticate users.
I also added a custom attribute to ask the user for a unique information, something like the SSN.
I've already set the custom attribute as required and I put a restriction based on a regex, but I can't find a way, in the docs, to verify if the value already exists in the directory and give an error if that condition is true while the user signs up.
In this question, the suggestion is to call a rest api that uses Microsoft Graph Api to verify if the value set to the custom attribute already exists:
Azure B2C: Querying AAD using a custom claim?
Is it the only solution or, meanwhile, has been released a way to do this check directly from Azure AD B2C custom policy?
Add a technical policy like:
<TechnicalProfile Id="AAD-UserReadUsingEmailAddress">
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="extension_attribute"/>
</OutputClaims>
</TechnicalProfile
This "merges" with the TP in the base so that when your policy reads AAD, it will also read your extension attribute.
Then in your user journey add a precondition of "ClaimsExist".
I have two different redirect URIs in my webapp like localhost:4200 and localhost:4201. Trying to have single-sign-on for these two. Based on this document https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior?pivots=b2c-custom-policy#configure-azure-ad-b2c-session-behavior, I
changed my session behavior and SSO configurations and added a UserJourneyBehaviors element inside of the RelyingParty element. It still asking to sign-in localhost:4201, though i have signed in localhost:4200
<UserJourneyBehaviors>
<SingleSignOn Scope="Tenant"/>
<SessionExpiryType>Absolute</SessionExpiryType>
<SessionExpiryInSeconds>1200</SessionExpiryInSeconds>
<ScriptExecution>Allow</ScriptExecution>
</UserJourneyBehaviors>
Why we need multiple token requests:
We're using implicit flow for our SPA to get access tokens from Azure AD B2C to access APIs that are protected by the B2C. We need to access multiple APIs and those are all registered as different applications in B2C, hence different audience for each. Since they are all different audience, B2C doesn't support a single token request for multiple audiences, so we'd have to make multiple token requests.
Background on B2C setup
We support local account login, as well as social login which is using our other Azure AD identity provider. We're also using custom policies for our B2C (identity experience framework)
The issue
The issue happens for user using the Azure AD login social login. The user has logged in before.
When multiple requests are made, we noticed the following network trace in google chrome:
The trace above showing:
Line 1 & 2 are the token request to B2C authorize endpoint for 2 different api/scope/audience.
Line 3+4 & line 5+6, those are redirects to login.windows.net and login.microsoftonline.com both as 1 set for a particular api/scope/audience.
Line 7 & 8 are both the the response (id token) form post back to B2C. The line 7 returns a bad request response from the form post.
The questions
Why the need to redirect back to login.windows.net or login.microsoftonline.com? Since the user has logged in before, shouldn't he has a valid session and thus B2C can just return the token requested?
Can B2C support concurrent token request (or login) from the same browser for social login identity? We're suspecting this is due to the auth state that B2C expect from social login is only one and unique, so concurrent login causes this to override each other which then cause the other request to be invalid. There is no details at all on the bad request response. It just shows a blank page with "Bad request" text.
-- Update March 5th, 2019 --
After some tinkering on B2C custom policies, I've managed to suppress the redirects, after having logged in once, by changing the following:
<TechnicalProfile Id="SM-SocialLogin">
<DisplayName>Session Mananagement Provider</DisplayName>
<!--Changed to this provider instead of ExternalLoginSSOSessionProvider-->
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.DefaultSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<PersistedClaims>
<PersistedClaim ClaimTypeReferenceId="alternativeSecurityId" />
<PersistedClaim ClaimTypeReferenceId="objectId" />
... removed for brevity ...
<PersistedClaim ClaimTypeReferenceId="groups" />
</PersistedClaims>
<OutputClaims>
<OutputClaim ClaimTypeReferenceId="objectIdFromSession" DefaultValue="true"/>
</OutputClaims>
</TechnicalProfile>
Changes made is to use default session provider.
Why the external session provider would not suppress re-authenticating though? The metadata AlwaysFetchClaimsFromProvider set to false would not suppress re-authenticating as well.
But going with this workaround cause us another problem which is asked in a separate question.
I’m currently trying to follow the guide here to setup our AADB2C IDProvider as a RP to Salesforce using Saml2.
Although the initial few steps are ok…
The new salesforce button is displayed in the login page.
When pressed leads me to the salesforce login page
I can login into salesforce.
The issue occurs when I am redirected back to AADB2C:
https://login.microsoftonline.com/te/{tenantname}.onmicrosoft.com/B2C_1A_TrustFrameworkBase/samlp/sso/as
results in a 404 File or resource not found.
Do you know if this is the correct url to redirect back to AADB2C?
I’ve tried to use App Insights analytics (trace) but cannot find any issue in there (I believe because the issue is not logged as the resource not found)
On the bigger picture, my base custom policy is setup for openid, but this salesforce policy is setup to follow a user journey that consumes saml2 … how does that work for it to be able to understand both protocols?
If I change setup on the RP policy from openid to saml2
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="OpenIdConnect" />
<TechnicalProfile Id="PolicyProfile">
<DisplayName>PolicyProfile</DisplayName>
<Protocol Name="SAML2" />
I can then access to saml metadata on that policy, but I lose capability of testing it up using Azure dashboard. Is there a way I can test it then?
Any help will be appreciated.
Yes, you need to set up the certificate in aadb2c. Also, you need to ensure that the Reply URL and Redirect URIs are matching, and the App ID matches the Client ID.