Identity Management at the University of Florida Mike Conlon, Director of Data Infrastructure University of Florida, Gainesville, Florida Background Asserting Identity – GatorLink Identity Management Entities Service Oriented Architecture for Credential Management The data model for UF IDM entities is shown in Figure 2. Password Policies are associated with Roles. Roles are associated with persons, as are credentials and affiliations. Affiliations are used as business process groupings of people and may generate automated role assignment by policy for access to services. The UF IDM entities treat Level of Assurance (LoA) as a property of a person object, not a credential. The LoA has to do with the certainty we have that a particular person corresponds to a particular person identifier (UFID) in our enterprise directory. Credentials associated with the UFID have the LoA of the UFID. The GLAM Project completes a three year effort to standardize identity management and authentication services and systems at UF. Future work includes: Parents will be added to directory and authentication systems Implementation of groups Consolidation of free-standing LDAP and Kerberos systems with AD-based solutions Multiple accounts per person supporting distinct legal entities Implementation of PeopleSoft roles as AD security groups Build out of SOA solutions for providing directory information to campus applications Consideration of InfoCard and other federated identity solutions Policy: All individuals associated with UF must be in the UF Directory. All faculty, staff and students must maintain current contact information in the UF Directory. All systems must use the UFID as the primary person identifier. No system other than the UF Directory may create identity. Identity Management – its policies, procedures and systems – answers the following questions for an institution: Who is in our environment? How can people assert identity when accessing computer systems? What are people authorized to do? The University of Florida has embarked on a series of large scale projects to transform its identity management to address these three questions. In doing so, the University has established new identifiers, developed new policies, procedures and systems for managing its identifiers, credentials and security roles. Started in 1997, GatorLink provides a reduced sign on (RSO) environment for UF computer users. Originally based on Kerberos, GatorLink usernames and passwords have expanded and transformed to be the one set of credentials used by most university systems. UF currently manages over 160 thousand active GatorLinks. Policy: In 2002, GatorLink was named as the standard credential for enterprise systems. Policy defines who can get a GatorLink, how GatorLinks expire, how passwords must be defined and how often passwords must change. Password policy is defined by a user’s security roles. Each role has a password policy. A user’s credential has the highest password policy associated with any of the user’s roles. See IDM Entities. Procedure: GatorLinks are assigned via self-service. All UF users visit www.gatorlink.ufl.edu to create their new GatorLink credentials – choosing a username and password of their choice consistent with university policy. Projects: In May 2004, the GatorLink Password Management Project implemented password policies associated with User Security Roles. All GatorLink passwords were changed and brought into the policy by May of 2005. In November 2006, the GatorLink Account Management (GLAM) project extended the username to 16 characters, implemented a SOAP-based architecture for credential management, created guest account processes and management software, defined and implemented policy and procedure for automatic expiration of credentials. During implementation, over 45,000 credentials were expired. Systems: GatorLink is implemented across LDAP, Kerberos, NDS, Active Directory, GLAuth (WebISO) and PeopleSoft. Access to enterprise systems are controlled by roles assigned to users. Users are assigned algorithmically according to policy via synchronization processes from the UF Directory. Manual requests for roles can be made via Department Security Administrators through the Access Request System (ARS) in PeopleSoft. Users can see their roles using the “My Roles” application in the my.ufl.edu portal (see right). Figure 2. Identity Management Entities at the University of Florida. A system block diagram is shown Figure 3. End users and Help Desk Users interact with custom PeopleSoft screens to create credentials, change passwords and perform other credential management actions. Systems and data flows in blue represent service oriented architecture processes. PeopleSoft sends XML to BizTalk which in turns provides SOAP messages to receivers for Active Directory, NDS and Kerberos. Upon receipt, these systems update themselves appropriately. SOAP messages can also be received by departmental systems if needed. UF Directory http://www.bridges.ufl.edu/directory Password Policy http://www.it.ufl.edu/policies/passwords.html GatorLink http://www.bridges.ufl.edu/gatorlink Mike Conlon Director of Data Infrastructure University of Florida mconlon@ufl.edu Who is in Our Environment – the UF Directory and UFID Project: In 2000, the University began an investigation to determine how to approach the fundamental questions of identity management. In the fall of 2001 work began on a new enterprise person registry with a new person identifier, the UFID – an 8 digit, non-revocable, opaque identifier assigned to every person affiliation with UF past or present. UFID has replaced SSN as the primary identifier in all UF systems. The UF Directory was launched in January of 2003 and to date over 1.4 million UFIDs have been issued. Figure 3. Users interact with PeopleSoft for credential management. PeopleSoft uses two methods for replicating credential information – SOA-based methods (blue) and database-based methods (orange). Policy Next Steps Credential policy is recommended by the Information Technical Advisory Council Data Infrastructure committee and consists of yes/no values for each directory affiliation. A portion of the approved policy is shown below. Affiliation Credential Affiliation Credential Alumni No Emeritus Yes Board of Trustee Yes Faculty Yes Campus Resident Yes Former Student Yes Courtesy Faculty Yes Vendor Yes Password policy consists of a matrix of 5 policies and 15 attributes per policy defining five password policies that are then assigned to each security role. A user’s password policy is the maximum password policy assigned to any of the user’s assigned roles. A portion of the password policy matrix is shown below. Procedure: Identity is established by directory coordinators, authorized University employees who enter information into the directory and are issued the UFID. The UFID is present on the UF’s photo id, the Gator1 card. Identity is also established by application processes for students. What Are People Authorized To Do – User Security Roles More information Student applicants are issued a UFID on completion of their application. Guest identity (low assurance) can be established by persons authorized to create guest accounts. Systems: The UF Directory is currently a mainframe application with data residing in a collection of 145 locally developed DB2 tables. Services queues are used to “slave” Directory, Authentication and Authorization systems to the UF Directory. Over 50 queues support replication to Active Directory, NDS, LDAP, Student systems, PeopleSoft, Housing, Hospital Systems, the UF Foundation and many others. Attribute P1 P2 P3 P4 P5 Minimum Length of Password 8 8 8 9 9 Password is character checked Yes Yes Yes Yes Yes Max Age of Password in Days 365 365 180 90 90 May Reset via Self Service Hint Yes Yes Yes No No Requires Two Factor Auth No No No No Yes Figure 1. My Roles shows each user their security roles