CAS supports a gateway mode (http://www.jasig.org/cas/client-integration/gateway), which doesn't force the user to sign in when accessing a non-secured resource, but if the user is already authenticated, they'll be signed in.
Lets say there's server A and B which have secured and non-secured pages. The user accesses a secured page on A and is forced to sing in with SSO. Then accesses non-secured page on B and although there is no need to authenticate, it should get the ticket because they're signed on.
Does any other SSOs support this feature?
I think Shibboleth has the same feature : http://shibboleth.1660669.n2.nabble.com/how-can-I-ask-for-but-not-require-a-lazy-session-td5084205.html...
Related
Microsof ADFS supports below federation protocols:
SAML 2.0
WS-Federation
OpenID Connect
Would like to know is it possible to achieve single sign on (SSO) and single logout across different protocols? E.g. user X after he/she successfully login to website A which is protected under SAML 2.0, then the user can access website B which is protected under OpenID Connect without re-login? Both website A and website B point to the same IdP.
There are typically the parties involved. Of these, website B is the modern architecture and can support many forms of authentication:
Website A redirects to SAML Identity Provider (IDP) directly
Website B redirects to Authorization Server (AS) which redirects to the SAML IDP
Single Sign On is represented by a third party session cookie issued for the SAML IDP's domain name. Both apps would redirect to the SAML IDP but only the first would result in a login prompt. Website B may need to send the acr_values OpenID Connect parameter during its redirect, to avoid the user being presented with an authentication selection screen. It should work fine, but test for your providers. The SSO cookie is maintained in current browsers on the second redirect, due to the user gesture of a top level redirect.
Single Sign Out has always been a set of draft standards that work imperfectly in all of the above protocols. Even if the technology works, there would be risks such as also signing the user out of App C, which you do not own. Also, recent browser restrictions on third party cookies mean some techniques may drop the SSO cookie and no longer work. Most stakeholders, including end users and security reviewers, do not expect you to have a perfect Single Logout solution.
I have a web application that is capable of being a SAML 2.0 IdP as well as a SP, and have successfully implemented SSO between my platform and ADFS, but only when ADFS is the IdP.
This is my first foray into integrating with my platform, using ADFS as a SP and I'm having problems understanding the SSO flow.
In my situation, I have three players: WebApp (IdP), ADFS (SP), RelyingParty (S). The trusts are set up in ADFS, and the user experience is supposed to be a successful login to the RelyingParty having logged in to the WebApp
Setting up a new Claims Provider Trust in ADFS with my web app appear to work perfectly. I can go to my app's IdP-initiated URL which sends an unsolicited SAML message to ADFS's ACS URL. When I do this, I get redirected to /idpinitiatedsignon with the message "You are signed in" and a drop-down of the relying parties I've already set up.
If I click on the login button for the RP, ADFS generates a new AuthNRequest to my web app before eventually getting to the Relying Party.
So, seeing this behaviour, I have two questions:
I would have thought that the initial sign in to ADFS via my IdP-initiated login would have got me though to my RP without the need for going back to the IdP for another sign-in. have I misunderstood, or have I just misconfigured ADFS?
What mechanism is ADFS determining that my IdP is to be used? If I go to the ADFS /adfs/ls/idpinitiatedsignon.aspx page in a browser, I've not involved my IdP at all, and selecting my RP does use my IdP to authorize the user but I've no idea how this is determined since there's no link between the Trust Claims Provider and the Relying Party in ADFS configuration.
What happens if you use loginToRp:
https://your-adfs-server/adfs/ls/IdpInitiated.aspx?loginToRp=your:relying:party:id
You have chosen to use IDP Initiated to ADFS. So ADFS handles the authentication.
If you want to involve your IDP, you need to use SP-Initiated flow from the RelyingParty (S).
Then ADFS will show you the Home Realm Discovery screen and you can pick your IDP.
I am implementing front-channel SAML 2.0 SSO golang Service Provider, with Okta as my Identity Provider (this is just a POC and should eventually work with any IdP).
Implementing the sign on process was straightforward with saml2 package. I've created the login endpoint that redirects to the SAML application login URL at the intended IdP, as well as the POST callback endpoint which is properly receiving the SAML assertion and is able to validate it. After that a session with a random cookie is created with the same TTL as the Identity Provider session TTL. So far everything works well (I haven't implemented Single Sign-Out yet, but I'm planning to).
However, when some time passes and the session expires, I'd like to renew it only if the user is still logged in with the Idp and hasn't been removed from the SAML Application. I would like to avoid redirecting the user to perform SSO again with IdP, because it would mean that if they are still logged in, they would be redirected back to the home page of my application. I wasn't able to find great sources on my options to go about it online.
Questions:
1.1 One solution that comes to mind is storing the requested URL in the RelayState parameter, whenever the session has expired, then redirect the user to the IdP SSO URL. When the redirect returns to the SAML callback POST endpoint, check the RelayState parameter and if set, redirect back to that (original) URL. That means that for users that use the system continuously, I would have to request Assertions very often. Does that make sense?
1.2 A second solution that comes to mind is to implement a back-channel of communicating directly from my SP to the IdP. That would allow me to verify a user is still logged in 'behind the users back'. If that's a sound idea:
a. Do I need to have dedicated code for each IdP?
b. Do I need to load an API key to the IdP which would allow secure communication?
c. Do I need to upload a public certificate to the IdP that would be able to verify that my SP signed the requests?
Will using the Assertion to get an OAuth 2.0 Access Token help me in achieving this?
I've chosen SAML 2.0 for now, since the environment is an enterprise oriented one and I thought it fits well with it based on what I read. Would using OpenID Connect instead help achieve my goals easier and fit well with enterprise oriented products?
Our company maintains a Web App composed of a front-end and a back-end in (Node.js), and we support the standard username/password login authentication. A couple of our partners have requested we support SAML SSO, so their end-users can access our web app through a link on their respective portals without the need to login again.
Question: Do we need to turn our app into a full-fledged service provider (SP) by implementing a SAML sdk/library in our front-end and back-end?
Or is it possible to use a 3rd party authentication provider like Okta to handle the SAML nitty-gritty behind the scenes and then redirect the end user to our app, with possibly a token (JWT?) so we can retrieve the user info from Okta?
I've read everything I could find on Okta's site, and here, and couldn't find a definitive answer, either yes it's possible (with example) or no you can't do that.
Like you already mentioned in your question, there are 2 possible ways to do it.
Update your application to support SAML login flow with your app as SP, in which case you will not need to use any 3rd party auth provider
If you don't want to get into the SAML nitty-gritty, you can use a 3rd party provider like Okta as an intermediary that will consume the SAML responses from the IdP (used by your external customers) and then convert that assertion into an Open ID token (JWT). In this case, Okta will act as an IdP (Authorization server) to your web app and generate ID tokens.
Your app will then need to implement the Open ID connect login flow.
You can refer to http://developer.okta.com/code/javascript/okta_sign-in_widget_ref for this.
I am creating a service provider which talks to third party IDP for authentication. But I have a concern that I have a set of dedicated machines(Desktop,tab) which are highly trusted, so is their a way in SAML that when a request is sent from such machines user is directly authenticated without the need to type username and password.
you want that user that tries to access a resource from his desktop (which is trusted) will be automatically authenticated? if this is the case, it seems that you need to identify the user using the active directory or something.
if this is the case, search a bit about Kerberos, or ADFS - it might serve your needs.