Search Stanford:

Strategic Vision

• Overview
• Technology Principles

Documents by Service Area

• Authentication
• Authorization
• Backups
• Calendar
• Desktop Management
• Directory
• Email
• Identity Management
• Integration
• Networking
• Storage
• Voice
• WWW Services
• Windows Infrastructure

Related Pages

• Planning Documents
• IT Services Projects
• Project Management Office

• IT Services
• Strategic Vision
• Identity Management

Identity Management Strategic Vision

Lynn McRae, updated 10/30/05

Identity management is often used broadly to encompass not only requirements to correctly identify who a person is, but also the manifestations of that knowledge through infrastructure access and security services -- single signon, account/service provisioning, authentication and authorization. Here we focus on a narrower definition, principally the need to identify persons as one individual despite multiple associations and roles, proper identification of other entities and agents (organizations, applications, etc), and the management of that information over time and across the enterprise. Integration, Authentication and Authorization are in separate writeups. Some aspects of enriching identity information with additional attributes for other purposes are included here, but only to the extent that Identity Management processes supports the aggregation of information about an individual.

Principles

• We base identity on standardized, enterprise-wide definitions of data types, with appropriate technologies and resources employed to do mapping, resolve differences. Of specific concern are core identity attributes (e.g., name, SSN and birthdate), shared identifiers (e.g., univid, sunetid, cardid), and accurate status/affiliation data (e.g., faculty in department X, incoming student in department Y).
  
  
• There must be clear identification of data ownership and responsibility for the integrity of identity information over time. Data ownership must reside with cognizant business and academic units across campus. IT Services is seldom the owner except where data originates with IT Services provided services.
  
  
• We place a strong emphasis on the rights of the individual regardless of role, including an individual's ability to manage significant portions of their online identity themselves. This goes from a rich set of purely descriptive data (profile, address, preferrred title) to more specific identity information (preferred name, sunetid aliases).
  
  
• We provide, through policy and action, secure/responsible management of privacy end-to-end. This includes release of publishable data online through venues like StanfordWho, and appropriate controls over the release of information to central and departmental systems and to external service providers. As data is aggregated into a single identity from multiple sources, privacy protection must meet or exceed provisions made by individual sources.
  
  
• We provide multiple means of access to information -- directories, documents, web services, data marts -- to address different technologies and different levels of technical sophistication. This requires that the data is the same everywhere, and that there be a continuity of information access strategies across ERPs, directories, documents, warehouse, etc. While the delivery of the data is an integration issue, the commonality of the data lies here.
  
  
• Because we support a component/service/standards based infrastructure serving diverse technologies, comprehensive vendor solutions -- e.g., Oblix, CA's eTrust suite, MaxWare, PingIdentity -- are not likely candidate technologies. A single enterprise product would not serve the entire campus well. Instead we integrate technologies that fit well in each respective service categories (authentication, authorization, web, etc), and support alternatives as required, and justified, by the needs of the community.
  
  

Technologies

Stable core technologies:

• A Stanford developed Enterprise Person Object in Java that encapsulates identity matching, conflict resolution and related data management.
  
  
• Person regis -- Stanford developed document/event-based integration software.
  
  
• StanfordYou -- Stanford developed web-based self-service application for personal data management..
  
  
• Relational Database as the internal datastore (currently Sybase).
  
  
• A Stanford defined enterprise XML document to express identity information (document access/delivery is covered under Integration).
  
  
• A Stanford defined web-based document service to deliver XML Person, Account and Course information.
  
  
• X.500 directory standards and Stanford-deployed directories (OpenLDAP and Active Directory) for information access through LDAP.
  
  
• RegAdmin -- Stanford developed web based application for distributed data management tasks.
  
  
• Maintenance scripts, principally in Perl, to handle Data Administration and operational tasks against the data.
  
  
• Contributing systems:
  • PeopleSoft for faculty, staff and students. Some identity resolution takes placed across these populations through their shared "campus community" internal tables.
  • Corresponding SLAC and Hospital HR systems.
  • SUNet ID system, which manages a unique, enduring network identity namespace for online services.
  • Campus Card system for physical card identity information.
  • SUNet ID request-for-services and Sponsorship application to register new identities and provide identifying departmental affiliation data.
    
    

New technologies:

• Adopt xchema for better document definition and management.
  
  
• Evolving eduPerson, eduOrg and eduCourse attribute standards for federated identity among Higher Education.
  
  
• Oracle as the relational database engine (migrating from Sybase).
  
  

Deprecated technologies:

• Sybase as the RDBMS. IT Services as a whole is moving from Sybase to Oracle.
  
  

Projects

Recent:

• Completion of a 9 month Person "refactor/rewrite" effort to address reliability issues for Registry integration with data providers, particularly in areas of shared data. In included adopting a central support model for a number of client integration components, principally the event posters and harvesters for PeopleSoft, Hospital, SLAC, ID Card, AMCOM and Pinnacle.
  
  
• Refined identity-matching rules to decrease duplicate records, plus targeted exceptions to allow human review in cases where matching is ambiguous.
  
  
• Bring missing affiliate populations into the Registry, e.g., non-paid consulting faculty and visiting scholars. A new "non-employee" facility in PeopleSoft allows departmental entry of such individuals into PeopleSoft. Accomapnying affiliation and other descriptive information is used by the registry and downstream systems to implement service policies for these previously problematic groups.
  
  

First:

• Complete the Data Dictionary effort to thoroughly catalog the sources of data and their definitions.
  
  
• Articulate and publish policies of data ownership and responsibility
  
  
• Expand the functionality of RegAdmin to deliver distributed management of identity issues
  
  
• Solve Workgroup Manager performance problems. Group membership adds significant identifying information to a person that can be leveraged across services, principally for authorization. It needs to be a more usable technology.
  
  

Next:

• Develop support for guest identities.
  
  
• Implement solution for a single source of University ID assignments.
  
  
• Extend SUNet ID namespace management to application accounts.
  
  
• Enable organization-based and course-based workgroups and pass them to the Directory as privgroups.
  
  
• Support Coursework request to add information about TAs and class auditors back to the Registry.
  
  
• Implement full UNICODE support (UTF-8 encoding standard) and internationalization (concerns quality of international identity information, like foreign names).
  
  
• Integrate of application identities into the Account Registry and related service architecture (including both kerberos and X.509 cert identities).
  
  

Later:

• Migrate registries from Sybase to Oracle.
  
  
• Implement Organization Registry as viable identity provider to systems and the infrastructure:
  • Automate integration of administrative and academic hierarchies
  • Publish organization data through the directory
    
    
• Additional populations:
  • Person: office of development
  • Organization: ASSU, SLAC
    
    
• Tie privacy support to an Attribute Release Policy system that supports privacy granularity by services
  
  
• SAML support as part of Shibboleth federated authentication and authorization.
  
  
• Join InCommon Federation
  
  
• Develop new Registries for
  • Policy management
  • Content management
  • Space management
    
    

Research

• Look at higher-ed solutions for cooperative development and shared solutions, in particular the middleware architecture promoted by the Internet2/NMI/MACE group (Network Middleware Initiative/Middleware Architecture Committee for Education)
  
  
• Join InQueue federation and begin dealing with issues of Federated identity across institutions
  
  
• Track vendor-provided identity management solutions, especially those that embrace the same standards adopted for higher Education.
  
  
• Investigate richer datatypes (documents, objects); focus on support for images and their use, e.g., facebooks.
  
  
• More formal and comprehensive approach to Roles and how they are described in our data