Access and Identity Management Requirements Specification Access and Identity Management Version 1.2...

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

In

Owner:PMO Program Office

Copyright 2012 California ISO. Page 2 of 19

TechnologyTechnology

Review Date:

Policy No.:

Requirements for Access and Identity Management

Business Requirements Specification - Planning

Version No.: 1.2

Effective Date 01/17/2013

Table of Contents

1. INTRODUCTION .................................................................................................................................................... 4

1.1 PURPOSE ......................................................................................................................................................... 4 1.2 REFERENCES .......................................................................................... ERROR! BOOKMARK NOT DEFINED.

2. DETAILS OF BUSINESS NEED/PROBLEM ..................................................................................................... 5

2.1 DESCRIPTION .................................................................................................................................................. 5

3. BUSINESS PROCESS IMPACTS ....................................................................................................................... 6

3.1 HIGH LEVEL BUSINESS PROCESS .................................................................................................................. 6 3.1.1 Description ................................................................................................................................................. 6 3.1.2 Pros............................................................................................................................................................. 6 3.1.3 Cons ............................................................................................................................................................ 6

4. BUSINESS REQUIREMENTS ............................................................................................................................. 7

4.1 BUSINESS PROCESS: IDENTITY & ACCESS REQUEST MANAGEMENT AND PROVISIONING ........................... 7 4.1.1 Business Requirements – Submit AIM Requests ................................................................................ 9 4.1.2 Business Requirements – View User Permissions and AIM requests ........................................... 14 4.1.3 Business Requirements – Access/Identity Expiration Alerts ........................................................... 15 4.1.4 Business Requirements – Create Reports/Views ............................................................................. 15 4.1.5 Business Requirements – Training ...................................................................................................... 16

In




Review Date:

Policy No.:



Version No.: 1.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.

In




Review Date:

Policy No.:



Version No.: 1.2


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.

In




Review Date:

Policy No.:



Version No.: 1.2


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.

In




Review Date:

Policy No.:



Version No.: 1.2


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

1. N/A

In




Review Date:

Policy No.:



Version No.: 1.2


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.

The process steps associated with each category are shown in the diagrams below:

In




Review Date:

Policy No.:



Version No.: 1.2

Effective Date 01/17/2013 P

OC

/ In

tern

al IS

O u

se

rs

create

AIM

request

submit

AIM

request

success

incompleterequest

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/

certificateBUapprovalrequired

else

create

certificate

new certificaterequired

else

close

AIM

request

element approve

create/

update

user

account

close

AIM

request

element

update

user

account

Bu

sin

es

s U

nit

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

completerequest

failure

Info

rma

tio

n T

ec

hn

olo

gy

else

In




Review Date:

Policy No.:



Version No.: 1.2

Effective Date 01/17/2013 P

OC

/ In

tern

al IS

O u

se

rsIT

/Cu

sto

me

r S

erv

ice

check for

identity/

access

soon to

expire

generate

alerts to POCs

& ISO staff

nonefound

else(3)

view user

permissions/

AIM requests

display

AIM

requests

display

authorized

users

AIMrequest

userpermissions

(2)

(4)

generate

report/view

display

report/view

print

report

save

report/view

display

print

save

regularbasis

Legend

Basic flow

Alternative flow

Exception flow

For externalusers 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.

4.1.1 Business Requirements – Submit AIM Requests

In




Review Date:

Policy No.:



Version No.: 1.2


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

Core Phase 2

In




Review Date:

Policy No.:



Version No.: 1.2



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

Core Phase 2

http://www.caiso.com/docs/2000/03/01/2000030110195926538.xls

http://www.caiso.com/2039/2039c6bd5f250.xls

http://www.caiso.com/2083/2083e6d435390.xls

http://www.caiso.com/2365/236583a1a490.xls

http://www.caiso.com/Documents/ParticipatingIntermittentResourceProgramAccessForm_completealongwithUserApplicationAccessRequestForm_.xls

http://www.caiso.com/Documents/ACLInformationForm_UpdatedApr13_2011_.xls

http://www.caiso.com/Documents/RevokeApplicationAccessRequestForm.xls

In




Review Date:

Policy No.:



Version No.: 1.2



Require

ment

Type

Potential

Applicati

on(s)

Impacted

Phase

1/Phase

2

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.

Core Phase 2

In




Review Date:

Policy No.:



Version No.: 1.2



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.

Core Phase 2

In




Review Date:

Policy No.:



Version No.: 1.2



Require

ment

Type

Potential

Applicati

on(s)

Impacted

Phase

1/Phase

2

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

In




Review Date:

Policy No.:



Version No.: 1.2



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

In




Review Date:

Policy No.:



Version No.: 1.2



Require

ment

Type

Potential

Applicati

on(s)

Impacted

Phase 1/

Phase 2

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.


AIM-BRQ044 Authorized ISO customer services & IT staff must be able to print or save reports generated.


4.1.5 Business Requirements – Training


Require

ment

Type

Potential

Applicati

on(s)

Impacted

Phase 1/

Phase 2

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.

In




Review Date:

Policy No.:



Version No.: 1.2


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 Database, 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).

Core Phase 1

In




Review Date:

Policy No.:



Version No.: 1.2


In




Review Date:

Policy No.:



Version No.: 1.2


Date post:	31-Mar-2018
Category:	Documents
Upload:	phungdien
View:	220 times
Download:	3 times