March 21, 2004
Shibboleth at NERCOMP 2004
NERCOMP 2004 starts today for preconference seminar. No offense to other NERCOMP presenters, was primarily interested in the Shibboleth topics so am only here in bits and pieces.
Today's preconference seminar is Shibboleth: Architecture and Implementation Requirements by Daniel Arrasjid of University at Buffalo and Steven Carmody of Brown University.
Was thinking I'd weblog about it real-time but it appears to be taboo at this conference.
First half of the presentation dug into identity management, which is an important precursor to Shibboleth. Daniel says "Long term, you're in a much better place to have identity management in place to drive Shibboleth." If you're going to attempt to authenticate and provide authorization attributes about a person to another institution it's a good thing to have the identity management to drive shib done right.
After a short break we got into Shibboleth. I've read a good chunk of the shib documentation in setting up a test environement but hadn't got to the point of configuring it to actually communicate with another organization. I had a number of questions regarding how to configure and how shib would interact with our existing authentication and authorization. The presentation and q-a session gave me more than enough information to work with. One slide titled Installation Process provided a nice summary of the steps to becoming a shib target.
- join a Federation
- configure Apache
- configure Shibboleth
- error handling
- Federation metadata
- key generation and certificate installation
- define attributes and attribute acceptance policies
- protect resources - create access control policy
The other pressing question was how to integrate into our existing system. A discussion about Buffalo's use of Shibboleth with Blackboard helped. At Buffalo when a user is authenticated via Shibboleth the attributes are used to dynamically provision a Blackboard account. We'd most likely do something similar, on an incoming, authoenticated shib request we'd take the attributes and verify the account status, creating a limited-use account. Right now the user account information is stored in a user table, but have thought a few times that it might be a good idea to be capable of creating user objects as a part of the session and only keep them around as long as the session is active. Something for the future.
The presentation was valuable and worth my time, have a clear sense of our path to being shibbified or shibbolized.
Posted by mike at March 21, 2004 1:03 PM