RFP Guidance

Last Updated: 11/21/2017

Purpose

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.

Overview

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. *

Authentication Requirement

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.