How can I have two separate SAML applications login to an IdP without logging in twice? - single-sign-on

I have four custom apps (that are SPs), using Auth0 or OneLogin as my IdP. In Auth0 I create a connector for each application. When I login to one application and then open the other application, I get redirected to Auth0 to login again.
Is it possible to log the user into my IdP (or Auth0/OneLogin) automatically on that second app without having to click the login button on Auth0, since they've already authenticated with Auth0?
There is an unfortunate need to embed the second app into the first app and it's a poor UX to have the user login to the first app and then login again in the iFrame.

Auth0 Dev here, Yes this is supported Out of the box in Auth0, for this to work you'd have to turn Use Auth0 as IdP "ON" in your Client. When doing this Auth0 will then remember the client for 10 hours upto 3 days if the client is active.
The flow in your scenario will be
User logs in to any of the application.
User visits the other application.
The other application sees no session.
The other application redirects to /authorize endpoint.
Auth0 notices the session and redirects it back to your application immediately.
This is further detailed and explained at https://auth0.com/docs/sso

SSO is not having to re-enter credentials again but you only get SSO once you redirect to the IDP and you authenticate under the hood i.e. seamlessly.
So you still have to do something to trigger the redirect.
You could programmatically redirect to a dummy page that requires authentication that then redirects via your client stack e.g. OWIN OIDC.
Also, there is no standard for the cookies so you don't get SSO across multiple IDP unless they are federated together.
So if no federation and you login to Auth0, you will still have to login to OneLogin.

Related

Okta SSO between 2 apps w/o user having to know about Okta

Background
We have two apps, App A and App B. I'm working on a POC for connecting the apps to each other.
For background, IT wants to use Okta in some fashion. My experience with Okta has always been as the IDP and SSO was done via a normal SAML or OIDC workflow. But this requires the user to know about Okta and log into Okta. This setup is suitable for companies who are managing their users through Okta.
Desired UX
The UX that we are looking for involves a user with a fresh browser (no cookies anywhere) logging into App A, and then being able to click a link in App A and ending up in App B authenticated, without ever having to see an Okta page (a redirect through an Okta URL would be OK, however). We would also like to support the opposite (App B sending the user, authenticated, to App A). There is a shared convention between the apps that the email address of the user will be the same on both sides.
Obviously we could create some form of SSO directly between these apps, but IT wants to manage whatever authentication connection we use in Okta (for security, etc.).
Without knowing the direction to go my instinct tells me that we will need to use Okta as an IDP, but that we will need to use an Okta SCIM API of some kind to register users in Okta, at some point before we send them from App A to App B. Is this correct? If so, is it also possible to authenticate the user so that they don't have to log into Okta in order to arrive authenticated at App B? Is this completely wrong? Would that basically require us to make App A and App B both identity providers and consumers? Or is there some kind of better / simpler workflow for this scenario?
You can do Okta sign-in w/o redirects to Okta, if you are using Okta widget or Okta APIs. Then you don't need to show any Okta UI to your users. Only one thing, make sure that Okta cookies are sent with those requests, so that Okta knows that you already have a session.
you just need to implement SSO for app A and app B, separately. Both A and B will share the same Okta tenant as the IdP.

How to set Java app to act as an Identity Provider

I have one java app in which the user logs in. In one functionality of the app, when the user clicks on one button , it will redirect to client website where user has to login in that website. If i want to do the SSO to redirect to the client website without logging in , How can i do that? I don't want to use third party IDP'S(okta, Salesforce, azure) since the user is logging into the java app, so the user is verified, is there anyway i can make the java app as an idp and do the sso by sending saml assertion directly to the client site from the java app ?
You could do this by adding a Java SAML client to your application.
A number of these can act as an IDP as well as a SP (the application).
But this is not recommended since it does not scale.
Rather use an IDP. You get SSO so the user only has to login once.

How to Check SSO Session from the first time without click on Sign In button

I'm researching on SSO but there is one thing I coudn't understand is how SSO consumer can get session without clicking on Login Button. I can explain the case as below:
I have:
accounts.domain.com (Identity Server. Already Allow consumer 1 & 2)
myapp.com (Consumer 1)
yourapp.com (Consumer 2)
When I go to myapp.com -> I have no permisson or no session to access the server resources.
I click on Sign In button in myapp.com, this will redirect to accounts.domain.com and after authenticated, I get back to myapp.com with my local session.
The question is: When I go to yourapp.com, I already have session without click on Sign In button.
The real case is google.com, accounts.google.com, youtube.com, ...
I don't know how it works and how to implement this?
And one more question, Can I use Auth0 or Google Cloud Identity or AWS Cognito to build my Identity Provider like google did?
Can someone support me in this?
To better understand the concept u should 1st know what happens when u use SSO login.
I will take google and YouTube as examples.
When u login to google using your credentials u will not only get a local session but a single sign on token. We generally have this as SAML which is security assertion markup language token.
This SAML token will be stored in your client or browser in this case.
Now when u try to load youtube in the same browser this token will be sent to the IDP along with the request. Since the IDP knows that this user is already authenticated it will check for authorization for the particular website in this case YouTube, the page loads.

Implement Single SignOn with Identity Server 4

Given an Identity Server 4, can we implement a Single SignOn being used by different applications with a single user authentication server?
If so, how can we do that? Any reference material available for the same?
In fact, there is nothing special you have to do to enable single sign-on. It's available by default, but not for all scenarios.
In order to make SSO work there is only one rule:
The user has to login on the IdentityServer website, because that's where the SSO cookie has to be placed.
SSO is not available for grant types that do not require the user to login on the IdentityServer website.
How it works:
A user visits webapp1, hits the login button and is redirected to the IdentityServer website in order to login. IdentityServer will scan for the SSO cookie but will not find it since this is the first time and the user isn't authenticated yet.
After succesful login, the SSO cookie is stored (on the IdentityServer website) and an authenticated user is returned to webapp1.
The user then visits webapp2. As long as the user is not required to authenticate the user will be an anonymous visitor.
Authentication is required when the user clicks on the login button or visits a secured page (e.g. secured by the [Authorize] attribute). That triggers the authentication flow which redirects the user to the IdentityServer website.
Again IdentityServer will scan for the SSO cookie, but this time it's found. Being already authenticated, the user isn't required to login again but is instead returned to the website as authenticated user.
Please note that the client can overrule the SSO cookie by setting the prompt=login parameter.
Also note that cookies are not cross-browser. Visiting webapp2 using a different browser will require the user to login again because the SSO cookie isn't available for this browser.
Yes you can, that is what IdentityServer4 is used for (SSO & Authentication).
There is documentation and some samples.

Okta - How do I identify currently logged on user in this case?

I will try to keep the question as clear and direct as possible.
Social authentication (Facebook) configured with Okta with redirect URI as URL to my custom webapp. This custom webapp relies on Okta for authentication.
User visits my custom webapp (unauthenticated) and clicks on the social authentication URL to login to my custom webapp.
User follows the normal flow, gets authenticated by facebook and thereby by Okta (as per usual flow) and is then redirected by Okta back to the custom webapp.
The entire flow is successful and the user can see an Okta session cookie set in their browser.
Custom webapp now needs to show the user their own profile by making an Okta API call.
Problem: How can my custom webapp identify who just logged in so that they can fetch their Okta profile using API?
I am aware that Okta knows who just logged in due to claims that facebook sends to the OAuth client (Okta), but how will my app know the identity of the user who logged in?
Thanks,
Jatin
It depends on the OAuth2 flow you've chosen for your app, but the end state is getting an id_token from Okta which contains claims about the user that just logged in.
If you've set response_type=code in your social auth url (/authorize), after Step 4 you'll get a code query param in the redirect that you can then exchange for the id_token using the /token endpoint.
Or, if you've set response_type=id_token, you should already have the id_token in the redirect - you just need to validate/decode it (more info here).