CAMP Shibboleth - Wrap Up
June 29, 2006 | 1 Comment
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.
Tags: aegis, aegis usa, arp, attribute release, camp, camp_062, eauthentication, educause, federation, identity management, idp, internet2, luminis, nmi-edit, openid, scott cantor, shibb, shibboleth, single sign on, sp, Sun Identity Suite, sungard, wayf, webiso, websso, xml
NERCOMP: Identity Management SIG
September 27, 2005 | 37 Comments
Yesterday we attended the NERCOMP Identity Management Workshop at the College of the Holy Cross.
Steve Carmody of Brown University explained an ideal infrastructure including a reminder for me to review “Identifiers, Authentication, and Directories: Best Practices for Higher Education” by Internet2. Carmody had a lot of great things to say, giving a solid overall update of how Internet2 and MACE are coming along with Shibboleth, Grouper, Signet, and various other initiatives. He also pointed me at Sun’s XACML Implementation which is very interesting.
Christopher Misra of UMass Amherst and Robert Banz of UMBC both presented on their current IdM initiatives. They both seem to have established IdM infratructures which need one enhancement or another.
In the final time slot was a general group discussion. I took this opportunity to ask how schools are establishing and maintaining credentials remotely. No one had an answer that was ideal, I suggested our current proposal and no one seemed to have any criticisms. One person suggested that maybe we don’t need to have as secure a system as we’re proposing to merely secure someone’s email. My reply to this was in a federated world with connections to the federal PKI bridge, InCommon services, and more, we are securing far more than email. It is our responsibility to have as high a level of assurance as possible.
Tags: authentication, authorization, credentials, grouper, higher education, identity, identity management, internet2, MACE, NERCOMP, password, passwords, shib, shibboleth, signet, xacml
Authentication Definition
September 26, 2005 | 5 Comments
According to Internet2, authentication or AuthN is defined as:
Authentication is the process of establishing whether or not a real-world subject is who or what its identifier says it is. Identity can be proven by:
- Something you know, like a password
- Something you have, as with smartcards, challenge-response mechanisms, or public-key certificates
- Something you are, as with positive photo identification, fingerprints, and biometrics
Once again, this is a nice concise definition. It’s good to have these clearly defined to eliminate any confusion or debate when discussing, similar to what I did with my “Single Sign-On Definition” post.
Tags: authenticate, authentication, authn, biometrics, challenge-response, definition, fingerprints, identity management, internet2, middleware, password, passwords, smartcards
Emerging PKI
July 28, 2005 | 2 Comments
This week four of us attended the 2005 EDUCAUSE/Dartmouth PKI Deployment Summit. Our intention was to get a feel for the status of client-side PKI.
Before I get into that, here is a definition of PKI from the UK Department of Health: (just happened to be the clearest, most concise one I could find.)
“A public-key infrastructure (PKI) is the set of policies, people, processes, technology and services that make it possible to deploy and manage the use of public-key cryptography and digital certificates on a wide-scale.”
What about the client-side part? I can’t find a clean definition of this alone, but here’s my summary. Client-side PKI is the assignment of digital certificates to end users for the purpose of authentication without the need for usernames and passwords. An end user could then present their personal certificate as either a soft-copy or on a hardware token to gain access to systems and services they are authorized for. In general deployment of client-side PKI gives a much greater level of assurance (LOA) that the user is in fact who they claim to be.
With the vast number and variety of integrated and disparate systems in most higher education institutions, coupled with a need to be sure only appropriate users are gaining access to them, client-side PKI becomes an attractive technology.
One of the more interesting presentations was from Peter Alterman on behalf of the Federal Public Key Infrastructure Authority. He spoke at great length about LOA and what levels would allow you to map to other levels of access to federal services through the Federal Bridge. I assume there will eventually be a great number of services provided through the bride which will be of interest to higher ed, so institutions need to be aware of the hoops you may need to jump through to get certified. Keep in mind that usernames and passwords will only qualify you for minimal connectivity and services.
So why not roll out client-side PKI at your institutions as quickly as possible? Well… it is complex, the road is mostly unpaved, and it is hugely expensive. Each user needs to have a certificate assigned to them and renewed annually. The outright cost of these are usually $8-$15. Under the newly formed EDUCAUSE Identity Management Services Program (IMSP) a reduced price has been negotiated with VeriSign dropping the price to about $4 (or less depending on volume). Looking at a basic higher education institute with say 7000 users, that gives an annual price tag of $28,000. Put alumni in the same mix and that price gets worse. Then there is a cost associated with hardware tokens if you decide to use those. My understanding is that these run about $30 ($210,000 for 7000). The only way this could actually be funded would be to pass this cost along to the students in their technology fee and have departments budgets handle it for faulty and staff.
Many institutions are avoiding all of this by signing their own certificates. Of course this then prompts users about unknown signing authority which might cause calls to the help desk with confused users. This is the solution MIT, USC, and others have adopted.
There is another solution nearing availability, USHER, the US Higher Education Root. According to Neal McBurnett of Internet2, USHER will:
provide a basis for campuses to deploy signed documents, secure email, and other applications. Serving as both an infrastructure and an initiative, it will include a root (AKA trust anchor or certification authority) to identify campus roots [CA's], and recommended applications, tools and metadata. It will coordinate with the InCommon federation.
Assuming the USHER CA finds its way into the major browsers as an accepted signing authority, it will provide higher education with an affordable solution for digital certificates. USHER is a key player in multiple Internet2 initiatives including the InCommon Federation and Shibboleth. USHER does not yet seem to have its own web site, but is being coordinated by HEPKI-TAG. I believe USHER is the lynch pin for general deployment of PKI in higher education.
Tags: authentication, certificates, digital certificates, educause, federal bridge, federated identity management, federations, HEPKI-TAG, higher education, identity management, incommon, internet2, loa, middleware, pki, public key infrastructure, SSL, USHER, verisign