Single Sign-On (SSO) @ OCF

As we see more staffers using more OCF services which require login, its worth considering if we can easily standardize login support with a Single Sign-On (SSO) system, to have a single system managing login state, like UC Berkeley’s CAS.

Based on Wikipedia’s list of SSO implementations, the following providers seem worth of discussion or further research.

It might be advisable to move to MIT Kerberos to facilitate this change. We also have campus administrators and mailing lists which could be helpful in considering our options as well as setup.

This post will be edited to maintain a introduction to this project idea with a focus on readability, OCF concerns/infra implications, and other trade-offs.

Is there a reason why we’re against putting applications behind an authentication HTTP proxy? This is what we do with RT, Puppetboard, and others. It requires a small amount of work to convert these back to Kerberos prompts instead of LDAP prompts (which would allow for automated logins on OCF desktops). Once we do that it’s basically the same as an SSO system but without having to install a new thing.

Most applications support auth proxies by reading an HTTP header. As far as I know, all the things we’ve been talking about deploying support it.

The only drawback I see to this is that the usability isn’t great on staffers’ personal machines. I’d also be interested in seeing if we could replace these Kerberos logins with a client side cert-based system. Ideally these certs could also be used for SSH. Then staffers could type their password once and get a cert that lasts them through the rest of the day, granting access to web services and SSH.