Considerations

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

Authentication vs. 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.

Provisioning

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?

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 is authorization handled?

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?

Deprovisioning

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

Join/Leave

Student graduation and employee termination are join/leave changes that may need to trigger deprovisioning in your application.

Mover

Mover (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.