Simple SSO - using custom authentication - CAS or some Oauth or openid server?

Question

I\'d like to know more about the different ways of solving Single Sign-On and their pros and cons. Have you worked with one particular solution, tell me what\

Answer 1

This is based on my experience: SSO (Single sign on) is related to two scenarios:- i) I know you very well (two parties involved) ii) Hey friend, meet my friend (three parties involved)

So ofcourse, 2nd scenario need a redirect/forward mechanism because usually third party is only centralized authentication/authorization service.

Now, implementation wise, SSO requries two areas to be evaluated:-

a) how different parties/systems(whether internal/external to organisation in question) are managing user credentials. This is called Identity management.

b) how SSO information should flow between parties? Ofcouse securly in most of scenario.

I think Identity management is more crucial than determining how-to-pass-information-securly because for latter part there are lot of encryption/decryption techniques available. It is indetity management which is unqiuely different in one set of SSO enabled systems.

Now Identity management can be implemented by a simple userID(if it is available on all participating systems),or by in-house developed XML content, or SAML payload,or a third party token. I think token is just a generic term referring to container containing user credentials in secured manner and also information about some security procedures performed.

@Ole, having said all above about basics of SSO (from my perspective), I think you should concentrate more on how users & their roles are identified across multiple systems i.e. in your case:- your users store, open outh2 provider; so put more thinking on identity management.

One solution could be (depending upon your budget and time), your enterprise can spend effort on creating in house centralized authentication interface in form of standard integration technologies for e.g. web service and behind those API, you can have any implementation: your own provider or third party oAuth or mixed of both. You can implement an engine layer in between your API and provider layer which is decision maker. For e.g. engine can have application domain and corresponding auth provider mapping. This way you will have uniform authentication interface for all of its clients.

Client --> In-house centralized API --> Engine --> Auth provider(s) let me give u an example:- i) you can have a Webservice exposed , named may be singleSigonService. XML payload may be like:-

   XYZ    my-java-app.com  ...
        ... 

ii) A web service Client would make SSO call to centralized engine layer (implemented in any technology), which may do validations and bookkeeping stuff and may be based on source-domain (for e.g. my-java-app.com) in incoming XML would delegate the request to Oauth2 provider such as facebook-connect. So your engine, the decision maker, would manage authentication rules as you mentioned in your requirement.

So basically all consumer applications will have an unified web service based interface to your SSO solution.This is what I refer to In-house centralized API.