Governance

Note to the Reader: This draft paper is being authored by Andrea Beesing at Cornell University. Please send comments and suggestions to authnframework-comments@internet2.edu.

Oversight is required to ensure that identification, authentication, and authorization services continue to meet business needs while maintaining the appropriate security and compliance with legal requirements. Areas for decision-making include the provisioning/credentialing process itself, operational standards and processes, application development best practices, and legal and regulatory compliance.

The credentialing/provisioning process

Processes will need to be established to create the credentials and ensure that they are issued to the correct person. These should be done according to a policy which describes the desired level of assurance and the steps needed during registration to achieve it. Usually it is easiest to set up these processes, if they follow already existing methods for registering people as closely as possible. Other points for consideration include:

- Determining which population groups are issued which type of credentials
- Determining the lifecycle of an identifier and credentials
- Understanding local community requirements vs. federated community needs
- Identifying the services each constituent group is entitled to receive automatically
- Determining how exceptions are handled

Operational standards and processes

Establishing and communicating operational standards and processes is a key role of governance. Considerations an institution may be required to take into account:

- Process for handling applications by service providers to participate in the security infrastructure
--- Receiving requests and registering the service provider
--- Issuing certificates if needed
--- Certifying after a beta period

- Tolerance for plaintext passwords
--- Whether and under what circumstances to allow them in transmission (over the web or in email)
--- Whether and under what circumstances to allow them on servers
--- Whether and under what circumstances to allow them in authentication forms

- Minimum requirements for the security of servers performing authentication and authorization functions
--- Physical security
--- Level of authentication required for administrator access
--- Number of staff who have access

- Password setting and changing
--- Password aging required or not
--- Complexity rules (e.g., more than 7 chars, includes letters and numerals)
--- Level of assurance required when a person forgets the password and needs a new one

- Federated frameworks, depending on how they are implemented, may bring dependencies that will need to be accounted for. Examples include:
--- Persistence of identifiers
--- Whether identifiers are opaque
--- Requirements to notify systems upon a change to identifiers

Application development best practices

Developers will require guidance in integrating their applications with the central authentication service. Examples of where best practices should be applied include:
- Functions or operations requiring two-factor authentication or re-authentication
- The interval of inactivity after which credentials will automatically time out
- Circumstances where a user logout function is desirable
Data stewards play an important role in informing these decisions since the type of data being accessed is a factor.

Legal and regulatory compliance

Other important roles of governance structures include:
- Ensuring compliance with governing laws and regulations (e.g., HIPAA, FERPA)
- Defining policies for managing trust with federated entities
- Ensuring that processes conform to policy and practice statements
- Working with technologists to determine authentication requirements for compliance with laws and regulations

Resources

At University of California Berkeley, IT governance is conducted by the eBerkeley Steering
Committee.

At UCLA, IT governance is conducted by the IT Planning Board. See the governance chart.

For more information about project governance, see the Assemble Resources section of the Enterprise Directory Implementation Roadmap.

Revision 1.0, December 12, 2004