>>> "Richard L. Goerwitz III" <rgoerwit@carleton.edu> 1/31/2006 11:52:32 AM >>>
SSO Project Proposal
====================
Overview w/ Hardware, FTE Requirements
======================================
This proposal is for investigation and introduction of a web-based
single sign-on (SSO) system that allows for a single point of
authentication for all web-based services on campus. It should work
with both IIS and Apache, and it should also plug into more general
federated authentication/authorization systems that are starting to be
deployed in the higher-ed sector.
This will require setting up a central web server running some SSO
system, most likely Shibboleth, and then adding Shibboleth modules to
any Microsoft IIS or Apache instance that we expect to utilize
authentication. It will also require configuring Shibboleth to
interact with our current middleware layer. The Shibboleth server
could be either a Dell 1850 or a virtual server.
This project will require the equivalent of several weeks labor on the
part of someone who is skilled in deploying web-based services, knows
our middleware layer well enough to work with LDAP administrators, and
who can add modules to web servers. Although Shibboleth (or whatever
SSO system we select) can probably be overlain on top of our current
web infrastructure, there may also be a public-relations element of
this process, but it should be fairly straightforward, and would
consist mainly of working with ITS to notify people that signing onto
web-based systems will work differently (it'll be a web page instead
of a basic-auth screen).
The whole process of configuring a server, installing Shibboleth,
cutting our current infrastructure over to it, and publicizing the
changes, will take (I'd guess) two months.
Justification
=============
In reality this proposal is as much about getting rid of our current
authentication infrastructure as it is about bringing in something
new.
Why should we be getting rid of what is now in place? Because our
current setup is deeply flawed and diverges widely from best practice
in the industry.
Our current system is:
1) Redundant - every web server throws up its own authentication
pages and every web server must be configured independently to
utilize LDAP and mod_auth_pam
2) Overkill - most pages that utilize authentication only require
encryption for the authentication process itself, and the rest of
the session can go to plain text; our current setup,
unfortunately, forces SSL/https for the remainder of the
authenticated session, and as a secondary side-effect, tends to
leave the user in an SSL encrypted session even after the part
requiring authentication has ended
3) Insecure - because so many different servers throw up basic
authentication screens, users become conditioned to enter their
credentials whenever asked, making it incredibly easy for anyone
to throw up a basic authentication screen and grab Carleton
NetIDs and passwords (we saw this happen when I was at Brown, and
for this, and other, reasons put in SSO); also just the sheer
number of webservers through which credentials pass increases
dramatically the likelihood of compromise
4) Isolated - our authentication infrastructure doesn't dovetail
with any larger efforts now afoot in higher education to deploy
federated authentication/authorization systems
5) Restrictive - our setup only works for Apache-based web servers
and services
Given its deep flaws, one might wonder why Carleton uses the web
authentication infrastructure that it does, and why no one has put
forth a serious proposal for revamping it until now. The reason why
we have waited so long is that back when transitioning from the old
OpenBSD to the new RedHat Linux-based web server back in 2002, our
current strategy seemed the only viable course of action. At that
time there were no proven SSO systems that seemed ready for long-term
production use (PubCookie was probably the best, but even then it was
clear it was going to be phased out). Although Shibboleth was on the
horizon, it had not yet emerged as a reasonable intranet SSO tool. It
was also immature, hard to install, and hard to set up. Commercial
solutions were then, as now, expensive, and in considerable flux. The
best course of action, therefore, was simply to keep what we had in
place (with some useful extensions, like LDAP enablement and using
directory names with special semantics), and wait for Shibboleth to
mature.
Shibboleth
==========
Enough time has passed now that Shibboleth is mature. It is therefore
time to re-think our SSO strategy, not only because our current
methods for authenticating/authorizing people have so many inherent
problems, but also because going with Shibboleth will offer us new
possibilities for cross-institutional collaboration, integration with
Library databases, and potential improvements to the authentication
setup used in the Bridge.
I'd therefore like to offer this to the Web Services Group as a
possible project - one that will have a considerable benefit to the
campus on many different levels.
Richard Goerwitz
>>> Matt Bockol <mbockol@carleton.edu> 2/2/2006 1:34:15 PM >>>
Hi Richard & Jaye,
Thanks for the proposal, Richard. I agree that this is something we
should be pursing, though I think the WSG will need to discuss it in
depth to figure out where it falls in our list of project priorities.
The first step would be to survey all the contenders and make sure that
Shibboleth is really the best option. I'd like to know exactly how
smoothly a given SSO infrastructure would integrate with out
environment. Moodle, Sympa, TWiki, and EzProxy all authenticate against
Shibboleth out of the box today. The quality of support for Horde,
Caucus, WebAdvisor/Wizard, The Bridge, Wordpress, and Sakai is unclear
to me. Reason and the rest of our custom code would need to be updated
and I'm sure there would be other wrinkles to sort out as well.
The real scope of the project is dependent on how well all of the pieces
of our existing infrastructure will integrate. If we could target
Reason and the Shibboleth-supported services I'd be much more
comfortable setting a two month project time frame. I think expecting
to make every service authenticate through Shibboleth in two months is
an optimistic assessment of my abilities. :)
That said, I'd like to address the reasons for replacing our current
authentication method:
1) Redundant - every web server throws up its own authentication
pages and every web server must be configured independently to
utilize LDAP and mod_auth_pam
I agree that the basic service SSO provides is worth pursing. Log in once and your credentials follow you around
regardless of the service or server you bounce to. Provided we can shibbolize most services, this is a real benefit to
users. The LDAP and mod_auth_pam configuration that needs to exist on every web server would be replaced by a
single Shibboleth apache module and associated configuration. The differences between a per server one time set up of
two modules verses a single module doesn't seem like a major advantage.
2) Overkill - most pages that utilize authentication only require
encryption for the authentication process itself, and the rest of
the session can go to plain text; our current setup,
unfortunately, forces SSL/https for the remainder of the
authenticated session, and as a secondary side-effect, tends to
leave the user in an SSL encrypted session even after the part
requiring authentication has ended
I'd argue that continuing to encrypt the session post-authentication is actually a plus. The users electing to password
protect their pages would likely prefer that the content was encrypted. The overhead of maintaining the SSL connection
is probably very low on the list of things contributing to our overall response time. I think the server spends much more
time chugging through our PHP code and waiting on responses from MySQL than it does encrypting the traffic.
3) Insecure - because so many different servers throw up basic
authentication screens, users become conditioned to enter their
credentials whenever asked, making it incredibly easy for anyone
to throw up a basic authentication screen and grab Carleton
NetIDs and passwords (we saw this happen when I was at Brown, and
for this, and other, reasons put in SSO); also just the sheer
number of webservers through which credentials pass increases
dramatically the likelihood of compromise
It's true that our current authentication methods leaves us vulnerable to social engineering attacks. An enterprising
person could set up an .htaccess file and collect passwords by relying on users automatically entering their credentials
whenever prompted. The same kind of tricks can be used for the sort of login page Shibboleth provides. Shibboleth
would make it easier for users to distinguish a real login page from a phishing attack and it would also dramatically
reduce the number of servers which see user credentials. I think these are probably the most compelling reasons to
pursue it.
4) Isolated - our authentication infrastructure doesn't dovetail
with any larger efforts now afoot in higher education to deploy
federated authentication/authorization systems
I agree. Federated authentication/authorization opens up doors for collaboration and resource sharing with other
institutions that's well worth pursuing.
5) Restrictive - our setup only works for Apache-based web servers
and services
I agree here, too. At the same time it's only a benefit if those other
services work with Shibboleth and that's not a given.
I'd like to spend time learning about the different SSO options
available, experiment a little and fill in some of the gaps in my
understanding of the underlying mechanics. I need to be able to present
the how and why of adopting something like this to the rest of the group
and see how we want to prioritize it. It deserves a much broader
discussion beyond the WSG as well, and I want to have test-implemented
the basic functionality before that conversation so I can be confident
in what I'm promising.
Matt
>>> "Richard L. Goerwitz III" <rgoerwit@carleton.edu> 3/1/2006 1:43:34 PM >>>
Matt, Jaye, here's a list (recently compiled by shilen@duke.edu, Shilen
Patel) of what a number of institutions (mostly much bigger than ours)
are doing with single sign-on:
Stanford University - Stanford Webauth
Rutgers University - CAS
University of Virginia - Pubcookie
University of Minnesota - cookieauth
Cornell - CUWebAuth
Ohio State - Shibboleth
UCB - HP's Select Access
Brown University - Shibboleth
Penn State - Cosign
NYU - Expecting to use Sun Access Manager
Rice University - CAS
Case Western Reserve University - CAS
University of Bristol - CAS
University of Connecticut - CAS
Emory University - Netegrity Siteminder, OctetString’s Virtual Directory, and homegrown applications (pwsync)
University of Memphis - Shibboleth
Johns Hopkins - Netegrity Siteminder (But looking into Shibboleth and other technologies from Microsoft and IBM)
UChicago - Pubcookie (Looking into using Shibboleth)
Hope this is interesting!
The trend seems now to be to head towards Shibboleth, if it's practical.
But that may reflect my background (see the UofC and Brown lines; I've
worked both places).
(Brown finally replaced the single sign-on solution I set up for them
with Shibboleth!)