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

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.

Related

Can/should client app provide its own login page?

I am very new to IdentityServer and Open ID Connect and most of what I know comes through the three walk throughs in the Overview section of the IdentityServer3 documentation. All of those samples demonstrate how to use the Authorize attribute to secure a controller action, which results in a redirect to the IdentityServer-hosted login page. What is the typical or recommended way to provide a Login link in the client application? Could my client application have it's own login page and then call IdentityServer to validate the login and provide a token? If so, is there a sample that shows this? If not, is there a way to have the login link in my application bring up the IdentityServer login page? Is it as simple as securing the Login action with an Authorize attribute?
I don't think it is right that client has its own login page. Imagine you use Facebook as identity provider, and would you expect facebook users to enter their Facebook crediential on your login page?
One method is what you described using server side challenge redirect, or configure your app as a Javascript implicit client - see example , which it builds up authroize challenge URL. Either way user sees login page from identity server.

Spring Security back channel SAML SOAP Authentication

I have a Spring Security app that uses SAML. It is working fine. I go to a secured page, I get redirected to the IDP, login... success.
Now I want to have the login done "in house" as it were, with no redirection.
I want to have a login page that takes username/pass - then -- well I don't know. :)
Is there anyway to NOT have the user's browser go to the IDP, either POST the form to the IDP and then redirect back to my app?
I read in the documentation about back-channel SOAP calls, and that sounds like exactly what I want, but I can't find anything on it. Does anyone have an example of how this would be achieved?

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

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.

ThinkTecture IdentityServer and identity federation

I'am trying to enter in the huge world of the SSO and making things to be clearer.
Here is my use case :
I have a web app (the RP in the SSO jargon) which uses a REST API. We have customers that would like to use a SSO way to connect to our web application and our API.
For example, a user "A" from our customer "A-Company" is connected to its intranet. And in this intranet there's a link to our Web App. If this user A clics on it the Web App must redirect it to the IDP of the "A-Company". User A then signin and gets an access token and is redirected back to our web app. Then, our web app validate this access token, get the claims and etc ...
If a user "B" from our customer "B-Compagny" wants to do the same, it'll have to be redirected to its own IDP too.
How this can be achieve using IdentityServer3? How my WebApp (the RP) knows where to redirect the incoming request to be authenticated (to IDP-A or IDP-B or elsewhere ...)
Is this use case illustrates what is called "Identity federation"?
I was looking at OpenID Connect and ThinkTecture IdentityServer V3 that seem to be a very good product but I have some difficulties to see if it will fit my needs.
Thank you for your help
Fred

Designing a single sign on / CAS interface

I am creating a SaaS that will allow users to interact with it via their web applications. I would like to create a CAS type login mimicking Facebook connect so when you click the 'Login' button on the users website it will popup a window for you to login with my SaaS credentials.
I do not want the SaaS users site to be able to access the users login credentials so this is why I thought of CAS. However, it doesn't look like Facebook Connect redirects to the CAS server. It looks like they just popup a window to the facebook login then create a cookie once the user successfully logs into facebook. How then does the Facebook Connected site access that cookie?
I am wanting to basically be able to keep the end user on the current website without being redirected to my login application. I would like to mimic what facebook does with just popping up a little window and have them login then refresh the page after they login but I am not sure how to go about this.
Any ideas?
Facebook uses a third party cookie: they set a cookie on your domain that you can access to get the necessary credentials.
EDIT: the easiest example would be to look at PHP's setcookie function. Notice that there is a domain parameter. If you change the domain to match the domain of the actual website that initiated the authentication action then you'll be able to set a third-party cookie.
Note that on IE there are certain headers the domain that initiated the authentication action needs to set to allow your third-party cookie to be set. See http://www.spamcollect.com/archives/33 for a short writeup of how that works.
If you are working in a different language you'll need to use whatever cookie management functions they offer.
Another option may be to do this with CAS programmatically using the REST client.
https://wiki.jasig.org/display/CASUM/RESTful+API
In this way you could take the users details and login to CAS without being redirected.
Facebook uses Cross Domain communication which is what I will be using.