Leveraging Varying Level of Assurance
March 9, 2006 | 2 Comments
In higher education we all seem to struggle, at least a bit, with coupling together our many varied web services and applications. Part of the difficulty I see is the varied needs for how secure each of the services we delever need to be.
A common reaction to this is to lock things down tightly, requiring your users to reauthenticate on a regular basis to access even the most trivial of services. In this situation users feel encumbered by the security and are less satisfied using these services. Face it, who doesn’t love sites that know who we are and let us do the things we expect when we go back? (ex. Wordpress, Gmail, Flickr, Amazon, etc)
For the purposes of this article, I am defining level of assurance as how sure we are that the user on the other end of the browser is who we think they are.
I imagine an ideal situation where we identify a required level of assurance for each service, then check against an appropriate indicator.
A preliminary structure for varying levels of assurance:
| LOA | Who/How? | Example Services |
|---|---|---|
| Level 0 | Anonymous | Homepage, various public facing pages, etc |
| Level 1 | Long term cookie | Targeted Announcements, News Reader, Personalized Content, Bookmarks, etc |
| Level 2 | Active browser session or desktop domain login |
Email, Learning Management System, Calendar, Groups Tool, etc |
| Level 3 | 30 minute session | Financial Information, Grades, Address Information, etc |
| Level 4 | Every usage | Password change, others? |
In this scenario, users would be asked for credentials less frequently for less secure needs. This in turn encourages them to use many of these types of applications more frequently. In those less secure applications, “ticklers” can be placed encouraging them to register for classes, update address information, or check in on classes in the learning management system all as appropriate. This allows us to draw users into the more secure areas just like Amazon draws us into making a purchase, but always allows us to place things in our shopping cart.
Tags: browser, higher education, identity, identity management, level of assurance, loa, password, portal, session
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