Access and Identity Management

(1)

Business Requirements Specification

Access and Identity

Management

Version 1.2

January 17, 2013

Revision History

Date Version Description

9/26/12 1.0 Creation of document 10/19/12 1.1 Minor edits to document

01/17/13 1.2 Added Phase 1/Phase 2 designation to each requirement. Also, added section 4.2 – Requirements for External POC data maintenance by ISO administrative staff

(2)

Disclaimer

All information contained in this draft Business Requirements Specification (BRS) as provided by the California Independent System Operator Corporation (ISO) is prepared for discussion and information purposes only. The draft BRS is provided “as is” without representation or warranty of any kind, including, without limitation, a representation or warranty as to accuracy, completeness or appropriateness for any particular purpose. The draft BRS shall be revised as the development and review of the business requirements progresses. The ISO assumes no responsibility for the consequences of any errors or omissions. The ISO may revise or withdraw all or part of this information at any time at its discretion without notice.

(4)

1. Introduction

1.1 Purpose

The purpose of this document is to capture and record a description of what the Users and Business Stakeholders of the project wish to obtain by providing high-level business requirements. This document establishes the basis for the bilateral agreement between the initiators and implementers of the project. The information in this document serves as input to determining the scope of Information Systems projects and to all Business Process Modeling and System Requirements Specifications efforts.

These requirements are intended for submission to the Information Technology Services (ITS) department and will serve as the initial set of business unit requirements for the appropriate software application/systems development effort. It is understood that ITS will perform additional requirements and systems analysis and may produce “To Be” Business Process Models, System Requirements Specifications and Use Cases to serve as the set of requirements documents used by the ITS development teams to buy, modify or build the necessary software and hardware systems. The Business Unit(s) involved in the project will have an opportunity to review and approve all ITS requirements documentation produced.

(5)

2. Details of Business Need/Problem

2.1 Description

The ISO maintains approximately six thousand certificates granting internal and external customers access to roughly 50 ISO applications and systems. Each customer has designated one or more individuals within their organization to act as the Point of Contact (POC), authorized for initiating and maintaining access to ISO applications and systems.

Currently, a POC maintenance process has been implemented in CIDI that facilitates the process of establishing, updating and terminating POCs as well as providing visibility (transparency), ease of use and self-service where appropriate to POCs to manage this process. In addition, an interim Application Access Request Form (AARF) Improvement Process that consolidates the submission of documents utilizing CIDI to create an AARC (Application Access Request Case) with a centralized approval and provisioning process was put in place. This process provides some degree of transparency and notification to the POC as the case is processed.

The AIM project will finalize the process and technology improvements by:

1. Providing self-service automated access request functionality to the users via a common UI and notifications;

2. Defining and implementing an approval process for new access requests that complies with audit and security requirements;

3. Automating access provisioning requests;

4. Integration with Centralized Security Data Service (CSDS); 5. Providing internal training and external training documentation;

6. Providing external training of market participants that will use the automated entry point; 7. Providing updates to the BPM’s and internal processes as identified in the impact assessment; 8. Providing interfaces/integration across ISO systems to support the above requirements; and 9. Implementing the above in production and non-production systems.

(6)

3. Business Process Impacts

3.1 High Level Business Process

3.1.1 Description

This project will expand on the existing IT access management and certificate based access business process. This is categorized under Support Business Services business process.

The following enhancements will be made to the existing business process to:

1. Interface with the recently implemented POC maintenance process that utilizes CIDI; 2. Enhance the existing IT access provisioning/management business processes; and

3. Expand the scope of the IT access provisioning/management business process to leverage data already existing in other ISO systems, interfacing with those systems to eliminate manual processes, improve efficiencies and increase transparency through proactive processes.

3.1.2 Pros

1. Provide state of the industry customer transparency to requesters of system access; 2. Eliminate potential human error; and

3. Reduce the manual intervention through automation.

3.1.3 Cons

(7)

4. Business Requirements

The sections below describe the Business Processes and the associated Business Requirements involved in the project. These may represent high level functional, non-functional, reporting and/or infrastructure

requirements. These business requirements directly relate to the high level scope items determined for the project.

Note: Requirements regarding maintenance of external POC data by ISO administrative staff and the functionality that currently resides in the CIDI application have been included in the scope of the AIM project in section 4.2. Also, each requirement that is in scope has been categorized into phase 1 or phase 2 where phase 1 at a high level covers read-only features of the AIM application as well as the external POC maintenance features while phase 2 covers read-write (create, update, delete) features of the AIM application.

4.1 Business Process: Identity & Access Request Management and

Provisioning

Identity & Access request management and provisioning deals with the process of organizations/entities requesting access to ISO applications or devices (in some cases it is the ISO that requires access to external devices) via Points of Contact (POCs).It also deals with internal ISO users requesting access to applications. Essentially, this will replace the manual AARF form submission and access activation/deactivation process.

The goal of the AIM process is to facilitate, across the ISO, a standardized approach to the process of establishing, updating and terminating access as well as providing visibility (transparency), ease of use and self-service where appropriate to POCs, internal ISO users, business units and IT to manage this process from end to end. Five distinct objectives of the “to be” AIM business process are:

1. Submission of AIM requests via GUI;

2. Viewing of user permissions or AIM requests via GUI; 3. Access/Identity expiration alert; and

4. Creating reports/views.

(8)

P O C / In te rn a l IS O u s e rs create AIM request submit AIM request success incomplete request create AIM request elements route AIM request elements review AIM request close AIM request element update AIM request status close request update AIM request status update AIM request status send out notification of AIM request completion receive certificate install certificate perform provisioning/ de-provisioning action

Identity/Access Request Management “To Be” Process

(1) Objectives (Internal/External): (1) Submit AIM requests via GUI

(2) View AIM requests/user permissions via GUI (3) Access/identity expiration alert (4) Create reports/views send certificate to requester RIG/ DPG disapprove send out notification of AIM request disapproval per application/ certificate BU approval required else create certificate new certificate required else close AIM request element approve create/ update user account close AIM request element update user account B u s in e s s U n it Legend Basic flow Alternative flow Exception flow send out notification of access request submission update AIM request status pre-validate AIM request update AIM request status incomplete else complete request failure In fo rm a ti o n T e c h n o lo g y else

(9)

P O C / In te rn a l IS O u s e rs IT /C u s to m e r S e rv ic e check for identity/ access soon to expire generate alerts to POCs

& ISO staff none found else (3) view user permissions/ AIM requests display AIM requests display authorized users AIM request user permissions (2) (4) generate report/view display report/view print report save report/view display print save regular basis Legend Basic flow Alternative flow Exception flow For external users only

The major stakeholders involved in the identity and access request management and provisioning business process are:

1. POC – Person designated to request identity and access authorization on behalf of a group of people

belonging to an organization that has a relationship with the ISO.

2. External user – Person associated with an organization/entity requiring access to applications or

devices.

3. Internal ISO user – An ISO employee requiring access to applications.

4. ISO Customer Services – Application and Business units (process) within the ISO responsible for

facilitating access and identity management.

5. Other ISO Business Units - Business units within the ISO that own different applications/devices and

are responsible for approving AIM requests.

6. ISO Information Technology – Primarily, IT Corporate Services is responsible for pre-validating AIM

requests, managing certificates as well as managing access.

(10)

ID# Business Feature

Require ment Type Potential Applicati on(s) Impacted Phase 1/Phase 2

AIM-BRQ001 POCs and all internal ISO users must be able to submit or cancel requests via GUI.

In order to update a request, the original request must be canceled and a new one submitted in its place.

A request can only be canceled before it has been approved or in cases where there is no approval required, before it has been provisioned.

Core Phase 2

AIM-BRQ003 The creation of requests shall include validation such as: 1. ensuring requests can only be submitted by eligible users

(POCs & internal users) and for the eligible applications; and

2. ensuring that requests for access are not duplicated

Core Phase 2

AIM-BRQ004 Complete and structurally correct requests that have been successfully validated can be submitted for processing by a POC or an internal ISO user.

Core Phase 2

AIM-BRQ050 AIM process must integrate with internal systems for validation where applicable

Core Phase 2

AIM-BRQ005 An AIM request may be used to initiate a single action associated with multiple users to:

1. provision/deprovision application access; 2. provision/deprovision device access; or 3. manage user accounts.

Failure for a single user will not hold up or cancel processing of an entire request.

Possible actions at a high level include: 1. new request to create user accounts

2. new request for access to an application or device 3. modification of existing access:

a. add more levels of access to an application b. remove some levels of access to an application c. add an application or device

d. remove an application or device 4. termination of access

5. renewal of access

6. modification of user accounts a. name change

b. contact detail changes

7. removal of user accounts that have no access rights

(11)

ID# Business Feature Require ment Type Potential Applicati on(s) Impacted Phase 1/Phase 2

AIM-BRQ006 An AIM request for application or device access must include the applicable application and resource information currently in the following manual forms:

1. User application access request form;

2. Device certificate request form;

3. Integration application access request form;

4. SFTP application access request form;

5. PIRP access form;

6. ADS ACL form;

7. SLIC – sub BA ID (requested via special notes/instructions in the user/integration application access request forms); or

8. Revoke application access request form.

For AIM requests for ADS and PIRP, these requests will not be accepted unless it is indicated (for each SCID requested) if full access is needed or what specific resources are needed if access is restricted.

Core Phase 2

AIM-BRQ007 The AIM process must be able to uniquely identify users and organizations regardless of name changes that may occur.

Core Phase 1

AIM-BRQ008 ISO’s AIM process must automatically issue receipt

notifications upon receipt of an AIM request with a unique id for the request.

Recipients of notifications must be configurable.

Core Phase 2

AIM-BRQ009 Each successfully submitted AIM request will generate 1 or more elements required to fulfill the request. These elements include but are not limited to:

1. User account creation, modification or removal/disabling; 2. Approval by business unit;

3. Certificate generation, renewal or revocation; and 4. Application access creation, update, renewal or

revocation.

Each element must be assigned to a responsible party with an expected target completion date.

Core Phase 2

AIM-BRQ010 Each element associated with an AIM request must be routed to the appropriate party(ies) for completion.

Core Phase 2

AIM-BRQ011 The workflow for routing elements of an AIM request to appropriate party(ies) must be configurable.

It must be able to handle non-CMA certificate provisioning actions that require business unit involvement

(12)

AIM-BRQ012 AIM requests for application access submitted by internal ISO users must be routed for approval to the appropriate business units depending on the applications for which access is requested.

AIM requests for application access submitted by POCs may be auto-approved or routed to business units for approval depending on the applications for which access is requested.

Business units may approve or disapprove a request or request more information from the submitter of the request.

Core Phase 2

AIM-BRQ013 During the approval process, an approver may modify an AIM request to incorporate additional information required to fulfill the request; e.g., the addition of information about LDAP groups associated with ADS exceptions or the modification of roles with respects to SIBR.

Core Phase 2

AIM-BRQ014 A user must be associated with only one organization, as his/her identity belongs to one organization.

A user or identity is considered to be a person at an organization. It is conceivable for a person to have multiple identities/user accounts with the ISO.

Core Phase 1

AIM-BRQ015 A request for termination of a user can only occur via the POC of the organization the user belongs to and it must result in the termination of all identity and access rights to ISO

applications/devices.

Core Phase 2

AIM-BRQ016 A request for revocation of access rights associated with a user can occur via:

1. The POC of the organization the user belongs to; or 2. The POC of another organization that has granted some

access rights to the user; i.e., the owner of the access control group.

Core Phase 2

AIM-BRQ017 The relationship of the organization represented by a POC with the ISO will determine the list of applications available for AIM requests.

Core Phase 2

AIM-BRQ018 POCs and internal ISO users shall be able to attach files to their AIM requests.

This is a specific requirement for RIG/DPG for a certificate signing request (CSR) to accompany an AIM request for device access. Also, to permit the attachment of an applicable NDA form.

Core Phase 2

AIM-BRQ020 POCs and internal ISO users must be able to copy an existing user to 1 or more new users as well as carry out a bulk modification of existing users.

(13)

ID# Business Feature Require ment Type Potential Applicati on(s) Impacted Phase 1/Phase 2

AIM-BRQ021 POCs must be able to submit certificate renewals without requiring re-approval.

Core Phase 2

AIM-BRQ022 POCs must be able to request access for a user at an

organization besides the organization they belong to, provided the appropriate cross organizational relationships are in place.

Core Phase 2

AIM-BRQ023 Each user or AIM request shall be associated with one or more of the different types of relationships that currently exist between the ISO and external entities or a new type of relationship that could be added in the future.

A relationship with the ISO is currently identified as one of the following:

1. A contract agreement with a registered scheduling coordinator with 1 or more corresponding SC ID;

2. A project established in RIMS with a corresponding project ID;

3. A generator owner identified for a RIG/DPG identified by a resource ID;

4. Agency requiring information from the ISO identified by an agency name;

5. ISO employee; or 6. ISO contractor.

Core Phase 2

AIM-BRQ024 Each AIM request must have a lifecycle which will be made up of states such as created, submitted, closed, approved, rejected, etc., which will be updated.

Core Phase 2

AIM-BRQ025 Each element within an AIM request must have it’s own lifecycle distinct from the request, such as new, completed, error.

Elements within a request may have different statuses.

Core Phase 2

AIM-BRQ026 Notifications must be sent and status updates visible

(transparency) to POCs, external end users & ISO staff during the different stages (refer to AIM-BRQ023) of the lifecycle of a request and it’s associated elements.

Core Phase 2

AIM-BRQ027 Each user account must have a lifecycle that will be made up of states such as active, terminated, invalid, etc.

Core Phase 1

AIM-BRQ028 Alerts must be generated when an element associated with a request is not completed within the agreed upon SLA.

Recipients of alerts shall be configurable and shall receive the alert notification on a regular basis until the element is

completed. The proximity of alerts to expected completion date shall be configurable and the frequency of alerts once triggered shall be configurable.

Also, the SLA shall be configurable.

(14)

AIM-BRQ031 Currently existing user account information must be migrated into the AIM process

Core Phase 1

AIM-BRQ032 The AIM process shall adhere to the existing ISO policy with regards to disabling/deleting users and the ability to re-activate/recreate them when required (such as internal users are disabled and then re-activated while external users are deleted and then recreated).

Core Phase 2

AIM-BRQ033 A history of user accounts, AIM requests and associated request elements shall be maintained and viewable by the AIM process.

Core Phase 2

AIM-BRQ049 The AIM process shall track what POCs are authorized to do; i.e., the organization a POC belongs to and the applications a POC is authorized to make requests for.

Core Phase 2

AIM-BRQ052 An organization may have 1 or more different relationships with the ISO

Core RIMS, RIG/DPG Access Database, MF, etc Phase 1

AIM-BRQ053 2 or more affiliated organizations may have the same POC. Core RIMS, RIG/DPG Access Database, MF, etc

Phase 2

4.1.2 Business Requirements – View User Permissions and AIM requests

Require ment Type Potential Applicati on(s) Impacted Phase 1/Phas e 2

AIM-BRQ034 POCs and internal ISO users shall be able to view AIM requests and user permissions.

POCs shall be able to view requests and user accounts identified by the authorized relationship(s) with the ISO.

Internal users shall be able to view requests and user accounts that pertain to them.

ISO business units and IT staff involved in the AIM process shall be able to view all requests and user accounts as well as the details of elements associated with each request such as status, assigned to, date assigned, etc.

Core Phase1/ Phase 2

(15)

ID# Business Feature Require ment Type Potential Applicati on(s) Impacted Phase 1/Phas e 2

AIM-BRQ035 Display of AIM requests must include:

1. ISO relationship ids (e.g. SCIDs, resource IDs, project ID, agency name);

2. Applications;

3. User role (job function); 4. Certificate expiration; 5. Organization; 6. Access role; 7. Environments; and 8. Effective date. Core Phase 2

AIM-BRQ036 The display of user accounts to POCs, internal users and ISO staff involved with the AIM process must at a minimum comprise of:

1. User’s name; 2. Contact details; 3. Status;

4. Certificates; and

5. Application access rights.

Core Phase 1

4.1.3 Business Requirements – Access/Identity Expiration Alerts

Require ment Type Potential Applicati on(s) Impacted Phase 1/ Phase 2

AIM-BRQ040 The AIM process must be able to generate alerts when certificates for external users are close to expiration.

POCs and ISO staff shall receive the alert notification on a regular basis until a renewal request is submitted.

Core Phase 2

AIM-BRQ041 Proximity of alerts to the expiration dates of certificates shall be configurable. Also, the frequency of alerts once triggered and the receipients of the alerts shall be configurable.

Core Phase 2

4.1.4 Business Requirements – Create Reports/Views

Require ment Type Potential Applicati on(s) Impacted Phase 1/ Phase 2

(16)

AIM-BRQ042 Authorized ISO customer services & IT staff must be able to create reports by applying different combinations of filters and sorting to POC, POC request, POC request elements, user account details, AIM request and AIM request elements.

Filtering capability for user account details shall include: 1. expiration date;

2. user/device; 3. application; 4. profile; and 5. access role.

Filtering capability for AIM requests shall include: 1. user/device; and

2. request status.

Core Phase 1/ Phase 2

AIM-BRQ043 Authorized ISO customer services & IT staff must be able to view generated reports.

Core Phase 1/ Phase 2 AIM-BRQ044 Authorized ISO customer services & IT staff must be able to

print or save reports generated.

4.1.5 Business Requirements – Training

AIM-BRQ054 The ISO shall provide training for POCs for AIM. Core Phase 1/ Phase 2 AIM-BRQ055 The ISO shall provide training documentation for AIM. Core Phase 1/

Phase 2 AIM-BRQ056 The ISO shall create Computer Based Training for AIM and

add it to the curriculum.

4.2 Business Process: External POC Maintenance

Maintenance of external POC data by ISO administrative staff applies to organizations/entities that require access to ISO applications. These organizations/entities designate one or more Points of Contacts (POCs) to manage the process of requesting user access to ISO applications. The goal of the AIM project with regards to the POC maintenance process is to replace the POC maintenance functionality currently in the CIDI application; i.e., maintenance of certain data elements associated with a POC such as contact information, organization, area of responsibility. This does not include establishing, updating or terminating POCs.

(17)

4.2.1 Business Requirements – Maintain External POC Data

Require ment Type Potential Applicati on(s) Impacte d

Phase 1/

Phase 2

EPOC-BRQ001 Data about external POCs shall be maintained by the ISO’s POC maintenance process with the ability for ISO admin staff to view and modify the data.

Core Phase 1

EPOC-BRQ002 Each external POC shall be associated with one or more of the different types of relationships that currently exist between the ISO and external entities or a new type of relationship that could be added in the future.

A relationship between the ISO and an external entity is currently identified as one of the following:

1. A contract agreement with a registered scheduling coordinator with a corresponding SC ID;

2. A project established in RIMS with a corresponding project ID;

3. A generator owner identified for a RIG/DPG identified by a resource ID; or

4. Agency requiring information from the ISO identified by an agency name. Core RIMS, RIG/DPG Access Databas e, MF, etc Phase 1

EPOC-BRQ003 Each external POC shall have capabilities associated with it, which will include:

1. Primary or Secondary role;

2. Type of relationship with the ISO (determined by the organization represented); and

3. Area of responsibility (for each type of relationship that exists with the ISO, there could be a further sub category within the relationship identified by an area of responsibility).

Core Phase 1

EPOC-BRQ004 A history of external POCs, and associated elements shall be maintained by the POC maintenance process.

Core Phase 1

EPOC-BRQ005 External POCs shall be able to view data about themselves as well as other external POCs identified by the authorized relationship with the ISO.

ISO admin staff shall be able to view all external POCs.

Core Phase 1

EPOC-BRQ006 The display of external POC data must at a minimum comprise of:

1. POC’s name;

2. Contact details (email address, phone number, physical address);

3. Status;

4. Capabilities (Primary/Secondary POC, Type of relationship, Area of Responsibility – by SC IDs, by Applications); and

5. POC effective dates (start, end and inactive dates).

(18)

(19)

Access and Identity Management

Business Requirements Specification