Identity Considerations

When considering the development or acquisition of a new software product, it’s important to answer some core identity management questions to help ensure that the selected product will integrate well with the university identity environment.

Account Management

How are user accounts conceptualized in your application?

Recall that there is a difference between an account, an identifier, and an identity. In short: User accounts are like keys, and the identity is the key ring which unifies them.

As an example, if you are running a UNIX service you may not be able to use NetID as the username due to namespace collisions. If you have multiple UNIX services, how would you link the accounts belonging to the same person across these different services? How would those user accounts then be linked back to an identity?

Not all accounts refer to people.

While an account is most frequently understood as referencing a person, non-person entities may have need for an account. For example, the NetID system supports service accounts that represent applications. You may need to consider if non-person accounts are appropriate for your application and, if so, how your application will handle these accounts (e.g. who has the right to make a request on behalf of a non-person account?).

Authentication

How will users authenticate?

You will need to start by knowing which authentication solutions are supported by your vendor/developer (e.g. SAML, OAuth, OIDC, etc.). If NetID-based authentication is not possible or not appropriate, you will need to consider how user accounts will be provisioned and managed over time, how they will be associated with the identity responsible for the actions taken with the account, and how authentication to the accounts will be managed.

How will you handle multi-factor authentication?

The university requires your use of multi-factor authentication. The solutions provided by the Identity Security team allow you to enforce multi-factor authentication on your applications.

Provisioning

How are user accounts going to be provisioned?

Especially with vendor-provided applications, you will need to consider how accounts are created in your application. For example, will these accounts be automatically created for a user upon their initial login attempt? Or will an administrator need to set up the account prior to the user’s initial login attempt?

How are authorizations provisioned?

Likewise, you need to consider that not all accounts in your application will be administrators. You will need to consider what the different authorizations in your application will be and how those authorizations will be granted. For example, will these authorizations be granted based on some attribute (e.g. a particular affiliation)? Or will an administrator need to manually authorize accounts?

Remember that authentication is not the same thing as authorization.

Authentication is the process of verifying that a user is who they claim to be. This is typically done by having the user provide a token (e.g. password) that only they know. Authorization is the process of checking to see that the user is allowed to access a requested resource or take a specific action. For example, after authentication your application may learn that the user is a student. Based on that knowledge, your application may then make an authorization decision that the user is or isn’t allowed to access a specific part of the application.

How does authorization work in your system?

You should understand how your application handle authorizations. Can authorization decisions be made based on attributes obtained during the authentication process? Or are all authorizations created and stored internally in the application?

Authorizations need to be reviewed over time (for example, once a year). Who is the right person to review those authorizations and audit them?

As you know, the University environment changes frequently. Students enroll and eventually graduate. Employees are hired, transferred, and terminated. Vendors are engaged and contracts end. As such, authorizations in your system will need to be reviewed on a regular basis. Depending on the sort of access your system provides, these reviews may need to occur as infrequently as once a year, or as often as once a week. You will also need to decide who in your area will be responsible for auditing those authorizations.

Deprovisioning

The University environment changes frequently. You will need to consider how accounts in your application are deprovisioned. There are two common events which might trigger deprovisioning.

Birthright changes occur when a University affiliation attribute of the user changes. For example, student graduation and employee termination are birthright changes that may need to trigger deprovisioning in your application.

Role changes occur when the identity’s affiliation itself doesn’t change but the nature of their work changes. For example, this will happen when an employee continues to be an employee, but their role within their department changes, or they transfer to a different department. Role changes are another common trigger for deprovisioning actions.

Authorization Reporting

You should be able to report on authorizations.

In order to ensure that users have the correct authorizations (and do not have authorizations which are inappropriate), your application should be able to provide a view into what authorizations an user has. To perform an audit (i.e., to perform an annual review) your application should provide the ability to report on authorizations.

Ideally, your application should be able to export authorization data into an external system.

An external system would allow authorization data to be collected into a single location to allow for holistic reporting, auditing, and management for authorizations.