While creating a custom IDP for my Azure AD B2C service I get the following error:
I did validate the JSON content for the JWKS endpoint on an online json lint and it validated it fine. Is there any specific expected format of the JSON content?
You should be providing the well known OIDC endpoint. The JWKS URI is referenced from within the well known OIDC endpoint.
Related
I am creating a custom policy to use Azure B2C as an IdP to integrate with a legacy auth service. The legacy service and the new IdP share a secret.
The legacy auth service has a custom authentication flow and requires that an HMACSHA256-based challenge token is sent to it as part of its Auth process using the shared secret as the key.
I am unable to find a way to create/transform a token to an HMACSHA256-based output claim. What are the recommended patterns to address a situation such as mine?
I tried https://learn.microsoft.com/en-us/azure/active-directory-b2c/general-transformations#hash
but the computed hashes do not match.
Azure AD B2C doesn't create or transform HMACSHA254 token.
Also, it is not possible to do transformations on the resulting token. Claim transformation will only apply to claims in the claims bag.
I would like to implement JWT SSO for Zendesk with Azure AD B2C custom policies. For some internal reasons, we cannot use SAML.
My problem is Zendesk requires that the return URI respect the format
https://yoursubdmain.zendesk.com/access/jwt?jwt={payload}
But by default, using Microsoft samples, the return uri is :
https://yoursubdmain.zendesk.com/access/jwt#id_token={payload}
I am new user of custom policies, I have no idea how I can change the format of the Redirect URI.
You cannot change the way AAD B2C return the tokens in the query parameters. You might have to build a proxy to transform the response from AAD B2C and send it to zendesk. Or use SAML.
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.
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
Entering the AWS management console, how does one build an SSO solution where authentication is done against Azure AD but authorization level is in AWS IAM?
Azure AD SAML claim will not include any security group data, since we don't want to overload SAML token with metadata. Same applies to Kerberos tickets. Hence using the Azure AD Graph API is out of question as well.
Basically the SAML assertion will only include data about authenticated user.
The AssumeRoleWithSAML API is role-driven, whereas we would need a SAML based solution that is user-driven (mapping incoming user data with IAM user). Any help is welcome.