Federated Identity Management System: A Model for the University System of Maryland

A Federated Identity Management System will provide the best recipe for the generic identity management problem faced by many organizations as they rely on interconnected systems (often called the internet) to deliver business services across their entire enterprise.

What is a Federated System?

A Federated System is a collection of independent and para-independent entities each with its own autonomy loosely joined together by some specific agreement or association which definition determines the level of confidence each entity will have in other entities, and whose mechanisms are held together by some pre-agreed arbiter or super entity whose authority devolves directly from the association of the entities. Each Entity will be comprised of sub entities and or elements whose behavior is governed by the rules and policies imposed by the entity, thereby creating an inherent hierarchy of TRUST and enabling the delegation and inter-verification of trust between elements in different entities.


A Federated Identity Management System (FIMS) will comprise of autonomous entities each of which will define its own identity parameters and delegate (or export) specific characteristics of those parameter to the FISM Arbiter (or Super Entity), who will in-turn arbitrate trust levels between entities whose inherent identity parameters may differ, but whose delegated characteristics meets some pre-defined association rules.

The University Systems of Maryland is a system of 11 degree awarding colleges (Universities) and 2 research institutions scattered across the state of Maryland under distinct administrative control and with some level of autonomy at each institution. Information Technology , like all other services at each of these Institutions are independent operations and member institutions are realy tied together by the USM for procurement and other related state compliance issues. The environement and cultures at each institution could differ remarkably, yet students and faculty in each of these institutions often require access to shared resources accross the USM. Several fully autonomy past members of the USM also do have strong relationship with the USM with their staff and student requiring access to shared resources accross the board.

Accross this huge system there are an aggregate of more than 50000 students and several thousand faculties and staff. Each College within the USM system manages its own infrastructure and the identity of its staff, faculty and students. But accross the system, there is often a need for cross sharing of resources. This cross sharing is often done at some higher level in the system heirachy and this often translate into students managing multiple identities or disclossure of too much information to other colleges who do not need access to such priviledged information.

Even within the Colleges, there is always the challenge of identity management between different Schools as well as between different Departmental entities. Students, faculty and staff moving from School to school often require access to resources (computers in Labs, etc) in those different locations, but there's always a challenge on how to enable a campus wide identity for students (some have impleted some form of campus wide online id while others still contemplate their options), the challenge however grows between campuses.

And this is where Federated Identity Management comes into play. A mechanism that will enable organizational units create an hierachical trust relashionship such that subjects within each unit need only publish their 'complete' identity to their primary unit or department and other entities will rely on their trust relationship with the primary unit to grant access. The primary unit will ofcourse have to share information with peer units, but such information can be limited to only those required to establish trust and uniquely identify the subject. In the event that a security incident was committed by the subject, the primary (originating unit) will hold enough information to assist the compromised host in correlating the exact identity of the subject, when there is a doubt.

The mechanism for this would be such that the federating units do the following:

1. Designate (choose) a central arbiterwho will be responsible for certification and registration of units or entities

2. Agree on a minimum set of credential information required for establishing an accepted level of trust

Exact Identity structure may however vary from unit to unit (Departmental or College). The central arbiter may however have the authority to score each Unit's implementation and thus other unit may use scores so determined to determine security levels and thus enable trust levels to be granted subjects as they cross entity boundries.

Ok so much for background, lets look at an implementation scenario...