Policy Number: 12-015

Identity Management Policies

Category: Information Technology

Responsible Executive: Vice President and Chief Information Officer

Responsible Office: Vice President and Chief Information Officer

  1. Purpose The university requires a secure and reliable method of identifying members of its community for access to electronic data resources. This requires collecting and maintaining identifying attributes, ensuring that electronic identities match the appropriate persons, and mechanisms to authenticate and authorize use of those identities.

  2. Applicability This policy applies to everyone with an identity included in the university’s central identity registry, as well as individuals authorized to perform identity management (IdM) functions on behalf of the university.
  3. Definitions
    • IdM Coordinator:  A UF workforce member who maintains data related to a person’s identification contained in the UF Directory for a specific unit of the UF enterprise. Individuals are delegated authority from the dean, director (or DDD) of the unit.
    • Primary IdM Coordinator:  A UF workforce member who serves as the primary contact for questions related to a person’s identification data for a unit. They are appointed by the dean or director of the unit.
    • Registration Authority (RA): An IdM Coordinator or Primary IdM Coordinator who has had additional special training to perform the credential verification functions to certify a user to meets Identity Assurance Profiles the require in person review.
  4. Policy Statement [Provide the policy specifics including all substantive aspects of the policy, any exceptions to the policy, and consequences for not following the policy. While the section format in this template is mandatory, the subsections and subtitles in the Policy Statement section will vary based upon the nature, size, and complexity of the policy itself. Use subsections and subtitles to organize the information and facilitate understanding.]

Additional Resources



Establish multiple levels of assurance for electronic identities, with attributes and requirements for their issuance. Multiple levels are needed to conduct the varied functions of the university, but can be handled without subjecting all users to the most rigorous levels of security


All electronic identities and accounts issued and maintained through the university’s IdM Directory Registry and GatorLink Account processes.


See the chart at the bottom of this document for the minimal attribute requirements for all each Identity Assurance Profile (IAP) defined in this standard. Eligibility for each IAP is conditional on having an appropriate UF Affiliation, which are listed in the UF Affiliation Reference.

Identity Assurance Profiles (IAPs)


UF FISMA Moderate offers a federal compliant FISMA Moderate certified proofing and Identity level. The user has been certified by UF proofing agents, possesses Multi-­‐‑Factor Authentication (MFA) capable credentials and has had no events to risk those credentials since the most recent proofing. This level is intended to comply with requirements for the NIST Level of Assurance 3 for credentials. UF FISMA Moderate identities are assigned a UF Password Complexity level of P6. Only qualified workforce members as defined in the UF FISMA Moderate Proofing Procedure may be assigned a UF FISMA Moderate profile. The user must also possess the UF FISMA Moderate approved MFA capability prior to proofing.

UF Proofing Agents serving as Registration Authorities for FISMA Moderate profiles
must verify a person’s identity and the specified Minimal Attributes Required before
granting a UF FISMA Moderate profile credential.


UF Blue offers a high level of assurance that an identity maps to the appropriate person. Qualified faculty, staff, students and workforce members with UF Bronze are assigned the Blue Assurance Level by enrolling in Two-Factor Authentication, and revert to Bronze if Two-Factor Authentication is removed.


UF Bronze is the default profile for active students, employees, and workforce members. The identity must have the Minimal Attributes Required, and UF Bronze identities may be assigned any UF Password Complexity level.

No in-person review of the credential is required for UF Bronze.


UF Basic Affiliate level is granted to anyone who has self-asserted their identity, or for whose identity is known by virtue of UF entered directory affiliations and the minimal attributes for this IAP. Examples include student applicants, library patrons, and selfregistration through a Learning Support System (such as to complete non-credit courses). This level is also assigned to students and workforce members who do not have the minimal attributes available for the Bronze profile.


UF Guest is a short-term temporary access level, for visitors to the UF campus who require temporary access to minimal services. Guests are not eligible for a permanent GatorLink ID and not listed in the IdM directory registry. Examples are seminar participants needing Internet access.

Guest identities are not eligible for promotion to any other IAP.


UF FISMA Moderate UF Blue UF Bronze UF Basic UF Guest
Business Name X X X X X
UFID Number X X X X X
Date of Birth X X X X
UF business e-mail address X X X X X
Workplace phone number X Only for Employees Only for Employees
Phone Number (workplace or personal) X X X X X
Social Security Number OR Passport Number X X X
Personal e-mail address X
Two-Factor Authentication Required X X


  • IAM-001: Identity Management Policy
  • UF Affiliations Reference http://identity.it.ufl.edu/identity-coordination/uf-directoryaffiliations/reference/
  • AC-002.02: Password Complexity Standard
  • NIST 800-63: Electronic Authentication Guideline
  • Federal Identity, Credentialing and Access Management Trust Framework Provider for Adoption Process (TFPAP) For Levels of Assurance 1, 2, and Non-PKI 3 Version 1.0.1
  • UF FISMA Moderate Proofing Procedure
  • UF Blue Registration and Proofing Procedure

Effective Date:

January 24, 2018

More Information

Identity Assurance Profiles Standard


Last updated: November 5, 2014


To establish requirements for services that make use of the university’s central identity registry to perform authentication and authorization that will ensure the security and integrity of identity information.


Any Service Provider that uses information from the central identity registry to authenticate and authorize users. Examples of technologies that incorporate information from the central identity registry for use by Service Providers include: Shibboleth, UF Active Directory, UF LDAP, and UF Kerberos. A Service Provider in this context is an application or web site that is authenticated by using the GatorLink account and password credentials.


  1. Service Providers must never commit user passwords to persistent storage.
  2. Shibboleth is the preferred authentication and authorization technology for web applications.
  3. Inclusion in the central identity registry provides no assurance of a person’s standing with the university. Authentication of credentials should be augmented with authorization assertions.
  4. Service Providers should use appropriate authorization techniques and attribute assertions available from the UF identity provider to verify that users are eligible to access the provided resources. Examples include checking level of assurance, affiliations, granted roles or group memberships.
  5. Service Providers should not use any login screen that is not provided by the central identity provider at UF. Exceptions to this may be granted after review of a Service Providers specific situation. Requests for exceptions can be made to the Identity & Access Management Office.


  • IDXXX Identity Management Policy
  • Procedure  for  Request  Exceptions
  • NIST  800-­‐‑63  Electronic  Authentication  Guideline
  • InCommon  Identity  Assurance  Profiles  (Bronze  &  Silver)  1.1
  • Federal  Identity,  Credentialing  and  Access  Management  Trust  Framework  Provider  for  Adoption  Process  (TFPAP)  For  Levels  of  Assurance  1,  2,  and  Non-­‐‑PKI  3  Version  1.0.1

More Information





Revision Date Description
March 30, 2012 Policy originally adopted
Policy updated