ADFS 2.0, WIF (WS-Federation): I want to implement SSO in the scenario when user goes to IdP web-site first to be authenticated. In this scenario our customers have intranet web-portals with links to our (service provider) web site, which actually lead them to IdP web site and redirect them to our web site as soon as user is authenticated. I could not find any info with technical details on how to implement it properly, can anybody?
What I did so far, I grabbed the redirection link to IdP using Fiddler to use as portal link and looks like it works, however I'm not sure if it's a proper way to do that. If you have similar experience please share.
UPDATE: More detailed use case: Our customer has its own intranet portal with link to our web site (service provider). The idea is to avoid additional initial http redirections and to have single entry point for different customers, so that our web site can count on security token coming from user to recognize identity of the customer, in other case we should have separate uri for any customer. User clicks the link, it leads him first to its own intranet IdP service (ADFS 2.0) that authenticates him with his windows account and adds security token and redirects him to our (relying party) web site where we can recognize him and his organization (customer) by the token, and he can consume our services. Let me know if something wrong or seems suspicious with the scenario.
Normal case is that the RP URL bound to ADFS via FedUtil is what ADFS return to. So if the portal is bound to ADFS (doesn't sound like it because you don't have to log in to get there?) then that's where you return when authenticated.
If your web site is what's bound to ADFS, then user goes to portal, clicks on link, gets authenticated, token with claims created and redirect to your web site.
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 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?
Let's say we have a service provider app called A hosted on tomcat, a user clicks a link to the SP A. SP A sees no token is provided so it redirects the user to the IdP for authentication (with a SAML Authn request provided by some means). The IdP then redirects the user to some common login page where credentials are provided, assuming that these credentials are correct the IdP creates a SAML response with a token and some assertions about the subject, and sends it back to SP A. SP A sees this and allows the user access into the application. Great!
I have a few questions though
How is the authorisation request/response sent, I understand there is a redirect binding and a POST binding where the SAMLResponse and request are encoded either as a query param, or sent as an XHTML form in case of a POST binding. But I'm not sure which is used where?
A service provider is the thing providing a service, so Office 365 or Sales force for example. Is each one a separate service provider? I ask as I watched a video where the guy said the service provider was the thing that hosted these services, so I'm not sure of the correct answer here?
How is the token stored on the client side? So for example I am now authenticated against SP A, the user then tries to use SP B from the same machine/browser window, how does SP B and the IdP know that the user has already authenticated and therefore doesn't need to re-authenticate. I.e. the SSO aspect of it.
Does SP B need to be hosted on the same tomcat instance for this to work?
I dedicated significant time to get SSO working for me. The most helpful document was this specification
The answers below are based on this experience:
Redirect or Post binding is used depending on a respective HTTP request header. The Post binding is recommended since it does not imply restrictions on data volume transferred.
A Service Provider in this context is anything that clients request. There may be many of them, participating in the same SSO scheme.
The service providers must be SSO-aware, which includes handling of the authentication response data. Usually you don't have to implement the protocol - there are ready-made frameworks that your SP can utilize.
Service Providers may reside on different servers.
From my own experience:
You choose your own SAMLBinding (redirect or post) depending on what your idp and sp supports. This binding type will be used both for the 1st step (SP -> Idp) and 2nd step (IdP -> SP). If you have some running environment, open your browser devtools and look at network tab to see what happens. It's just a way to send data from browser to SP/IdP.
Both Office 365 and Salesforce.com are cloud services, right? Let's take Office 365. it means that beyond "end-user" services (like Word, Excel) there is some technical SSO service which are common to the platform. It can be viewed as lower (or technical) service layers, I think that what you speaker meant.
The SAML token is stored by you SP application inside your browser, either hidden inside web page, cookie or web storage. It depends on how your SP is implemented.
SAML response can be validate by each SP based on shared private key, so it will decrypt the token using this key and be able to grant user without the help of IdP redirection.
Tomcat have some extension to support SAML. But SAML is designed to work without being on the same instance, as the opposite as basic JSESSIONID cookies.
So you have several instances, of course.
All,
I am working on a SSO Project using WIF for my current employer .Registered users can log in to a portal that is public facing and receive access to a suite of applications . My employer has purchased a COTS Application(Claims Aware) hosted in another city . What they would like to do is the following
1a)Have Registered users log into the Portal located at portal.domain1.com
1b)During the login process , the portal communicates with an STS in the background which returns a signed and encrypted token back to the browser
2)User sees a link to the COTS Product on the Portal Page and clicks on it
3)They are redirected to app.domain2.com
4)App.domain2.com does not need to autenticate the user again since they receive the identity token from the portal .The user is able to establish a session from his browser with app.domain2.com
5)The browser is able to persist the token across all requests to the domain2 server
We will not be doing ADFS 2.0 but a Custom STS . My question is , is there a way to do it in SAML ?
Thanks,
Raja
You can push SAML authentication statements.
When the link is clicked on portal.domain1.com you use javascript to post a saml statement to app.domain2.com.
I'm working on a proof of concept app. The basic functionality works, where I can log into one website, link to another site that shares the same STS, and the partner site picks up the credentials properly.
However, the partner site only requests the token if the page that we link to requires authentication (which kind of makes sense I guess).
Ideally, I'd like to link to a partner page that does not require you to be authenticated, BUT if the user IS already authenticated, I'd like to at least be able to recognize them on the partner site.
Currently, if my partner landing page does not require authentication, it doesn't appear that the user is logged in when they arrive. As soon as the user requests a page on the partner site that does require authentication, it then grabs the token without requiring the user to log in.
I've tried playing around with the SecurityTokenReceived and RedirectingToIdentityProvider events, but so far I'm stumped.
Any thoughts are appreciated.
So, the problem you are running up against is in dealing with the SessionAuthenticationModule hijacking the request. This module is responsible for detecting if the user has a valid session (based on a cookie that is written upon a successful redirect from the STS) and if not, to redirect the user to the STS to fetch a valid token. The WSFederationAuthenticationModule supplies the eventing necessary to hook into various stages of the redirection/authentication process.
Based on your description, it sounds like you want the following to happen:
User clicks on a link that redirects to the partner site
At the partner site, the request is intercepted and the system determines if the user is signed-in to the STS or anonymous
If the user has a valid session with the STS, then pull the claims for that user
The problem is, your RP cannot know that the user has a valid session without sending the user to the STS first (the RP's do not talk to each other or the STS. The user's brower is used as the means of communication between the RP's and the STS in the form of WS-Fed directives and SAML tokens passed in the url during redirects). If the user is sent to the STS, then they must authenticate, which could be a problem for anonymous users.
So, I do not think there is a "trick" that you can pull via configuration or interception of the request to determine if the user has a valid session with the STS. You might be able to pass a hint, however, from the referrer that is intercepted by the partner site. This hint could take the form of a parameter on the url that indicates to the partner site that the current user has a valid session and to go ahead and redirect to the STS (absence of this hint would indicate an anonymous user). You could also build a system to "hand-off" knowledge of the signed-in user using a resource that both sites have access to (i.e. database).
As you are sure to learn soon, more often than not, WIF offers pieces to the puzzle, but every situation is different and you have to supply the other pieces on your own.
Hope this helps!