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.