I've been messing around with MSAL having previously used ADAL for sign up & secure API calls within AAD
I have a user case now requiring sign up and sign in but bafflingly MSAL - even tho there's a method for returning user name - is incapable currently of returning you anything about the user from the B2C token
The workaround seems horribly contrived so I'm considering abandoning MSAL and going back to ADAL or other providing the Sign Up or Sign in is also available
Can anyone recommend me a library or method of achieving Sign Up directly into AAD using ADAL or other please?
is incapable currently of returning you anything about the user from
the B2C token
ADAL supports for v1 endpoint.B2C uses v2 endpoint, and the MSAL is designed to support v2, so you could not use ADAL for the B2C Sign Up. If you want to get user information in the token, suggest you use the OpenId Connect. In the OpenId Connect, the id_token includes the user information.
You could use jwt.io to parse the id_token, and you could find username in the id_token:
For the details about OpenId Connect in B2C, please read here.
ADAL and MSAL are incompatible
MSAL doesn't support Graph
OpenID Connect needs an authorisation code so isn't appropriate for the workflow
The answer I figured out was to install ADAL into my API, then when the user logs in on the app send securely the GUID from the token to the API which can then communicate with the Graph and return user profile info
Related
When I log into Azure AD B2C I don't get the preferred_username claim included id_token. Is there a way to configure this from the Azure portal? Pretty sure I would get this claim in regular Azure AD OIDC implicit flow.
I've tried looking at custom claims but it seems like this should be a built-in claim that gets included or mapped to some attribute.
This is a known issue with B2C and the MSAL libraries.
From the MSAL .NET wiki: B2C does not return a value in the IdToken for the preferred_username because of limitations with the social accounts and external identity providers (IdPs). Azure AD returns a value for preferred_username because it knows who the user is, but for B2C, because the user can sign in with a local account, Facebook, Google, GitHub, etc...there is not a consistent value for B2C to use for preferred_username. To unblock MSAL from rolling out cache compatibility with ADAL, we decided to use "Missing from the token response" on our end when dealing with the B2C accounts when the IdToken returns nothing for preferred_username. MSAL must return a value for preferred_username to maintain cache compatibility across libraries.
If you want to display a value in the UI, you should be able to use the login hint to pass in a username to pre-fill the sign-in UI. As noted in this MSAL .NET issue.
This is a known issue with Azure AD B2C.
This is because Azure AD B2C does not return a value in the IdToken
for the preferred_username because of limitations with the social
accounts and external identity providers (IdPs).Azure AD returns a
value for preferred_username because it knows who the user is, but for
Azure AD B2C, because the user can sign in with a local account,
Facebook, Google, GitHub, etc. there is not a consistent value for
Azure AD B2C to use for preferred_username.
Here is the Workarounds.
Im able to login to my angularjs app using the angular adal library
I can get a token and verify this token. My question is the following:
If i signout, should the token get revoked automatically? If not, how do i do so?
Currently Azure Active Directory does not support or provide an endpoint for an application to revoke the access/refresh tokens.
You may read more about configurable token lifetimes in Azure Active Directory to check the policies on token lifetimes and adjust that base on your requirement .
There is a sample logout code that you may be able to integrate as a workaround.
See: Can Azure AD ADAL (ios) refresh token be revoked from the client?
Completely new to B2C. Tried both of these walkthroughs, but I'm missing something still:
https://github.com/Azure-Samples/active-directory-b2c-advanced-policies/blob/master/Walkthroughs/RP-SAML.md
http://blogs.quovantis.com/saml-based-sso-with-azure-ad-b2c-as-an-idp/
Both of these only describe the policies needed, but I'm pretty sure I need to register an app on B2C still? The problem I have with app registration is that SalesForce gives me a token endpoint URL with a query string:
https://mycompany.cs79.my.salesforce.com/services/oauth2/token?so=00D1h000000Cnli
And B2C won't allow query strings in the reply URL.
Is there any way around this? Salesforce also supports OpenID I think, if that would be better?
::::::::::::UPDATE 6/22::::::::::
SAML:
I found and realized I was missing a critical step on the SalesForce side: adding the authentication provider to my domain's login page. Clicking the new link redirects me to B2C, but I get an immediate error from B2C. Application Insights shows the following exception:
The SAML technical profile 'serviceProviderMetadata' specifies a PartnerEntity URL of 'REMOVED', but fetching the metadata fails with reason 'For security reasons DTD is prohibited in this XML document. To enable DTD processing set the DtdProcessing property on XmlReaderSettings to Parse and pass the settings into XmlReader.Create method.
OpenID:
Using this write-up as a guideline, I've registered the app in B2C and configured the SalesForce side.
Instead of using the Azure AD authorization endpoints, I pulled my B2C tenants endpoints from my meta data URL (login.microsoftonline.com/{tenant}/.well-known/openid-configuration).
This works for my B2C admin account, however, when I try try a test user that isn't a B2C admin I get the following error from the B2C sign-in page:
Sorry, but we’re having trouble signing you in.
AADSTS50020: User account 'REMOVED' from identity provider 'LINK REMOVED' does not exist in tenant 'MTB2CTest' and cannot access the application '5c8b9f4f-cf28-42fe-b629-b87251532970' in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
::::::::::::UPDATE 6/23::::::::::
OpenID:
I’ve found that it works 100% only for my B2C admin account if I don’t use a policy, but doesn't work for other accounts. When I use a policy, only accounts that signed up through the policy can authenticate with B2C (which is great) – but the token doesn’t seem to be reaching SalesForce. I've created two PDFs showing the configuration details and the results from each method (policy and nopolicy) here.
Both of these only describe the policies needed, but I'm pretty sure I need to register an app on B2C still?
Not exactly, you no need to register an app at B2C side. All the configuration you do in Policies is enough.
Did you try Salesforce SAML SSO article https://help.salesforce.com/articleView?id=sso_saml.htm&type=5
Check the above article and try to do configurations at Salesforce side and grab the details required by SAML RP
I hope by following both SAML RP and Configure SAML Settings for Single Sign-On articles you can configure B2C as IDP for Salesforce.
I stumbled on this question while trying to implement Azure AD B2C as an IdP for Salesforce. We used Open ID Connect to enable SSO between the two. This involved setting up an Application in Azure AD B2C, enabling the read scope on that application, and configuring the connection in Salesforce using that application, a custom policy returning a JWT token, and a dummy User Info endpoint.
Check out this answer for exact steps on how we set up Open ID Connect: https://stackoverflow.com/a/61639332/13484109
Sorry I am still very confused, read everywhere telling me oath is a authorisation protocol but it appears using the azure ad oauth code grant, it does promote a login screen to authenticate against the directory, so is it not an authentication process? what is the relationship between the open id connect? thanks!!
the OAuth2.0 protocol has several flows that an identity provider (in your case Azure AD) may implement to support auth.
The Auth Code flow is in fact one of these used by apps to get access tokens for some api. The flow is quite simple, an app redirects the user to the identity providers /authorize endpoint. At this point the user enters their credentials, and the site redirects back to your application with an authorization code and can also issue an ID Token that represents a user (This is the OpenID Connect part). The app takes this code, and POSTs it to the /token endpoint and will be issued an access token and refresh token. With the access token, your app can access whatever api you've requested access for.
For Azure AD specifically, Microsoft has built libraries that handle all these flows and token caching so most of the complexity is abstracted away. There's some simple code samples that you can checkout that you may find helpful. The authentication protocols and scenarios doc for Azure AD may also be really helpful for conceptual information.
In my scenario I have the following architecture elements:
- SAML secured Portal (Domain A)
- User
- SAML secured API( Domain B, so different domain than the portal)
- an IdP
The user will login first to the portal, when not authenticated, the portal will redirect him to the identity provider to login. Once logged in to the IdP and hence to the Portal, the Portal will possess a SAML token identifying the user.
Now this portal will need to automatically call the API (present on another domain), and pass to it a SAML token identifying the user. Problem is that the portal only posses the token that has been provided to him, and hence my question:
How can I propagate the identity of the user through the invocation chain?
For instance, is it possible to share same token between different relying parties? If yes, what are the constraints that the issued token should respect to make sure it can be "shared" by different entities?
Many thanks in advance!
One way could be that the portal rather than calling the API directly, instead should redirect the user to the API.
This way the API will find the user doesn't have a valid session, will redirect to the IdP where the user is already authenticated. The IdP will then redirect back to the API with the SAML response for the API.
This will all be transparent to the user, who will just see the result from the API.