Is SSO between different applications achievable using ADFS or other STS?

Question

I am trying to come up with a solution which heavily relies on claims based authentication, possibly with ADFS2.0 or other STS.
One requirement from the solution is Single Sign On between different application in the organization. Assume that all applications have been adapted to this using WIF, and are claims aware.

So basically it means that once a user has logged in on any one of the applications participating in the SSO, he can move on to other application without the need to authenticate.

Is this possible using ADFS? with custom STS?

Update: not windows authentication. see explanations in my post below.

Also, it would be nice if some application, although claims aware, should not participate in the SSO.
Example: if I logged in on the corporate portal, I can move seamlessly to the learning portal, but If I want to go to view my salary report I should log in again.

Is this possible using ADFS? with custom STS?

Please refer individually to each question, because the second requirement is not a show stopper.

Thanks!

Answer 1

Yes this is totally possible - and in fact the standard scenario.

For requirement #2 - since ADFS does Windows authentication, you typically don't force re-authentication. A custom STS could implement that feature exactly the way you want.

In general I would recommend ADFS (or another commercial STS) if it has all the features you need. For a custom STS, this might be a good starting point:

http://identityserver.codeplex.com

---

Dominick Baier | thinktecture | http://www.leastprivilege.com

Answer 2

I am sorry I should have mention before that the scenario does not involve any kind of windows authentication. We are authenticating against a custom account store.
You can assume that that custom account store already has a STS that issues SAML tokens.

If ADFS will be part of the solution, it will act as a federation point between the relying parties, and the our custom account store (it will trust the other STS).
If not, we can create a custom STS for this purpose, and trust the custom account store STS.

So under this conditions, is SSO it still possible? if so, how is this process looks like (in terms of http messages)?

About identity server - I have seen it while searching for stuff that can help with the custom STS. It looks very nice (good work!).

Thanks for your help!

Answer 3

Bumping up..

Answer 4

SSO is somewhat of a byproduct of federation in what you are describing.  You will get SSO between any/all RP’s that share the same IP/STS.  The key is the timeout within the IP/STS.  When you access RP1, you get bounced to your STS, and will need to authenticate, then on success you get redirected back to RP1.  Then if the user goes directly to RP2, they again get bounced to your STS.  If your IP/STS session is still valid, then the assertion will be generated again and the user then redirected to RP2.  The net effect to the end user is SSO, although there are several hops going on under the cover.

On the second question, if you want one particular RP to require the user to login, then you can either deploy your STS twice where the special app trusts the second STS OR you can have this app issue a signout call to your STS, which will require the user to login again.

If you are looking for a good STS that integrated with ADFS, check out our solution at http://www.optimalidm.com/Products/VIS/VirtualIdentityServerFederationServices/default.aspx, we include other elements that are typically not thought of when writing your own STS such as Denial-of-Service, 2-Factor Authentication, SSPR, Authentication from multiple back-end data stores, etc.