This is the second of a two-part series introducing the Identity and Access Management (IAM)project at the University of Illinois.  Read part 1, Identity.  More information can be found on the IAM project website.

Authorization

You will recall from the first post on IAM that authentication deals with determining whether someone is who they claim to be.  Authorization is concerned with determining what resources a person can use after they have passed authentication.  The most common authorization method at the University of Illinois uses Active Directory.  An identity (remember, one person, one identity) is added to one or more active directory groups, and those groups are granted permissions for using resources or accessing services.

One common problem with authorization is that many services don’t use it.  There are a lot of applications on campus, especially websites, that require a Bluestem login to access them.  In some cases, after Bluestem passes the authentication (the website trusts that the user is who they claim to be), there are no authorization checks to ensure that the person should be able to access the page.  This happens because of old policy; when a person ends their affiliation with the University, their accounts are deactivated.  For services that are expected to be available to all University-affiliated people, there was never a need for authorization.

• Authentication – Are you who you claim to be?
• Authorization – Are you allowed to use this resource?

Identity for Life

One of the stated goals for IAM is that once a person has claimed an identity, it is theirs for life (and possibly longer).  Making this change would allow places like the Library to offer services to alumni and retirees without creating a new identity for them, or lumping them in with other unauthenticated users.  It has some interesting and wide-reaching implications, such as eliminating the need for zero-time appointments.

But this also creates a problem for applications that don’t use authorization, or that are very loose with it.  There is a lot of talk about allowing retirees and alumni to continue to use Library resources.  But what about all the students who applied to the University, but never actually took a class?  Poor access management could cost millions of dollars, as publishers and other rights holders demand more money for current subscriptions because there are many more people with access.

Fewer Passwords

There are quite a few things to get excited about with IAM, but perhaps the most anticipated service is single sign-on (SSO).  Since there will be a single identity store making sure you are who you claim to be, there is no reason for dozens of different applications to ask for your password.  You just gave a password when you logged into your computer, why do you need to do so again when you open email, go to your department’s internal website, access the wiki, or anything else?

This concept can be extended even further, to off-campus applications.  The final stage of IAM will create federation between the University and other institutions.  This will allow people to use their existing logins/passwords from Illinois to access resources that are run somewhere else.

What does this mean for the Library?

Library IT is preparing for this change on several fronts.  We are examining our services to ensure that they use proper authorization, and cleaning out old permissions for people who have left the Library.  We are also cataloging each of our secure services to address what the proper authentication and authorization processes should be.

In doing this, we will enlist the help of many Library service owners – the people working with patrons to provide a usable Library service – to identify the required level of authentication trust and proper authorization requirements for each service.  A committee has also been formed to identify and solve potential problems with the IAM project that could affect the Library.

This is the first of a two-part series introducing the Identity and Access Management (IAM)project at the University of Illinois.  Read part 2, Access Management.  More information can be found on the IAM project website.

Authentication

When someone tells you who they are, do you believe them?  If it’s a casual introduction, “Hi, my name is Jason,” then probably you do believe them every time.  If it’s during a transaction, like checking out a book from the Library, you probably ask for some proof (like showing a library card).  If the person is trying to access their bank account online, they are asked for a password.

The process of determining whether someone is who they claim to be is called authentication.  There are certain levels of trust associated with authentication, which are appropriate for different types of interaction.  When I introduce myself to someone on the bus, there’s no logical reason to complicate things by making me prove who I am.   When I access my credit card accounts, though, I want some pretty strong safeguards in place so I can be reasonably sure no one else is getting into my financial transactions.

The University currently has several methods for authentication, which are very loosely coupled, and that don’t rely on the same basic requirements.  There have been reports of people using, for example, a guest library card to convince someone at Campus Rec to also issue a day pass for the ARC.

The IAM project aims to address this situation by creating one source for information, a central identity store, which includes information on how trusted each identity is.  When a student applies for undergraduate admission, they may be entered into the identity store with a low trust level – we only know their email address, but that’s good enough for now.  The applicant then submits some paperwork, which may be checked against other sources (the Social Security Administration, credit bureaus, the high school the applicant attended, etc).  This adds increased trust, because it’s much more difficult to fake those records than it is to fake an email address.

One Person, One Identity

Currently, each U of I campus maintains its own identity store.  Different units may also have their own systems – the Library uses a database to differentiate between different patron types, for example.  Effectively, this means that a person could have several different identities with different levels of trust.  In order for that person to function on campus, all of these systems need to communicate with each other, and people who grant access to services need to be familiar with each of these other systems.

IAM will greatly reduce the complexity of identity management by ensuring that each and every person has one, and only one, identity.  The central identity store will be queried in various ways, depending on the level of trust required for the service being requested.

Identity and the Library

Creating and maintaining this store has several implications for the Library.  We currently gather patron information from ICard, CITES, and Active Directory.  Each feed has some delay associated with it, which creates a delay in updating the current information.  In the coming years, the IAM project will allow us to change how we query patron information, which should greatly simplify the current process and improve accuracy and timeliness of data.

But there are other issues that bring up problems.  As a public library, we do not require that patrons be affiliated with the University in order to use some services.  Will we need to expand the identity management store to include anyone who might be a patron?  Will we need to run a separate identity store for people who are not in the central one?  Will our service models change to allow a basic level of service for people without a U of I identity, which doesn’t require any identity proofing at all?  These are just a few of the questions we will have to address as the project moves forward.

Continue with part 2, Access Management

There’s actually quite a bit of documentation on the G and H drive already available, but not much of it has been consolidated into an easy-to-digest format.  To hopefully clear things up, the Digital Library Access, Repository, and Scholarly Commons Services group has put together a summary document.  It is currently housed on the CITES wiki, but will eventually move to a more permanent knowledge base – which just happens to be a great topic for a later post!  High fives to Betsy Kruger and Kyle Rimkus for helping to create the first draft.

The G and H drives are great places to store data that needs to be protected from accidental deletion or corruption.  The most common IT request (relating to backups) is that someone lost a file, or made an accidental edit that they couldn’t undo.  IT can quickly handle these requests for the G and H drive.  IT can easily restore files that were corrupted or deleted up to seven days ago.  We also have a policy of keeping backups for one year, but due to technology limitations, it is much more difficult to restore from those backup sets.

Box.com looks very similar to G and H at first glance.  The major drawback to Box is that you cannot get an on-demand restore.  The data is protected from disaster, such as a data center losing power from an earthquake, but the service does not allow you to restore a file that you accidentally deleted.  On the other hand, Box is the easiest way to share files with people outside the University.

The G and H drives are maintained by the Library, and we consistently increase the quota to meet the needs of our units and patrons.  Therefore, we frown upon using them for personal documents, such as your MP3 collection.  However, Box was commissioned as a replacement for Netfiles, which was specifically intended as common-good storage for staff and students.  So feel free to use Box for practically any (legal) need you have for storage.

We are eagerly looking forward to the upcoming storage and virtual infrastructure upgrade,  which will allow us to restore files to specific times of the day and go back much further than we currently do.  As we implement features of the new system, we hope to offer self-service restores.  This will allow you to roll back to an earlier version of your file, without having to get involved with OTRS or IT.