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's good about it and tell me what the limitations or suboptimal parts are.

Below are the details of what I'd like to know, or don't understand.

SSO is a huge topic, as listed in the wikipedia. The more I learn the more questions I have.

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

Is it more secure? I guess it's vulnerable to man-in-the-middle attack like any. Should clients also use ssl?

Let's get real, this is our need: Automaticaly recognize/sign-in user if already logged in at one of our apps.

• my-php-app.com
• my-java-app.com
• my-ruby-app.com

(we have many webapps, written in different languages)

We want (to keep) our own authentication rules and users store, but might add some Oauth2 provider, as facebook-connect. We want it dead simple for the users and simple for developers using it.

What would you do?

• CAS?
• Openid? Can I have centralized authentication with it?
• Other? Or a server with OAuth?

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

---

Yet another SSO related question: Saml is often (wrongly?) mixed into the SSO discussions - do I understand if I say that

a saml implementation would not provide sso (autologin) when pointing the browser to www.yetanother-myapp.com?

---

Some related SO questions I've studied:

• SSO with CAS or OAuth? - His need description is not what I want, he describes CAS...
• OpenID as a Single Sign On option? - Well, I'm not sure what I learned from it.

Thanks for educating me!

Answer 1

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 2

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.