CAMP Shibboleth – Wrap Up
// June 29th, 2006 // 1 Comment » // Technology Bits
The following is a wrap-up of what I saw, heard, and hopefully learned from CAMP Shibboleth in Burlington, VT. As always with conferences and workshops, conversations with others and listening to questions asked are usually the most insightful and valuable moments. Much of this may seem scattered in thought, but I need to document these things somewhere…
1) Plymouth State is looking at Shibboleth as a way to accomplish centralized authZ. SunGard sold me on this idea months ago when I could only see Shibb as a federated WebISO solution. I was surprised to see that they are clearly marketing this use case as step two in your implementation plan. Number one is of course to get WebSSO implemented. Both of these are suggested before attacking the politics and policy of extending beyond institutional boundaries. It is clear that this is a smaller step base method that has stages of success. I like this a lot.
2) Shibboleth does attribute release or attribute assertions, not authZ. This seemed like semantics initially, but then I realized from responses to questions that this is an important distinction. Shibboleth could assert in some instances a common name attribute. This has no place in being used for authorization of any sort, but still may be useful, especially with intra-institutional home grown applications. An extremely valuable distinction to understand.
3) I learned that our current implementation methodology of CAS is not ideal. As we rely on an API based mechanism, the authN is coded into our system to rely on CAS. This does not make it as easy to change authN providers or WebSSO solutions as if we used a technology like mod_cas. This explanation from Scott Cantor was illuminating as it gave me a much clearer understanding of how the Shibboleth SP was intended to work when we begin Shibbolizing internal applications.
4) There is an increasing number of federated services becoming available from through third parties that interoperate with Shibboleth. None of these constitutes “the killer app” for Plymouth State University, yet. Of particular note, international federations seem to be moving and forming much quicker than ones in the US. In Europe, a fair number of library related companies appear on their prioritized vendor list including some Plymouth State licenses: EBSCO, JSTOR, and ExLibris.
5) Shibboleth 1.3 can interoperate with federal E-Authentication with a “simple plugin”. This may evolve into our killer application as the Department of Education brings student oriented services online. Currently there are schools using this method to connect so NSF grant applications and the like.
6) The “Where Are You From” (WAYF) concept and implementation has problems. They are even referring to it as “the weakest link.” I’ve had concerns about this, so am happy this is getting attention. In our initial implementation, I believe the simplicity of our environment should allow us to bypass the WAYF. Hopefully WAYF issues will be resolved by the time we start playing in the federated space.
7) When it comes to identity, SunGard’s Luminis causes nearly as many problems as it solves. Others seem to be struggling with this. I’m left wondering if SunGard’s research into the identity management space will eventually lead to some better redesign around this issue.
8) This group has awareness and respect for OpenID. Glad to see this on their radar. When am I getting around to using it?
9) We (Bill Baber, Petr Brym, Ted Wisniewski and myself) met with a representative from the consulting firm Aegis USA. They seem very tuned into what is going on in this space. They also seem to have solid experience working with the Sun Identity Suite which I assume will be a large contender as we work to improve our identity management infrastructure. USNH will be considering them as potential consultant as we look into identity management system wide.
10) Finally some terminology:
IdP – Identity Provider – the core Shibb service that knows who a user is and has access to some attributes it can assert about them.
SP – Service Provider – This is the end service that will consume Shibb asserted attributes. These are the applications we would refer to as “Shibbolized”
ARP – Attribute Release Policy – fairly complicated policies about what attributes are released for what services, and potentially on a per user basis. These are configured through XML.
WebSSO – this is a rebranding of WebISO. Not sure why, but I like it.
