Leveraging Varying Level of Assurance

// March 9th, 2006 // My Stuff

Lock 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.

LOA, “level of assurance”, password, “identity management”, identity, browser, session, portal, higher education

Related items

2 Responses to “Leveraging Varying Level of Assurance”

Jon says:

March 9, 2006 at 9:30 pm

It makes sense to have the broadest level (lowest LOA) to be 0. That makes it more clear.

There will be many people who will see this as making things less secure but I think it’s important to notice how this makes things more secure.

In an all-or-nothing security paradigm, if you just want to check your “cartoon of the day” you must log in. If you walk away leaving yourself logged in you have exposed all your access.

Alternately, if your “cartoon of the day” is considered a Level 1 service, you can look at your cartoon and walk away without logging out you have only exposed a very basic level of access.

Every time we add another service to our portal we have this consideration, so we warn people, keep timeouts low, and take the complaints.
zbtirrell says:

March 9, 2006 at 9:51 pm

It is also important to note how much people always want us to increase the timeout. In an all or nothing situation, as you put it, making a change like that is a huge sacrifice in security. Even now they way we have it, 60 minutes, it’s probably a bit to long for a lot of the apps I’d put in Level 4.

No Sheep