Document Status
May 18, 2012 - Draft available for review and comment. Additional explanation of each sub-requirement and guidance on selecting among alternatives will be provided in a future draft.
This document provides example requirements for Identity and Access Management (IAM) integration that should be considered when planning the purchase of an application or developing materials involved in a competitive solicitation such as a Request for Proposal (RFP), Request for Quotation (RFQ), Statement of Work (SOW), etc.
Not all the requirements in this document will apply to integrating any given application and there may be additional requirements not included here. For example, while some requirements apply only to web applications, most are relevant to a range of application architectures. Planning teams need to carefully consider their business requirements relative to the different integration options that are available and then select the requirements that are most appropriate.
Each requirement has been given a unique name for easy reference. Names that differ only by a letter designation (e.g. AUTH-1A, AUTH-1B) denote a set of alternatives to select from. In most cases you would select only one requirement from the set.
IAM requirements are organized into four categories: Account Provisioning & De-provisioning, Authentication, Authorization & Role Management, and Session Management. For each category a general description of goals is provided, followed by a list of specific requirements that will help ensure goals will be met.
Account provisioning and de-provisioning are the processes that create an account in an application, maintain the accuracy of account information over time, and delete the account when it is no longer needed in the application. Account information typically includes a unique user identifier such as UW NetID (but not the user's password) as well as user profile attributes such as name and email address.
The primary goal of “Account Provisioning & De-provisioning” integration is to leverage UW institutional information and processes to automate account management in the application, rather than having to recreate this information from scratch and manage it independently in an additional location. The specific data elements that are required to automate this process vary from application to application.
| Sub-requirements | |
|---|---|
PROV-1A | The application will create, update, and delete user accounts and profiles in the application by accepting a batch file feed from the UW with an agreed upon design (format, schedule, etc.). |
| PROV-1B | The application will create, update, and delete user accounts and profiles in the application by consuming UW data integration services programmatically (pull model). |
| PROV-1C | The application will create, update, and delete user accounts and profiles in the application by providing a provisioning API the UW can use programmatically (push model). |
| PROV-1D | The application will create and update user accounts and profiles in the application by consuming SAML attributes at user logon time. Note that this mechanism can't provide for automated de-provisioning. (May apply if AUTHN-1A is selected.) |
| PROV-2 | The application will support user ID length and formats compatible with the account identifier provided by the UW (e.g. UW NetID, EPPN) |
Authentication is a process by which users, processes, or services provide proof of their identity. User authentication often relies on a username and password but may also require a second authentication factor (e.g. a PIN from an Entrust hardware token) where greater assurance of identity is required. Processes and services may authenticate each other with other kinds of credentials.
The primary goal of “Authentication” integration is to ensure that applications use existing UW authentication systems and protocols. In particular, applications should utilize UW NetID authentication so that UW users don’t need to obtain an additional user ID and password local to the application.
| Sub-requirements | |
|---|---|
| AUTHN-1A | UW NetID authentication will be verified using SAML 2 protocol and the UW’s Identity Provider. |
| AUTHN-1B | UW NetID authentication will be verified using Windows Authentication and the UWWI Active Directory. |
| AUTHN-2 | The application will use InCommon as the source for the UW Identity Provider’s SAML metadata. (May apply if AUTHN-1A is selected.) |
| AUTHN-3 | The application will support single sign-on (SSO) with other UW applications that use SAML 2 (May apply if AUTHN-1A is selected.) |
| AUTHN-4 | The application can require 2-factor token authentication on a per user, group, or role basis. (May apply if AUTHN-1A is selected.) |
| AUTHN-5A | The application provides a mechanism for an authorized user to impersonate another user in the application without needing their password. |
| AUTHN-5B | Application APIs provide a mechanism for an API client to impersonate a user in the application without needing their password. |
| AUTHN-6A | The application will authenticate to UW services for data integration using an X.509 certificate from the UW Certificate Authority. (May apply if PROV-1B, AUTHZ-5B, or AUTHZ-5E are selected.) |
| AUTHN-6B | The application will authenticate to UW services for data integration using an Application UW NetID. (May apply if PROV-1B, AUTHZ-5B, or AUTHZ-5E is selected.) |
Authorization & Role Management are access management processes that ultimately control what a user or process is allowed to do in an application. These processes may include organizing users into groups, assigning users or groups to roles, and managing the permissions for each role on application resources.
The primary goal of “Authorization & Role Management” integration is to use UW systems and institutional information to control access within the application. For example, this could mean externalizing authorization from the application by querying ASTRA for user authorizations or by checking the UW Groups service for group memberships. Several options are available. Another goal is ensuring that the application’s role and permission model has the flexibility to handle current and anticipated business needs.
| Sub-requirements | |
| AUTHZ-1 | The application has an access control model that can be extended to accommodate UW custom roles. |
| AUTHZ-2 | The application can map groups or individuals into roles. |
| AUTHZ-3 | The application allows the UW 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 the UW with an agreed upon format and schedule. |
| AUTHZ-5B | The application can manage groups and roles by consuming UW data integration services programmatically (pull model). |
| AUTHZ-5C | The application can manage groups and roles by providing a provisioning API the UW can call programmatically (push model). |
| AUTHZ-5D | The application can manage groups, roles, or permissions by consuming SAML attributes at user logon time. (May apply if AUTHN-1A is selected.) |
| AUTHZ-5E | The application can query a UW authorization service (e.g ASTRA, UW Groups Service) to determine if a user is permitted to perform a given operation. |
| AUTHZ-6A | After a user authenticates but before they can access application resources, the application can call an external UW service that knows whether a user has a current Institutional Data Access Agreement and if not redirect the user to an appropriate URL. |
| AUTHZ-6B | Before granting access to application resources, the application can check a SAML attribute to determine if the authenticated user has a current Institutional Data Access Agreement and if not redirect the user to an appropriate URL. (May apply if AUTHN-1A is selected.) |
Session Management provides capabilities to control properties of a user's session such as session length, forced reauthentication, and logout.
The primary goal of “Session Management” requirements is to ensure that data security controls on user application sessions can be configured to meet current and anticipated business needs.
| Sub-requirements | |
|---|---|
| SM-1 | The application has a configurable user session inactivity timeout. |
| SM-2 | The application has a configurable user session maximum lifetime. |
| SM-3 | The application can trigger authentication for an existing anonymous session when a user requests protected application content. |
| SM-4 | The application supports session context step-up from password authentication to 2-factor token authentication when more sensitive data or functions are requested by a user. (May apply if AUTHN-1A is selected.) |
| SM-5 | The application can force re-authentication of a user that was previously authenticated in the UW single sign-on (SSO) environment. (May apply if AUTHN-3 is selected.) |
| SM-6 | The application supports user-initiated logout. |
To learn more about procurement processes at the UW, refer to Procurement Services.