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?
Related
Background
I have a web application "APP1" (front-end: Vue.js & Back end:Azure function) deployed in azure app service. I have implemented client directed sign in (easy auth using this), after that I can authenticate user using provider's sign in page [both AAD & google].
Target
I have another web application "APP2" deployed in on-primes server. I want to redirect to APP1 from "APP2" and automatically sign in without provider's sign in page. I will read credentials from environment variable.
Tried solutions
I have found a similar issue here, however I am unable to use the solution because the DB between AAP1 and AAP2 can't be shared
I have also checked the google identity providers documentation, however I am unable to find how to programmatically sign in without provider's sign in page
Question
Is it possible to programmatically sign in to google identity to get token without provider's sign in page
The whole point of google identity is to prove the identity of the person behind the machine.
OpenID Connect is an open standard that companies use to authenticate (signin) users. IdPs use this so that users can sign in to the IdP, and then access other websites and apps without having to log in or share their sign-in information. (id_token)
OAuth 2.0. This standard provides secure delegated access. This means an application created by a developer, can take actions or access resources from a server on behalf of the user, without them having to share their credentials (login and password). It does this by allowing the identity provider (IdP) to issue tokens to third-party applications with the user’s approval. (access_token, refresh_token)
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.
Should be a simple matter of registering the app in the IBM Cloud and providing callback URIs for authenticating the user and returning control just like login with google or login with Amazon.
But I cannot seem to find the exact flow of steps involved.
--prasanna
I think the service you are looking for is App ID.
When you are developing a web application, you can use the App ID web flow to securely authenticate users. Users are then able to access your server-side protected content in your web apps.
App ID uses the OIDC authorization code flow to securely authenticate users. With this flow, when the user is authenticated, the app receives an authorization code. The code is then exchanged for an access, identity, and refresh token. In code exchange step the tokens are always sent via a secure backchannel between the app and the OIDC server. This provides an additional layer of security as the attacker is not able to intercept the tokens. These tokens can be sent directly to the web server hosting application for user authentication.
App ID interacts with identity providers by using multiple protocols such as OpenID Connect, SAML, and more. For example, OpenID Connect is the protocol that is used with many social providers such as Facebook, Google. Enterprise providers such as Azure Active Directory External link icon or Active Directory Federation Service External link icon, generally use SAML as their identity protocol. For Cloud Directory, the service uses SCIM to verify identity information.
Read this blog post for using a custom identity provider
For an in-depth understanding of the flow, you can refer to this link
I need to implement an authentication mechanism with JWT tokens for an mvc web application and a mobile application as well. Users will be able to register to our database and authenticate by using credentials (from signup) or use facebook single sign on. Both applications will use web API for data exchange with JWT token. I am thinking of using Identity Server 3 for that using Resource Owner Flow and i have some questions on that:
1) User will login from mobile application and will get a jwt token. Mobile application will verify it's validity and will refresh when needed. In order for mobile application to have user always logged in should i store refresh_token on device??? Is it secure?
2) I cannot understand how am i going to handle facebook authentication and get jwt token from identity server. Should i first get users email from facebook profile data and then what???
Thank you
1- You can store refresh token in database( identity server provide a token stor)
also you can use third party library to store tokens in device securely.
2-To use the 3rd party logins you need to do the redirect style to the IdSvr login page. Using resource owner password flow means you miss out on all the features in the token service like SSO, 2fa and federated authentication.
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.