I have this kind of internal errors inside our Production B2C environment.
Our Insights in the Relaying Party:
And our AppInsights-Common:
Exception after 2 or 3 409 business validation exceptions:
Any idea how to fix this?
Thanks.
Please check the following:
When you create an instance of Application Insights in your subscription for required resources, make sure to record the INSTRUMENTATION KEY .
and ensure the recorded instrumentation key is provided and developer mode to false in the metadata of technical profile (Don't enable developer mode in production environments.)
<TechnicalProfile Id="AppInsights-Common">
<DisplayName>Application Insights</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.Providers.Insights.AzureApplicationInsightsProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
<Metadata>
<!-- The ApplicationInsights instrumentation key, which you use for logging the events -->
<Item Key="InstrumentationKey">xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</Item>
<Item Key="DeveloperMode">false</Item>
<Item Key="DisableTelemetry ">false</Item>
</Metadata>
<InputClaims>
....
</InputClaim Claims>
Reference: Track user behavior by using Application Insights - Azure AD B2C | Microsoft Docs
or
Make sure to replace {Your Application Insights Key} with the Application Insights Instrumentation Key that you recorded earlier in the user journey.
ex:
<UserJourneyBehaviors>
<JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="{Your Application Insights Key}" DeveloperMode="true" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
</UserJourneyBehaviors>
When using in production environments,i.e; in the configuration in TrustFrameworkPolicy
Please make sure to set the DeploymentMode attribute to Production(not developer)
<TrustFrameworkPolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.microsoft.com/online/cpim/schemas/2013/06" PolicySchemaVersion="0.3.0.0"
.....
DeploymentMode="Production"
UserJourneyRecorderEndpoint="urn:journeyrecorder:applicationinsights">
And change DeveloperMode="false" in userjourney:
<JourneyInsights TelemetryEngine="ApplicationInsights" InstrumentationKey="{Your Application Insights Key}" DeveloperMode="false" ClientEnabled="false" ServerEnabled="true" TelemetryVersion="1.0.0" />
Please check this doc to Troubleshoot custom policies with Application Insights - Azure AD B2C | Microsoft Docs .
And please note that these detailed logs are collected only when the
policy is placed in DEVELOPER MODE.
logs may take a little or some time to populate under app insights.
Also sometimes the order of userjourney may affect the output, try
changing it to other step or order .
Related
We are trying to integrate custom identity provider like NHS Login with Azure ADB2C which provides private key to fetch access token. When we try to login using credentials, we get the error saying "We encountered an error connecting to the identity provider. Please try again later." Is there any source or starting point which we can refer where user has integrated generic custom identity provider like NHS Login with Azure ADB2C successfully and able to fetch access token using private key as token endpoint auth method Azure ADB2C tech profile
(new account so can't comment on the above - but i think the below is useful to this thread).
Jas Suri, Could you possibly expand on the last sentence please, as from what I've experienced, its a requirement?
It is best to use the OAuth2 technical profile to get the most out of
NHS Login platform
I have now got NHS Login working with Azure B2C, but I had initially had the claims tech profile setup as OpenIdConnect, but was getting validation errors:
(IDX10618:
AsymmetricSecurityKey.GetHashAlgorithmForSignature( 'RS512' ) threw an
exception.\nAsymmetricSecurityKey:
'System.IdentityModel.Tokens.RsaSecurityKey'\nSignatureAlgorithm:
'RS512', check to make sure the SignatureAlgorithm is supported)
We have integrated NHS Login with AAD B2C.
The document linked shows two metadata items that make us compatible with NHS Login:
token_endpoint_auth_method: Specifies how Azure AD B2C sends the authentication header to the token endpoint. Possible values: client_secret_post (default), and client_secret_basic (public preview), private_key_jwt (public preview).
token_signing_algorithm: Specifies the signing algorithm to use when token_endpoint_auth_method is set to private_key_jwt. Possible values: RS256 (default) or RS512.
The technical profile will look like this:
<TechnicalProfile Id="NHS-Login-OAUTH2">
<DisplayName>NHS-Login-OAUTH2</DisplayName>
<Description>Login with your NHS account</Description>
<Protocol Name="OAuth2" />
<Metadata>
<Item Key="authorization_endpoint">https://auth.sandpit.signin.nhs.uk/authorize</Item>
<Item Key="AccessTokenEndpoint">https://auth.sandpit.signin.nhs.uk/token</Item>
<Item Key="ClaimsEndpoint">https://auth.sandpit.signin.nhs.uk/userinfo</Item>
<Item Key="client_id">yourClientIdFromNHS</Item>
<Item Key="scope">openid email profile phone profile_extended gp_integration_credentials</Item>
<Item Key="response_mode">form_post</Item>
<Item Key="BearerTokenTransmissionMethod">AuthorizationHeader</Item>
<Item Key="response_types">code</Item>
<Item Key="HttpBinding">POST</Item>
<Item Key="UsePolicyInRedirectUri">false</Item>
<Item Key="token_endpoint_auth_method">private_key_jwt</Item>
<Item Key="token_signing_algorithm">RS512</Item>
</Metadata>
<CryptographicKeys>
<Key Id="assertion_signing_key" StorageReferenceId="B2C_1A_NhsSandpit" />
</CryptographicKeys>
..snip..
NHS Login requires private_key_jwt and RS512. This will use a client assertion to authenticate to the NHS Login /token endpoint.
Take the PEM file which NHS login docs state to generate, and convert it to PFX. Upload that PFX into B2C policy keys. This is referenced in the CryptographicKeys node of the technical profile.
It is best to use the OAuth2 technical profile to get the most out of NHS Login platform.
I'm trying to add a custom policy without refresh token
I've modifiy the ClaimsProviders this way :
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="JwtIssuer">
<DisplayName>JWT Issuer</DisplayName>
<Protocol Name="None" />
<OutputTokenFormat>JWT</OutputTokenFormat>
<Metadata>
<Item Key="client_id">{service:te}</Item>
<Item Key="SendTokenResponseBodyWithJsonNumbers">true</Item>
<Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
<Item Key="token_lifetime_secs">3600</Item>
<!-- 1 H -->
<Item Key="id_token_lifetime_secs">3600</Item>
</Metadata>
<CryptographicKeys>
<Key Id="issuer_secret" StorageReferenceId="B2C_1A_TokenSigningKeyContainer" />
</CryptographicKeys>
<InputClaims />
<OutputClaims />
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
But it's not working.
I'm facing this js error when I try to sign in :
main.js:1 ERROR ServerError: server_error: AADB2C: Issuer technical profile 'JwtIssuer' must specify a 'issuer_refresh_token_user_identity_claim_type' to use this OAuth flow
Correlation ID: bab26044-1e53-4b4a-b5c9-d2f35030a9d7
Any ideas ?
Thanks :)
Thanks for the comment #paralight. We need to apply some workaround to achieve the same as there is no way to remove the refresh token and no direct modifications to the JWTIssuer technical profile.
Workaround:
Force a session time out by adding a tag UserJourneyBehaviors in custom policy. ex :
<UserJourneyBehaviors> <SingleSignOn Scope="Application" /> <SessionExpiryType>Absolute</SessionExpiryType> <SessionExpiryInSeconds>900</SessionExpiryInSeconds> </UserJourneyBehaviors>
Other scenario :
Claims information in the JWT token is exposed to the public. To store some sensitive information in the JWT token
Workaround: You can send claims to a REST API and send them back to B2C to encrypt.
You would create an orchestration step before the SendClaims step to send all claims to a REST API, and have the REST API respond with encrypted versions of those claims
JWT Token issuer reference https://learn.microsoft.com/en-us/azure/active-directory-b2c/jwt-issuer-technical-profile
REST API usage https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-rest-api-claims-exchange
Reference : All Technical Profiles : https://learn.microsoft.com/en-us/azure/active-directory-b2c/technicalprofiles
Reference SO Thread: Modify the JwtIssuer ClaimsProvider in the custom policy to achieve the JWE in AD B2C
Adding your comment as answer and glad to know your queries are addressed. You can accept it as answer( click on the check mark beside the answer to toggle it from greyed out to filled in). This can be beneficial to other community members.
I am using custom policies and I have defined the location of the custom exception page as follows:
<ContentDefinition Id="api.error">
<LoadUri>https://{Settings:BlobStorageAccount}.blob.core.windows.net/{Settings:BlobContainer}/html/global_exception.html</LoadUri>
<RecoveryUri>~/common/default_page_error.html</RecoveryUri>
<DataUri>urn:com:microsoft:aad:b2c:elements:contract:globalexception:1.2.0</DataUri>
<Metadata>
<Item Key="DisplayName">Error page</Item>
</Metadata>
</ContentDefinition>
However, how do you go about triggering an internal API exception within Azure AD B2C to see this page in action? I tried also using a default user policy and adjust the location but there doesn't seem to be a way to view the page that way as well.
You can set the client_id parameter in the authorization request to an unknown value where this should display the error page with the following text:
AADB2C90018: The client id '<client_id>' specified in the request is not registered in tenant '<your_tenant_name>.onmicrosoft.com'.
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 able to retrieve refresh tokens for my custom B2C policies but would like to increase the token lifetime to the max limit or set the sliding window lifetime to No Expiry.
This was able to be done via the Azure Portal B2C settings for Basic policies but is not available in the portal for custom policies.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-token-session-sso#token-lifetimes-configuration
How can I configure this in my policies?
Check out this article.
Specifically add the following in your RP technical profile.
<Item Key="token_lifetime_secs">3600</Item>
Can look like this (copied from docs)
<ClaimsProviders>
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>
<TechnicalProfile Id="JwtIssuer">
<Metadata>
<Item Key="token_lifetime_secs">3600</Item>
<Item Key="id_token_lifetime_secs">3600</Item>
<Item Key="refresh_token_lifetime_secs">1209600</Item>
<Item Key="rolling_refresh_token_lifetime_secs">7776000</Item>
<Item Key="IssuanceClaimPattern">AuthorityAndTenantGuid</Item>
<Item Key="AuthenticationContextReferenceClaimPattern">None</Item>
</Metadata>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>
</ClaimsProviders>
What Parakh said is correct but please take note of the banner on the page that he linked to which says the following about SPA apps with PKCE:
Note
Single-page applications using the authorization code flow with PKCE always have a refresh token lifetime of 24 hours while mobile apps, desktop apps, and web apps do not experience this limitation. Learn more about the security implications of refresh tokens in the browser.
That means that settings such as the following may not be respected for those apps:
refresh_token_lifetime_secs
rolling_refresh_token_lifetime_secs
allow_infinite_rolling_refresh_token
This last one is never respected for SPA w/ PKCE