In the 20th Century, every information resource was responsible for maintaining a list of allowed users and their passwords.� To access information you had to provide a login name and password recognized by that service.� As the number of different services proliferated, you might well have dozens of different login names and passwords, and keeping track of them all became not merely inconvenient but a barrier to effective use and a security threat.� 21st Century access management tools being deployed at UA address the following inherent limitations of this outdated method:

1.� Reduce the number of passwords:� When each information resource set its own requirements and conventions for passwords, you could easily have dozens of different username - password combinations.� Empirical studies and anecdotes agree that some people resort to using very easy passwords, letting a web browser "remember" passwords, writing them down next to their computer, or other tactics that can lead to unauthorized access and compromised data.� Many people attempt to simplify things for themselves by using the same password for many applications.�
Attempts to keep track of and/or synchronize passwords among different accounts inevitably fail because of differing requirements or temporary communications interruptions.� Once out of synch, it can be confusing and difficult to reestablish.

In contrast, services that subscribe to a central authentication service do not manage the login names and passwords of users; instead they rely on an Identity Provider service which is responsible for validating login ids and passwords. Whichever application or information resource you access, uses the same login id and password from the same Identity Provider.� So instead of many services each maintaining a login id and password for you, there is just the one store, and just one login id and password for accessing any of the participating services.� Not only is this easier for you, removing the burden of maintaining login ids, passwords, reset procedures, and the like makes deploying information resources simpler.

2.� Keeping you password hidden: Traditional security entails sending your personal password to the service you are accessing.� There is always a chance that the service has a flaw (intentionally or unintentionally) that will enable your password to be captured and used by a miscreant.� Since some people use the same password on multiple systems, such an event can spread damage beyond the compromised system.� In contrast, services that rely on the UA Identity Provider (IdP) do not see your password - instead they rely on assertions from the IdP.� Thus your password cannot be compromised by weaknesses in any outside service or its operation.� The strategy of you and the service both trusting a third party has been a mainstay of secure login for a quarter century, but is only recently been extended to web based services.

3.� Single sign-on:� An Identity Provider's use of a central password store reduces the number of different passwords that need to be managed, but depending on the number of different services or information resources you use you may still have to type in your credentials many times per day.� UA, like many universities, is adopting authentication protocols that enable many web applications - even though they know nothing about each other - to rely on a single authentication or login event.� Suppose you have just logged in to a research database licensed through the library, relying on central authentication by the UA Identity Provider, and you now realize you need to review some course materials posted elsewhere (for this example, assume on UA iTunes site).� When you point your browser to this second resource, it connects to the Identity Provider; the IdP already has established that you recently authenticated (provided valid username and password), and it relays that fact to this second resource; the result is that you are authenticated or "logged in" to the second resource without having to re-enter your username and password.

4.� Respect your privacy: When sharing credentials (and perhaps other information about you such as date of birth) the services you use may learn and store more information about you than is necessary, compromising your privacy.� If, for example, the University licenses access to an online encyclopedia that asks you to log in and asks for your date of birth to enable you to reset your password if you forget it, that service can maintain a history of what you look for in the encyclopedia.� Worse, information about your use of different resources might be combined to provide a disturbingly detailed portrait of your actions.�

UA's Identity Provider is an implementation of the Shibboleth protocol developed by higher education to enable provision of services to users while protecting users' privacy.� It does so by sharing only information that is absolutely necessary and explicitly configured to be released for each service.� For example, a service may rely on an assertion from the IdP that you are a current student in a particular program, or an employee at a specific campus - but not reveal your name or id #.�� Thus there is no "trail" leading back to a specific person.� Of course, some services, such as your email account, do need to know exactly who you are in order to present you with the information to which you are entitled, but others may need far less.
�

• More information on Identity and Access Management at UA is at http://www.alaska.edu/oit/iam
• A description of the InCommon Federation that enables trust between information resources elsewhere and the UA Identity Provider is at http://www.incommonfederation.org/
• The privacy-preserving web single sign-on protocol used within and across institutional boundaries is described at http://shibboleth.internet2.edu/

OIT's Training & Development Group reminds you that you can take a look and signup for our upcoming classes via our web page - htrtrp://www.alaska.edu/oit/training.

There are several new items this fall.

1. Microsoft Office 2010 classes will be making their debut mid to late October
2. Beginning in September, Blackboard virtual office hours will be available on Fridays between 10:00 am and noon - you'll be able to reach the virtual office (via elive) through http://bit.ly/bbvirtual
3. Beginning in September we will be offering 2 different podcast related classes
4. Also beginning in September, we will be offering a class on how to configure and set up an iTunes U course (your iTunes U course must already be created).

Looking a little further to the future, TechFest 2010 is coming (http://www.alaska.edu/oit/techfest2010) and our office will be providing a wide variety of classes (at least 9)

And one last item, the Training & Development Group will be having an open house for Faculty & Staff, August 26th from 1:30 - 4:00 pm in Bunnell 319 - come meet & talk to us if you've got training questions!

Remember we are only a call or email away!

Chris Beks - cgbeks@alaska.edu - x6796
Gary Bender - gabender@alaska.edu - x6573
Cara Brunk - cbrunk@alaska.edu - 8385
Martin Miller - msmiller@alaska.edu - x8304