We had a mix of people from central IT to Registrars in the audience.  We had schools that had fairly mature IAM systems to some who were just starting.  It was a fun time and there was good conversations.

Karen and I also had fun running around Minneapolis.  We had great food at Zelo and Masa and listened to the Spaghetti Western String Company.   We also saw the Picasso exhibit at the Walker Art Museum.

One of the better conferences trips that I’ve had in a while.

The first was a breakout By Peer Groups. In this break out, Registrars sat together, CIOs sat together, etc. I was in the IT Idenity Management peer group. There were strong themes that came up during this discussion. Interestingly, the strongest themes were around:

• Governance – how do you establish it on campus, how do you get buy in, who should be on the governance board,
• Communication – the need for a common vocabulary for communicating with campus about Identity Management.
• CAF Credential Assessment Framework PDF – Especially as a tool to find gaps in the infrastructure and as a communication tool with campus. If the campus want’s to use FASTLANE and NIH Grants and other applications, we will have to fill these gaps that are identified in the CAF Process.
• Mapping of Levels of Assurance to Risk Assessments for various applications. Development of a Framework to map LOAs to Risk Levels for Applications.

It is interesting that the Technologists didn’t list a bunch of technologies. There concerns were mostly around communication, governance and policy.

We then had a break-out by University. Each University would then gather and discuss what they had learned, their concerns, their thoughts on what their next steps should be. From the University of Wisconsin – Madison break-out, I had the following list (which aligns with the list that we presented but isn’t exactly the same):

1. Doing a CAF analysis and obtaining level 1 of LOA
2. Building a business case for Identity Management for campus. (Note: I believe that the CAF process can feed into the business case)
3. Tracking the Federal eAuthentication, CAF, Federal Identifier and other initiatives. We need to keep up with the Federal initiatives and changes and to communicate those changes with campus
4. Build out of Identity Management infrastructure (specifically our PASE initiative which manages Groups and Entitlements).

Report out from all of the Universities:

Common threads were:

• Establishing Governance, building a common vocabulary and Funding and Prioritization and Staffing.
• Going through some version of the CAF process (maybe not bringing in the OMB but working through the analysis internally).
• Dealing with “Privilege Bloat” – users accumulating access as they move around campus and change jobs
• Federating with Federal Government especially around Research.
• Separating Authentication from Authorization.
• Education of the population – how to protect their own data and the institutional data.
• How to serve affiliated populations – like distance ed, research collaborators, etc
• 2-factor Authentication came up at U-Minn.
• Look at joining inCommon which will push people to document what they do.

Next Steps

1. Each University submit their summary / prioritized list so that they can be published as a group
2. The Universities that are going through the CAF process would like to gather to compare notes
3. Work together and join InCommon so we can federate with each other and to show vendors that we think this is important
4. Sharing notes on Governance – especially those who are building new governance structures – what are you trying, how is it going, documentation that might be sharable and adaptable
5. Should there be a regular CIC Identity Management Meeting? Take this up via email and the CIC CIOs planning group
6. Generate common requirements for software that we could use with vendors. Note: there are two flavors of this: (1) What the software should do now and (2) what the vendors should be working towards. The second is where the CIC might want to focus

This panel session discussed Federated Identity Management and Sharing Resources. The slides are here as a PDF

I was the moderator for the session. The panelists were:

1. Kevin Morooney, PSU, Senior Director, Academic Services
2. Kenneth Forstmeier, PSU, Director Office of Research Information Systems
3. Mike Grady, UIUC, Sr. Technology Architect & Strategist
4. Phyllis Davidson, IU, Interim Assistant Dean for Digital and I.T. Services

Below are the highlights that I took away from the panel.

Kevin Morooney

Penn State University (PSU) has moved along way down the identity management roadmap. They have two levels of internal authentication with their WebAccess for most applications and SecureID for higher level of assurance applications. They are using Shibboleth to handle federated IdM with several outside service providers.

Kevin lists many of the Web2.0 applications (like Flickr, Wikis et al) as an interesting case that we need to think about. Much of our students and faculty are using these applications. Should the University provide a federated IdM process for their faculty and students to access these applications? Which ones should be brought in house?

Kenneth Forstmeir

Researchers interacting with the federal government need to manage dozens of user accounts and passwords. Each of the applications that they use have their own username/password pair and their own policies regarding password change policies. The researcher cannot synchronize their usernames across these systems. Federation would help with part of this problem but the solution must include a method for researchers to maintain their account information when they change institutions. The researcher must be able to remap their identity with the government to a new set of credentials.

Mike Grady

UIUC started looking at using Shibboleth for library content – specifically content providers like Elsevier et al. The contracts with the content providers are often based on a fixed set of IP addresses and they are often for multiple years. The change to federation would allow UIUC to move groups to new IP ranges. The change to a federated system would cause users to log in to resources which they were used to accessing automatically (because they were in the IP address range).

UIUC also uses federation intra-institutional. Federation technology (like Shibboleth) can be used inside the institution to federate between separate identity management systems.

Phyllis Davidson

Phyllis presented several interesting use cases for federated identity management. One of which is “Chat Reference”. The library provides reference support via chat 24 hours a day. They would like to be able to share the resources with other libraries. Each library would provide some hours of support but be able to reduce their overall cost. Other use cases involve Digitized Collections which could be hosted at various institutions but shared amongst the whole.

IP based access does not let you control levels of access based on Roles. This is another thing that would come with federated identity and access management.

The Q and A

Where do Help Desk Questions go? When a user can’t log in to a resource, who do they call? How do they know who to call? This is negotiated in the SLA between the Service Provider and the Identity Provider. Scott Cantor states that it must be the Service Provider first.

The legal agreements between the Service Provider and Service Consumer need to include agreements about how help desk issues will be dealt with. This agreement then needs to be communicated to the end users so they know who to call.

JimPhelps, ITArchitect, IT-Architecture, IdM, IdentityManagment,

It is an interesting example of the basic Authentication / Authorization flow:

1. The Authentication is based on the “something you have” and “something you know” schemes. They have a phone with a phone number and they know my phone number (or they have misdialed).
2. The caller presents an Identifier – their phone number.
3. My phone checks the Identifier against the “known and trusted user” directory – my Address book.
— If the Identifier matches a user the directory, Bio/Demo data is expressed and I grant access or deny based on criteria for service access (if I’m in a meeting, I may not answer a call from my Wife but may answer a call from the CIO). Another way to think of this is that different users have different access levels – the CIO has a high access level during work hours, my nephew has a lower access level during work hours.
— If the Identifier doesn’t match a user in the directory, I may grant access or I may request further Identifiers (e.g. the user’s voice and message of intent in my voice mail)

This example highlights some interesting challenges in Authentication / Authorization schemes: Access based on time (user X can get access services during normal business hours but not after hours), Exertion of further Identifiers (user X is not in our Directory but is in another trusted Directory or can present further credentials to gain access), Requiring additional credentials prior to granting access (user X has successfully logged in with NetID and Password but needs another credential to gain further access).

Dealing with new hires. Desire to deliver email prior to hire. Getting HR to understand that they are part of a larger flow. The only interest isn’t just in the HR department.

Can’t treat the value of the identity of a “potential student” as equal with a “PI” on campus.

What do you want to do for people? Getting agreement on that on campus is 80% of the work.

We have to create a vision of the better place to be. Then you can talk about the vision for the future and the techniques for getting there

Key functions of the future:

1. Reflect – track information from key systems. Can’t gather all information from all systems but pick the best source for the population
2. Join – combine identities from various sources to represent the actual individuals.

Michael Gettes – Credentialing

What are the process (business process) that you have for credentialling?