We have a .Net 6 website that integrates with Azure AD B2C using OIDC. Login and registration for the website are defined in custom policies in the Azure AD B2C tenant. Azure AD B2C returns a claim that we use for user creation and login for existing users.
The client would like the website to integrate with another platform that supports SAML SSO to Azure AD B2C. Basically, if users are signed in to the website, and by extension signed into Azure AD B2C, and they click a link on the website to take them to the other platform then the user should be signed into the other platform.
My question is if we can mix OIDC and SAML in the custom policies so that logging into the website logs the user into the other platform or does it need to be either OIDC start to finish or SAML start to finish.
I have looked into the Microsoft documentation and it explains how to integrate Azure AD B2C with either OIDC or SAML but I couldn't find anything related to integrating Azure AD B2C with separate platforms that use different protocols.
Any help is greatly appreciated.
I am not sure if understand your use-case correctly - are you trying to onboard external partner as identity provider? And their identity provider uses SAML2 protocol?
If yes, you can look at this official page - https://learn.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-generic-saml?tabs=windows&pivots=b2c-custom-policy
Basically you need to use custom policy. In a nutshell, custom policy orchestration flow redirects to identity provider, user authenticates with its own credentials. If successfully, the idp issues SAML token, redirects back to B2C.
And then you can process/transform those claims in SAML token, even create reference/federated user in your b2c (add your own attributes/claims in B2C user management portal) and send claims as JWT token back to your app.
Peter
Related
I have an Azure AD B2C in Tenant A. A SPA web app (FE) and an API Functions App (Node.js) in Tenant B.
FE is using MSAL to require login with Azure AD B2C. I want the set up Authentication in the API to accept bearer access token from FE.
How can I configure Azure to achieve that?
The Tenant that has your Azure Subscription which in turn has your resources doesn't really have to be the one used for App Level Authentication. It is just required RBAC.
The App Registrations for both could just be in the Azure AD B2C Tenant directly and you could provide the required details when setting it up like below
I have a webforms app running on .net 4.7.2, currently being hosted on Azure as a SaaS. It is a single software for multiple clients, each one with its own database.
Currently the user authentication is manually handled by us, but we are trying to implement a multi tenant strategy, using the AzureAD and OWIN tools.
The app service has an Identity Provider configured, from a test AAD. We can login with the provided credentials, but I can only configure a single microsoft identity provider.
I'm not sure where to go from here... After hours reading the multiple docs from microsoft, i'm still stuck.
By default, web app/API registrations in Azure AD are single tenant. You can make your registration multi-tenant by finding the Supported account types switch on the Authentication pane of your application registration in the Azure portal and setting it to Accounts in any organizational directory. So that people from other azure ad tenants will login.
multi-tenant SaaS web application sample
If in case if you want to use other identity providers, You can federate with IdPs that use the SAML protocol. SAML/WS-Fed IdP federation allows external users to redeem invitations from you by signing into your apps with their existing social or enterprise accounts. Federation with SAML/WS-Fed identity providers
And we have azure ADB2C, Azure Active Directory B2C provides business-to-customer identity as a service. Your customers use their preferred social, enterprise, or local account identities to get single sign-on access to your applications and APIs.
Reference Docs:
Sign in any Azure Active Directory user using the multi-tenant application pattern
Azure Active Directory B2C
I am building an asp.net core web API project, with Angular client for front-end. We are using azure b2c as our IDP server, (for registration, authentication and related topics). So far the experience is great.
The issue we are having right now, is that we are trying to add 'admin' role to some of our users, who will be allowed to reach some endpoints of our web API, and do some operations that normal users won't be allowed to.
Since we are using asp.net5 web API for our back-end, in a normal environment, this would be done through [Authorize (Role = "Admin")] attribute, however in Azure b2c it seems not a straight forward thing to do.
Right now, we need 2 types of user roles: User role and Admin role.
Anyone knows how to add user roles in a azure b2c app, and then protect the back-end API endpoints for those roles?
Thank you!
There is no out-of-the-box support for RBAC / Roles in Azure AD B2C. However there are a lot of samples in the official GitHub repository. For example the "Implementing Relying Party Role Based Access Control" or "User consent for API Scopes".
These are the ways to implement RBAC using Azure AD B2C.
I am trying to integrate a Google Identity Platform SAML provider with Okta. Typically the flow that have used to use a GIP provider, is this process where you provide the provider ID, and wait for the callback. This works correctly with Okta as an identity. However, in order to create the Okta integration, (and allow the user to click the application and be taken to the website) you need to provide the ACS(assertion consumer service), which in this case would be https://my-app-12345.firebaseapp.com/__/auth/handler however when this is posted to, and a SAML response received, there is no way to redirect to our web page. Is there a way to use the SAML Provider's ACS directly, but still return the result to a JS web page?
Question:
I am trying to integrate a Google Identity Platform SAML provider with Okta. Typically the flow that have used to use a GIP provider, is this process where you provide the provider ID, and wait for the callback. This works correctly with Okta as an identity.
Answer:
(1) Okta supports the third party SAML identity provider such as Google Identity Platform or Shibboleth IdP.
(I) Google Identity Platform is SAML identity provider. Okta is SAML service provider.
(II) Okta is SAML identity provider. Web application (such as Office 365, Salesforce, Dropbox, Box, etc.) is SAML service provider.
(2) A user can log in to a web application via Okta by using the credential of the third party SAML identity provider of Okta.
I have validated the following user identity federation procedure for Salesforce (a web application) from the web application perspective:
(I) A user accesses their Salesforce organization domain (such as https://example.my.salesforce.com/)
(II) Select Log In with a Different Provider > Okta with Google Identity Platform
(III) The user is redirected to Google Identity Platform via Okta
(IV) The user submits their Google G Suite username/password credential (e.g., winston.hong#example.com )
(V) The user is redirected back by Google Identity Platform and Okta, and then is logged in to their Salesforce account successfully.
Note that the user's username for Google Identity Platform, Okta account and Salesforce account is the same, i.e., winston.hong#example.com for their organization example.com
Question:
However, in order to create the Okta integration, (and allow the user to click the application and be taken to the website) you need to provide the ACS(assertion consumer service), which in this case would be https://my-app-12345.firebaseapp.com/__/auth/handler however when this is posted to, and a SAML response received, there is no way to redirect to our web page. Is there a way to use the SAML Provider's ACS directly, but still return the result to a JS web page?
Answer:
(1) As a SAML identity provider, Okta supports both SAML SP-Initiated flow and SAML IdP-Initiated flow.
As a SAML service provider, Salesforce supports SAML SP-Initiated flow.
(2) In order to create the Okta integration and allow the user to click the application and be taken to the website (such as Salesforce organization domain https://example.my.salesforce.com/), you do NOT need to provide the ACS (assertion consumer service) URL, Instead, you need to provide the organization domain of Salesforce, i.e.,
Application label Salesforce.com
Instance Type Production
Custom Domain example
(3) A user can log in to a web application via Okta by using the credential of the third party SAML identity provider of Okta.
I have validated the following user identity federation procedure for Salesforce (a web application) from the Okta perspective (This is your use case):
(I) A user accesses their Okta organization domain (such as https://example.okta.com/)
(II) Click Need help signing in? and then click Log in with Google
(III) The user is redirected to Google Identity Platform
(IV) The user submits their Google G Suite username/password credential (e.g., winston.hong#example.com )
(V) The user is redirected back and then is logged in to their Okta account successfully
(VI) On their Okta home screen, the user click Salesforce application icon
(VII) The user is redirected to their Salesforce organization domain, and then is logged in to their Salesforce account successfully.
Issue:
Quote "however when this is posted to, and a SAML response received, there is no way to redirect to our web page. Is there a way to use the SAML Provider's ACS directly, but still return the result to a JS web page?"
Resolution:
(1) This is exactly SAML SP ACS issue of your web application https://my-app-12345.firebaseapp.com/__/auth/handler.
(2) You have to either modify the SAML SP configuration of your web application or modify the SAML SP source code of your web application, because the SAML SP ACS endpoint of your web application does NOT redirect to your web application page after verifying SAML signature sent by Okta SAML IdP.
(3) I have validated the following user identity federation procedure for Shibboleth SAML SP demo application (a web application parallel to your web application) from the Okta perspective (This is your use case):
(I) A user accesses their Okta organization domain (such as https://example.okta.com/)
(II) Click Need help signing in? and then click Log in with Google
(III) The user is redirected to Google Identity Platform
(IV) The user submits their Google G Suite username/password credential (e.g., winston.hong#example.com )
(V) The user is redirected back and then is logged in to their Okta account successfully
(VI) On their Okta home screen, the user click Shibboleth SAML SP demo application icon
(VII) The user is redirected to Shibboleth SAML SP demo application, and then is logged in to their Shibboleth SAML SP demo application successfully.
(4) The configuration of a general SAML SP application through Okta Admin GUI
Shibboleth SAML SP demo application (parallel to your web application my-app-12345.firebaseapp.com)
Applications > Shibboleth SAML SP demo > SAML Settings
Single Sign On URL https://samlsp.example.com/Shibboleth.sso/SAML2/POST
Recipient URL https://samlsp.example.com/Shibboleth.sso/SAML2/POST
Destination URL https://samlsp.example.com/Shibboleth.sso/SAML2/POST
Audience Restriction https://samlsp.example.com/Shibboleth.sso/Metadata
Note that Single Sign On URL is ACS URL of SAML SP of your web application.
(5) How to build and run Shibboleth SAML IdP and SP using Docker container at GitHub repository provides the instruction on building your own IDP for SAML in Java using Shibboleth SAML IdP and OpenLDAP.
Shibboleth SAML IdP is responsible for identity federation.
OpenLDAP is responsible for identity authentication.
(I) I have validated SAML Single Sign-On (SSO) provided by Docker-running Shibboleth SAML IdP (Identity Provider) and OpenLDAP for the following enterprise applications. In other words, I leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to the following enterprise applications successfully.
Microsoft Office 365
Google G Suite
Salesforce
Dropbox
Box
Amazon AWS
OpenStack
Citrix NetScaler
VMware vCloud Director
Oracle NetSuite
(II) I have also leveraged Docker-running Shibboleth SAML IdP and OpenLDAP to log in to Salesforce and Shibboleth SAML SP demo application via Okta successfully.
Shibboleth SAML IdP is SAML identity provider (parallel to Google Identity Platform), Okta is SAML service provider.
Okta is SAML identity provider. Web application (such as Salesforce and Shibboleth SAML SP application) is SAML service provider.
(III) For your convenience, I have made the 11th commit to upload the Okta SP metadata and corresponding SAML configuration to How to build and run Shibboleth SAML IdP and SP using Docker container.
Note that I have logged in to Salesforce organization "example.com" account (https://example.my.salesforce.com) with username "winston.hong#example.com" successfully via Okta by using Shibboleth IdP running with Docker Container.
(IV) How to build and run Shibboleth SAML IdP and SP using Docker container provides the SAML SP configuration for SAML SP demo application.
We have requirement of build .NET based plugin/component for enabling Authentication against multiple IDP providers like ADFS, Azure AD and Shibboleth based on DB configuration. i.e, depending on the configurable parameter the anonymous user will be authenticated against any one of the IDPs like ADFS, Azure AD or Shibboleth IDP.
Our application URL ("https://www.contoso.com/ProcessToken.aspx") will be registered as RP Identifier in all of the 3 providers.
We won't make any web.config changes for any of the providers.
At run time, User will access common page(Proesstoken.aspx) who needs to get redirected to the any of the Login page URLs at the provider (ADFS, Shibboleth, Azure) for Authentication based on User Organization. (For ex: User A to ADFS, User B to Shibboleth etc)
After Successful authentication at the IDPs the user needs to get redirected by the provider (ADFS/ Shibboleth/ Azure AD) to the RP Url registered.
In the redirected page (ProcessToken.aspx), we are planning to get the security token and decipher the claims required.
The main intention is to decouple authentication away from application logic and it should be extendable to other providers in future.
PS: Considered options like OWIN Authentication Middle Tier, .NET Component etc.
Need guidance on How and where to start.
Have a look at IdentityServer 3 which implements this multi-auth scenario or OWIN : ASP.NET MVC application with multiple authentication options.
The main point is that you use NuGet to download all the protocols you require and than use OWIN to pull them all in via app.use.
You can configure ADFS to have Claims Provider Trust with the other IDP's Owin will acknowledge the authentication. The difficult part will be reading the attributes from the tokens. ADFS under the covers in conjunction with the Owin framework use ws-federation, I have not figured out how to read the SAML.
What gets confusing is that at one time the answer was WIF but now that 4.51 has been released, WIF was moved into Owin. The documentation for a multi-tenant application is sketchy at best.