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.
Related
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
I have an Asp.Net Core IdentityServer4 instance securing an API that is fronted by a Vue.js SPA (using oidc-client). The IS4 server is setup to manage "local" account itself for my companies users, but we also have an external OIDC provider setup for a trusted partner that allows their users to access our site using their single sign-on server (OIDC identity server). The partner's portal has a link to our app, so if they are already authenticated by their own OIDC server, then no additional login prompt is displayed.
Overall, this process works. I can login "locally" (an account that is only on our identity server), or use the external OIDC provider that authenticates the user and goes through the auto-provisioning on our local IS4 server. The Vue app has its tokens and silent refresh is enabled, which keeps the user's credentials updated against our IS4 server.
However, if a user from our partner comes to our app, spends some time there, and then returns to their own portal via a link on our site, it's likely that their access will have timed out and they see their own SSO login again. This is because the silent refresh on our site is only refreshing our local IdentityServer4 credentials.
Is it possible to somehow maintain BOTH "sessions" while the partner user is on our site? Silently refreshing both our IS4 token and their OIDC SSO credentials?
Is SAML an authentication mechansim. ? I have seen this being written in many places.
As per my understanding SAML is not an authentication mechanism but a way to exchange authentication and authorization data between a service provider and an identity provider. ?
Both Service provider and identity provider have to be SAML compliant or basically understand SAML to take part.
Authentication can be done by any means like oAuth, Form etc. and then SAML exchange happens.
Best Regards,
Saurav
Actually SAML is a internet standards based technology to achieve web-based single on.
The actual authentication, which happens at the SAML IdP is out of scope of the specification.
However sometimes implementors do no accurately distinguish between SSO and authentication.
Chapter 1 from SAML Technical Overview, a document published in 2008 and still a good read:
The Security Assertion Markup Language (SAML) standard defines a
framework for exchanging security information between online business
partners.
...and then Chapter 4 in the same doc
SAML consists of building-block components that, when put together,
allow a number of use cases to be supported. The components
primarily permit transfer of identity, authentication, attribute, and
authorization information between autonomous organizations that have
an established trust relationship
SAML (Security Assertion Markup Language) is an identity federation protocol.
(1) Traditionally a web application utilizes a local data storage (such as MySQL which is used to store username/password credentials) to accomplish the login authentication.
On the other hand, a web application can leverage a third-party SAML Identity Provider (IdP) to accomplish the login authentication if the web application has been integrated with a SAML Service Provider (SP).
(2) Usually a SAML IdP utilizes identity repository (such as OpenLDAP) to provide identity authentication for a SAML SP-enabled web application.
(3) A web application, which has been integrated with a SAML SP, outsources login authentication to a SAML IdP.
Without loss of generality, we assume that the SAML IdP has been configured with OpenLDAP.
A typical SAMP SP-intitiated authentication procedure can be described below.
(I) A user launches a web browser to access a SAML SP-enabled web application.
(II) The user is redirected to a SAML IdP which will prompt username/password login screen.
SAML SP sends a SAML request to SAML IdP.
(III) The user submits the username/password credential.
(IV) The SAML IdP leverages OpenLDAP to validate the username/password credential.
(V) The user is redirected back and logged in to the web application if the user has been authenticated by OpenLDAP successfully.
SAML IdP sends a SAML response token to federate the user identity (such as username) to SAML SP-enabled web application.
(4) How to build and run Shibboleth SAML IdP and SP using Docker container demonstrates how a SAML IdP utilizes OpenLDAP to provide identity authentication and then federates the user identity (such as username) to a SAML SP-enabled web application, thus accomplishing the login authentication for the web application.
I am trying to understand SAML and the IDP / SP model by following this auth0 tutorial.
https://auth0.com/docs/protocols/saml/samlsso-auth0-to-auth0
In this tutorial you create two auth0 tenants.
The first tenant (tenant 1) is the service provider, the second (tenant 2) is the identity provider.
In the section where we setup the second tenant I am having trouble understanding what is described in this line:
In this section you will configure one Auth0 tenant (tenant 2) to serve as an Identity Provider. You will do this by registering an application, but in this case, the 'application' you register is really a representation of tenant 1, the SAML Service Provider.
I'm confused about this because I thought the service provider is essentially a wrapper for all of the different applications you need to access through the IDP. So in my interpretation, I would think the application we create would exist inside the first tenant.
Would someone explain why in this example we set up the IDP to contain the application and how it is a representation of the service provider (tenant 1)?
Agree this article is somewhat confusing.
The key is "In this step, you will test your sample HTML application that uses the Auth0 SAML connection you set up in Tenant 1 to perform SSO via SAML against Tenant 2, serving as the SAML Identity Provider."
In SAML, there are two kinds of SP.
An SP can be an application so the path would be:
Application --> SAML IDP
or you can have an SP-STS (Security Token Service) i.e. an intermediate IDP acting as an SP.
Here the path is:
Application --> SAML SP --> SAML IDP
Basically, the SAML SP is just pass-through.
Normally what happens is that when you authenticate, the application redirects to the STS. You can authenticate here. However, if this STS knows that there is another STS upstream it will ask you via Home Realm Discovery which STS you want to use.
Basically I just want to know how does StackExchange's single signon system work?
In the SE network you need to login only once in one of the websites to be automatically logged in to the other sites upon visiting.
How should I implement such a feature in my own network of sites?
I assume it uses the cookie which resides on the user's browser and then authenticates it with the originating site. If it is legit then it logs the user in automatically.
You have to implement SAML or oauth2 to allow sso on your network.
In case of SAML your child websites will be service providers or resource servers.
While you need to setup and identity provider.
The sequence of events will be like this.
1. User hits a url of songs website, this site is resource server and does not handle authentication.
2.To authenticate resource server will construct a SAML authrequest and redirects to identity provider after signing it.
Idp verifies the signature after receiving authrequest.
3. User will be presented with a login form, user has to end login credentials.
4. After user authentication idp will generate a SAMl token and redirect back to resource server.
5. Resource server will extract identity information from SAML token, resource server will login the user with session or cookie.
Depends upon which technology you are working in i have implemented it in php using simplesamlphp.