Introducing: The Identity Management Project

The Identity Management Project kicked off in December of 2009. The current project team (small ‘t’) is Tom Cutter, Adam Franco, Mike Lynch, Chris Norris, Carol Peddie, Mark Pyfrom, Jeff Rehbach, Mike Roy, and Marcy Smith.

The Identity Management (IDM) project seeks to organize our concept of a “person” or “identity” among our various systems (including Banner, the Active Directory, web-applications, hosted systems, and others). This project focuses on three facets of each identity:

Unique identifier:
Every identity would have a unique identifier. Currently, only people in Banner have one of its identifiers (guests and vendor-staff aren’t in Banner) and only people in AD have log-in names (alumni, parents, and others aren’t in the AD).
Unified Properties:
Each identity will have a set of properties (name, email, address, title, department, etc) that is consistent and available to all of our applications. Currently user properties may be different or unavailable depending on which source of user information is used; a person’s title is a good example of this inconsistency.
Roles:
Identities will gain zero or more “roles” that can be used to grant or deny access to our systems and services. We currently have no consistent way (in AD or web applications) of determining if a person is a current student, faculty, staff, or other role — the best we can do now is to look at membership in certain mailing lists like “All_Faculty”. With the IDM project, we will be able to access an authoritative list of the current roles for a person (visitors would have no roles) and will be able to ensure that access to services properly matches an individual’s relationship to the college.

In addition to organizing and improving the properties and roles of our current set of users (current students, faculty, staff, emeriti, vendors, spouses, and limited guests), the IDM project will also enable us to expand the number of usable (authenticate-able) accounts to include alumni, prospective students, and visitors. As well, we gain the potential to include users from other institutions via federated authentication systems such as Shibboleth.

Here is a list of a few things that will become possible with completion of the IDM project:

  • Rather than accounts being immediately deleted upon graduation, they instead would loose the “student” role and gain the “alumnus” role. These users would continue to use their same log-in credentials access alumni-only and public resources (i.e. commenting on blogs, renewing library books), but would loose access to student-only resources (i.e. course websites, JStore and other subscription library materials).
  • We will be able to grant access (individually or in groups) to many of our online systems for guests, alumni, emeriti, visitors, vendors, perspectives, and others with loose affiliations with the college.
  • Inter-institutional projects will be able to make use of any of our online systems as collaboration platforms.
  • A fan of Middlebury Hockey could create a visitor account to use for purchasing panther gear from the college book store, then come back and log in with the same account to purchase tickets from the box office, make comments on the coach’s blog, and fill out a form to sign up their kids for participation in the Winter Carnival ice show. Their name, email, mailing address, and other properties would be available to all of the systems.

Please note that some of these examples will require additional changes and development projects beyond the IDM project itself. However, all require aspects of the IDM project to be possible.

2 thoughts on “Introducing: The Identity Management Project”

  1. Mary Backus

    I’m wondering if within the parameters of this project the team would examine the widespread use of shared identities in offices and departments on campus (LIS included) Should there continue to be generic logins which are used by groups of student workers, for example? I’m not sure if this fits with the project, but I wanted to bring up the question.

  2. Adam Franco Post author

    Thank you for the comments, Mary. Wholesale removal of role accounts is outside of the scope of this phase of the IDM project as currently envisioned. That said, the first phase of this project will provide us with an authoritative list of roles (e.g. student, alumnus, staff, faculty, emeritus, contractor, parent, applicant, etc) for all users, something we actually don’t have right now outside of Banner. For authorization checking through the Active Directory, roles will likely be accessed as read-only groups/group membership. While we may add direct provisioning of accounts to other systems, Active Directory will be the main initial target and the working repository of user information accessed by other systems.

    As a general comment about role accounts, it is really up to the application in question to support checking user attributes (such as group membership) and authorizing (granting or denying access) based on those attributes. Role accounts often pop up as a work-around when an application doesn’t support group-membership checking.

    Ideally, all applications would be configured to authenticate against the Active Directory via its LDAP protocol or the CAS single-sign-on protocol. Once a user’s credentials are verified (authenticated), the user’s groups would be checked against an list of groups allowed to access an application or perform certain actions. Access to the application is then managed by adding or removing users from the group in question. This is how access to private wikis (as well as Drupal pages, Segue sites, many other web applications, file-server shares, etc) are managed.

    When choosing and purchasing applications (both vendor-hosted and locally-hosted), support for group-authorizations should be one of the key features required. If this feature isn’t available, then often the only [unfortunate] work-around is to create role-identities with a shared password known by many people. Removal of these role accounts and reconfiguration to use group-based authorization can be done now with any application that supports it. For groups such as student-workers in any particular office, there is no need to wait for the IDM project, these groups can be created in the Active Directory now via Outlook or our web-based group manager.

Comments are closed.