This document provides a guideline to the Identity and Access Management (IAM) requirements that should be taken into account during any planning or purchasing process such as a formal or non formal Request for Proposal (RFP) or similar.
This document is organized into three sections: Account Provisioning & De-provisioning, Authentication, Authorization & Role Management. Each section will have a requirement goal and some number of sub elements that can be leveraged to reach that goal. Not all items have to be accounted for in integrating a given application.
Account Provisioning & De-Provisioning Requirement
The application will integrate the CUBoulder identity record lifecycle (create, update and delete operations).
- [ACT-1A] The application will create, update and delete user accounts within the applications domain using a batch feed process. **
- [ACT-2A] The application will enable create, update and delete user account operations within the application through an API that CUBoulder has access to (push method). *
- [ACT-3A] The application will enable create and updates to user account objects within the application by consuming SAML attributes at the time of user login (JIT method). Note: Using this method does not allow for de-provisioning of account objects on the application side. *
The application will integrate with current CUBoulder authentication services and protocols to provide access to the application.
- [AUTHN-1A] CUBoulder IdentiKey authentication will be verified using SAML2 protocol and the CUBoulder IdP.
- [AUTHN-1B] CUBoulder IdentiKey authentication will be verified using Windows Authentication and the CUBoulder ActiveDirectory.
- [AUTHN-2] The application will use InCommon as the source for CUBoulder SAML metadata (applies for SAML [AUTHN-1A]).
- [AUTHN-3] The application provides a mechanism for an authorized user to impersonate another user in the application without needing their password.
Authorization & Role Management Requirement
The application will integrate with current CUBoulder services to manage groups, permissions and roles.
- [AUTHZ-1] The application has an access control model that can be extended to accommodate CUBoulder custom roles.[AUTHZ-2] The application can map groups or individuals into roles.
- [AUTHZ-3] The application allows CUBoulder to customize the permissions applied to roles.
- [AUTHZ-4] The application supports multiple roles per user without requiring multiple accounts.
- [AUTHZ-5A] The application can manage groups and roles based on a batch file feed from CUBoulder with an agreed upon format and schedule.
- [AUTHZ-5B] The application can manage groups and roles by providing a provisioning API that CUBoulder can call programmatically.
- [AUTHZ-5C] The application can manage groups, roles, or permissions by consuming SAML attributes at user logon time (may apply if SAML [AUTHN-1A] chosen above).
* Denotes desired functionality.
** Denotes required minimum functionality.