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

I can answers some of the question regarding CAS as I have used them before. I've no experience with OAuth and therefore wont comment on it.

First of all, I don't understand the need for token verifications of CAS, what is it good for?

CAS is used for SSO purposes. Its used when you have multiple applications(desktop apps/webapps on different TLD) that want to do authentication from a single source.

Is it more secure? I note that it's redirect based and hence equally subject to man-in-the-middle attack, just as a "custom" auth server without the extra token verification step would. Is it something to the security in CAS that I'm missing?

Authentication servers uses SSL to prevent MitM attacks. But I don't see how this a problem specific with SSO/CAS since you would have the same problem even if the app is doing its own authentication. Maybe you can tell us what kind of MitM attacks are you worried about with the CAS setup

Is the purpose of the tokens to provide single sign-out and/or timeout? (We don't want it, our users would hate us.) I've been looking into CAS, as there are some awesome Ruby implementations, but I'm not sure it's what we need.

The tokens are just a way for the application to authenticate you without having your password. They are short lifespan/single used token that is associated to your user credentials. The application provide the token to the CAS server and the CAS server reply with a credential, if any is associated with it. Single signout and timeout is possible to implement but not directly tied to having the tokens.

I hope this is clear. I tried to make it a high level explanation. Feel free to ask for specifics if theres any part that is not clear or you want more specifics about.

EDIT: I found a better put simple explanation of how CAS works at http://www.jasig.org/cas/proxy-authentication (The rest of the page talks about proxied authentication. Which is more complex but the first few paragraph is the simple case we are talking about here )

I go to my Portal instance. It redirects me to CAS to login. CAS detects my secure cookie and does the Single Sign On whereby I don't have to give my username and password again. CAS redirects me back to the portal. The portal validates the ticket, logs me into the Portal I see my default layout populated with some cool channels telling me it's really cold outside and what's in the news.

Notice that the portal didn't get my password.

Answer 2

Oauth is designed to authenticate application to let them act in the name of a user. For example a twitter client may post tweets with the account of a user. It can be used for single sign on as Facebook shows, but this requires a bit of additional work.

Comparing CAS and OpenID

CAS is a centralized system with one account authority. OpenID is a distributed system where basically anyone can setup an identity provider. Of course you can limit your consumer to only accept your own identity provider.

OpenID has two (incompatible) standards to provide additional attributes about the account, which are supported more or less by the common libraries. In the standard setup CAS only provides the username. While CAS does support attribute exchange in theory, at the moment only the PHP client supports it.

Both OpenID and CAS can do automatic login. If the user is already logged in, the browser will be redirected back to your application immediately. In a simple setup the identity provider, however, will display a login page, if the user is not logged in. So if you want to allow anonymous access to your side, this will require people to click a dedicated login link.

Luckily both OpenID and CAS allow a transparent login attempt. In this mode, the login form is not shown. The browser is redirected back immediately with or without authentication information. In other words: You can redirect all new users (without a session) to the identity provider as soon as they visit your site. There is a nice diagram explaining this in detail. CAS calls it "gateway mode" and it is achieved by appending gateway=true to the login URL. In OpenID it is called "immediate mode" and the URL parameter is openid.mode=checkid_immediate

CAS supports single sign out. OpenID does not.

My personal experience is that CAS is very easy to set up and very reliable with high quality libraries for all common programming languages. OpenID has many tiny incompatibilities as it is a much more complex system. OpenID, however, allows the usage of Google accounts.

Answers

First of all, I don't understand the need for token verifications of CAS, what is it good for?

Both OpenID and CAS require you to let the identify provider verify the provided token. Otherwise an attacker may be able to create his own token or use a token that was created by a user before he logged out.

Should clients also use ssl?

Yes.

On the client side, would you use an iframe, like lightbox, to show the redirected page? Why/Why not?

A full screen redirect is the most simple thing to do. I would start with that to get it working. Many application require a reload of the current page after login anyway in order to show parts that are only visible to logged in users.

An Iframe has the issue that you need to get rid of it once the login was completed. For CAS there is a tutorial on how to directly embed the CAS login form into the HTML code of the application. Another alternative is to show a pop up window like Facebook Connect does.

Answer 3

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:-

<SingleSignOnReqType>   <sourceID>XYZ</sourceID>    <source-domain>my-java-app.com</source-domain>  <user-credentials>...</<user-credentials>
        <security-credentials>...</<security-credentials> </SingleSignOnReqType>

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.