Have configured SSO via SAML and WS-Federation in Production using ADFS. New customer is asking to integrate SSO via OpenID Connect (oidc) with Google+.
Identity Server v3 (IdSrv3) supports oidc, so I put together a prototype and I am able to integrate SSO using Google+ as follows:
MyWebApp <-- ws-fed --> ADFS <-- ws-fed --> IdSrv3 <-- oidc --> Google+
Current configuration has IdSrv3 present the user a Login page with option to enter Username and Password and button to use Google+ as IdP.
Can I configure IdSrv3 as a Federation Gateway with Google+ as the only IdP? (i.e. no username password fields)
Please advise,
-Santiago
Sure - set the EnableLocalLogin to false in the AuthenticationOptions
https://github.com/IdentityServer/Thinktecture.IdentityServer3/blob/master/source%2FCore%2FConfiguration%2FAuthenticationOptions.cs#L47
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?
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.
Our system architecture has this setup. We have an API that is used by a WebApp Client. We allow users to authenticate using an Identity Provider (IDP) that returns SAML.
The problem is how would you setup authentication? Which of the flow below would be more suitable?
WebApp Client controls the flow
When a user needing authentication visits WebApp Client, redirect user to IDP.
User authenticates with IDP
IDP redirect user back to webapp client with SAML response
WebApp client passes the SAML to the API.
The API will decrypt and read the attributes.
API then gives access token to the WebApp client it can use for subsequent requests.
API controls the flow
When a user needing authentication visits WebApp Client, redirect user to a special endpoint of API.
API redirects user to IDP
User authenticates with IDP
IDP redirect user back to API with SAML response
API decrypt and read the attributes
API redirects user to the WebApp client passing an access token to the WebApp client it can use for subsequent requests.
I'm currently asking myself the same questions with google idp. I thought about passing the returning code from idp to my API and then authenticating the user from my API.
If you have some return on your experience let me know :)
Premise:
I have an infrastructure where we have a custom RP-STS implemented with Windows Identity Foundation, providing SSO for a few websites. This STS communicates with the sites via WSFederation. This custom STS is about to be deprecated because the organization is adding an Open ID Connect Idp into the infrastructure.
The websites themselves (Episerver) contain all the custom made authorization logic already based on the claims the STS provides, and if we were to simply toss the STS we'd have to replace all of this logic.
Question:
What is the browser redirect flow to integrate our RP-STS to the openId connect provider in such a way that the end user browser gets a session for both our RP STS and the Open Id Connect IdP?
Personal thinking on how it might be doable (based on massive assumptions on how openid connect works), skip this if you know how to answer:
Website sends HTTP post to RP-STS containing username/password
RP STS responds to browser with redirect to OpenId Connect Idp (Redirect contains username / password, and a replyto address is set to the RP STS)
OpenId Connect Idp creates a local session (???) and responds with a redirect to RP STS, redirect contains auth_token. (I'm unsure of the parts that go into an openid connect login flow)
RP STS receives user token and gets / asks for user data, builds claims and builds local session
RP STS sends claims in SAML token via WSFed to RP site
Am I even close?
Further clarification:
I do not want to remove the existing STS, but abstract the new infrastructure change behind it so that from the end-user-sites perspective, identity objects and authorization logic will remain unchanged.
I need help specifically in seeing if the login/logout flow is doable between the STS and the Open ID Connect IDP
WIF and OpenID Connect are completely different protocols e.g. WIF is mainly browser based in the passive profile. The token types are different - SAML and JWT etc.
The way to do this is via OWIN (Katana is the Microsoft implementation). There are NuGet packages for both WS-Fed and OpenID Connect.
There are samples available for Azure AD - refer Microsoft Azure Active Directory Samples and Documentation that you could use as a guide.
OWIN would allow you to use both protocols.
In fact, have a look at IdentityServer3.
This is an open source STS implementation of both.