Company ABC

an

IT Se

Access Management Vision Document

Version 0.0
This document has been reviewed by:

nb

er

Stakeholder

rv
Date Approved

c.

20

07

R an

dy

A.

St

ei

ic e

Zo ne

.c

om

access Management

Version: 0.0 Date: 07/10/07

Revision History
Date Version Description Author

c.

20

07

Confidential

R an

dy

A.

St

ei

nb

er

an

IT Se

rv
Page 2

ic e

Zo ne

.c

om

access Management

Version: 0.0 Date: 07/10/07

Table of Contents
1. Introduction 1.1 Document Purpose 1.2 Document Scope 1.3 Overview Positioning 2.1 Business Opportunity 2.2 Business Objective 2.3 Problem Statement Vision, Assumptions and Scope 3.1 Vision 3.2 Assumptions 3.3 In scope 3.4 Out of Scope 3.5 Open Issues Alternatives and competition 4.1 Vendors 5 5 5 5 5 5 6 6

2.

5.

6.

20

07

Product Features 6.1 Password Management 6.2 Self Service 6.3 User Account Administration 6.4 Provisioning 6.5 Workflows 6.6 Audit Reporting and Audit Control 6.7 Defining and Enforcing policies

dy

A.

Product Overview 5.1 Context Diagram 5.2 System Functions 5.2.1 Authentication 5.2.2 Authorization 5.2.3 Role based access 5.2.4 User life-cycle management 5.2.5 Self Administration 5.2.6 Single Sign on 5.2.7 Provisioning access data to various systems 5.2.8 Auditing and Reporting 5.3 Summary of Capabilities

an

4.

IT Se

rv nb er g

3.

ic e

St

ei

7.

R an

Development Tools 7.1 Environmental Requirements Risks and Constraints 8.1 Constraints

c.

8.

Confidential

Zo ne
7 7 7 7 8 8 8 8 9 9 11 11 11 11 11 11 11 11 12 12 12 12 12 12 12 12 12 12 12 13 13 13 Page 3

.c

om

access Management

Version: 0.0 Date: 07/10/07

8.2 Risks 9. 10. 10.1 10.2 10.3 10.4 A. Quality Ranges Use Case Diagram Overall User Functions Use Case Diagram Administrative Functions Use Case diagram Audit and Reporting Functions Use case diagram

13 13

c.

20

07

Confidential

R an

dy

A.

St

ei

nb

er

an

IT Se

rv
Page 4

ic e

Appendices A.1 Definitions, Acronyms, and Abbreviations A.2 References

Zo ne
16 16 16

14 14 15 15 15

.c

om

access Management

Version: 0.0 Date: 07/10/07

1. Introduction
1.1 Document Purpose The purpose of this document is to describe the positioning, scope and features of the Enterprise access Management initiative. It focuses on defining the ABC need for access Management and providing details on how this initiative would help fulfill those needs. The content in this document reflects 1.2 Document Scope This document will focus on the features of access Management. It will supply project implementation teams with the background and objectives for developing access framework. It is not intended to describe the processes associated with future usage of the framework. . 1.3 Overview This document is intended for anybody who is interested in understanding the scope of the solution that will be provided by this project.

2. Positioning

20

07

R an

c.

Confidential

dy

access management policies should be implemented as part of the standards and procedures which are derived from the corporate security policy. Without centralized access management it is extremely difficult to enforce the corporate policy in a complex environment dealing with a variety of target platforms, different system specifications and administrators. The user typically has multiple accounts and passwords. The ability to synchronize passwords across platforms and applications provides ease of use for the user. It can also improve the security of the environment because each user does not have to remember multiple passwords and is therefore less likely to write them down. Password strength policy can also be applied consistently across the enterprise. Centralized password resets enable a user or administrator to reset one or all account passwords from a central interface. This prevents lost productivity due to the inability to access critical systems. As the number and type of users within the scope of an organizations access management system changes, there will be increasing burdens on the system. Any centralized system run buy an IT department could face the burden of having to manage users that are within other business units, or even within other partner organizations. A key feature of any centralized system therefore is the ability to delegate the day to day management of users to nominated leaders in other business units or partner Page 5

A.

St

ei

The centralization of the cross-environment management provides a common interface for administration of user access information, thus reducing education and maintenance costs.

nb

er

2.1 Business Opportunity Describe benefits of having a centralized access management from a security stand point, ease of user life-cycle management across multiple platforms.

an

This document begins with an overview of the business problem, project assumptions and project scope. A summary of product capabilities is followed by a description of major features.

IT Se

rv

ic e

Zo ne

.c

om

access Management

Version: 0.0 Date: 07/10/07

organizations. Managing access and account related data involves a great deal of approvals and dependencies. It takes a lot of time and effort in order to collect the necessary approvals and check for all sorts of dependencies between related components. To reduce these often manually conducted chores the access management system should have an automated workflow capability that allows the system to Gather approvals, Reduce administrative workload, Reduce turn-on time for new managed identities, Enforce completeness of information. 2.2 Business Objective

2.

3.

4. 5. 6. 7. 8.

We have security policies but a lack of awareness and no clearly defined way of enforcing them consistently across the enterprise. We are moving towards becoming a role based organization but there is no access management to reflect and support that. Orphan user ids, contractors??

c.

20

07

Confidential

R an

dy

A.

St

There is no Single Sign-on capability. No one clearly defined process for data synchronization.

ei

nb

er

Once a user in the system, they typically have multiple accounts and passwords to manage. This not only results in inefficiency but there is also associated cost as more frequent assistance is sought by each individual user to maintain their myriad of accounts and passwords.

an

A request for setting up a user account in the desired systems takes anywhere from 46 weeks. There is a need to reduce the cost and latency associated with this process. This process is even slower for the contractors. There is no system in ABC that stores contractor information.

IT Se

2.3 Problem Statement 1. ABC has a very complex environment with multiple access data stores scattered over various directory servers and databases namely, iPlanet, Active Directory, PRODUCT TOOL and with in applications databases that support authentication for individual applications.

rv

ic e

Zo ne
Page 6

.c

om

access Management

Version: 0.0 Date: 07/10/07

3. Vision, Assumptions and Scope

3.1 Vision To have an access Management solution that provides a product, which together with a set of standard processes around it, manage the complete life cycle of Security Profile of ABC systems users, from a single authoritative source. The vision is to achieve a single source of truth for all identities and across all systems. System Users: ABC employees across all businesses, all contractors, vendors and trading partners that need access to ABC systems ABC Systems: LDAP, AD, Lotes Notes, PRODUCT TOOL , OS/Platforms and Application databases Trusted Sources: HR database, CORE Database. Standardized processes: - Process that feeds into access Management - Process that ensures compliance with ABC security policies - Unified password policy across all systems - Standard process for password management and profile management - Standard process for administering the access management including managing security policies and access control

3.2 Assumptions 1. Active Directory and iPlanet will stay as they do in the current system and will continue to support the various Unix and MS desktop applications. 2. Commitment from the stakeholders is key to the success of this project.

1.

R an

07

20

c.

Confidential

dy

2.

3.

Phase II Support the EPF release in Qtr 1 of 2004. 1. During this phase, the access Management product will be implemented with partial scope. Page 7

A.

Phase I Current state analysis and Completion of FPOC Produce a current state document that details the current system in terms of access data flow and the dependency of various applications and systems on the iPlanet and Active directory servers. This document will also capture the cost associated with the operations

Deliver a full Proof-of-concept including selected product, Portal Framework, iPlanet and Active directory. Investigate the viability of provisioning to PRODUCT TOOL , Lotus notes and Unix accounts. The FPOC will include user administration, Single Sign on, workflows and automated provisioning. The project team will produce a post FPOC document manual and a decision to accept/reject product will be made based upon the FPOC results. This phase will produce a future state description document that will discuss the access management as it aligns with the vision.

St

3.3 In scope The scope for this project has been divided into three phases. This will allow the project team to focus on the immediate tasks without loosing sight of the long term vision as stated above. Each phase assumes a successful completion of the previous one and builds upon that.

ei

nb

er

an

IT Se

rv

ic e

Zo ne

.c

om

access Management

Version: 0.0 Date: 07/10/07

2.

Phase III This may involve a series of projects implementing the complete access Management Solution, piece by piece, until the envisioned future state is reached. The processes may continue to evolve and new policies set up as part of standard change management effort.

2. 3.

Integrating the various applications into access Management, that currently authenticate against iPlanet and/or Active Directory is not in scope. Implementing an enterprise wide SSO.

2. 3. 4. 5. 6.

What is ABC strategy about including Trading Partners under the access Management umbrella. Feed back from MPIP is sought on this issue. Role categories at a very high level in order to a Access the standardization of user set up process based upon their role/category.

4. Alternatives and competition

20

07

4.1 Vendors Netegrity was eliminated due to weakness in administration tool and batch processing. VENDOR XXX and Oblix were evaluated according to a rigorous scoring model.

c.

Confidential

R an

The access Management was in the scope of ABC Enterprise Portal Framework (EPF) project to meet the requirement for a secure portal, provide Single Sign-on ability and role based access. The EPF access Services team investigated several Industry-standard solutions, drawing from a list of vendors recommended by AMR. As part of a formal procurement process, RFPs were sent to Oblix, Netegrity, VENDOR XXX, Sun and Novell. After evaluating the RFP responses, three vendors were short listed: VENDOR XXX, Oblix and Netegrity. These three vendor finalists were invited to perform product demonstrations, based on a ABCprovided script.

dy

A.

St

IM track, Solar Upgrade and Associate Data Synchronization efforts.

ei

Is investigating the re-design of LDAP schema, in scope of this project. This was brought up by xxx and we need to discuss this today.

nb

Understanding the current security policies and how clearly defined they are. How will these translate to our project. This would be a question for xxx when we discuss Risk.

er

3.5 Open Issues 1. There is a huge endeavor of cleansing of data which will be a pre-requisite to implementing access management. This involves data resulting from name changes, generic Access assignments as well as missing ids.

an

IT Se

3.4 Out of Scope 1. Actual conversion of existing systems and applications to utilize the access management framework is not in scope.

rv

ic e

Zo ne
Page 8

As part of this initiative, we will visit the use of MMS and Psync and make a recommendation about it.

.c

om

The scope will include functionality of receiving the feed from HR and other trusted sources and for generating the account IDs. The access Management will ensure pushing the data to iPlanet, Active Directory and the BroadVision Database to completely support the launch of the second release of EPF.

access Management

Version: 0.0 Date: 07/10/07

VENDOR XXX was selected due to viability and strategic fit.

5. Product Overview
A complete security and access product would provide a solution for access control, user credentials, policy enforcement, business process automation, auditing, and ease of administration. It should also provide interconnectivity and support for existing sub-systems in the enterprise. The solution should be flexible as to adapt to the change needs of access management in the enterprise.

The ability to centralize auditing and logging of all additions, changes and deletions made on user repositories should be provided for to reduce tracing of events on disparate systems. The selected solution should reduce the need for several administrative interfaces for user management. It should also provide a level of self-service to reduce the administrative workload. Delegated administration should be provided The selected solution should allow for the administration of several user repositories that exist in the enterprise. This will reduce the need for specialist administrators for various sub-systems that exist in the enterprise. This will also allow for security policies to be uniformly applied across the organization.

5.1 Context Diagram

c.

20

07

Confidential

R an

dy

A.

St

ei

nb

er

an

The product should provide for business process automation by automating approvals and dependencies in the account creation process. It should reduce administrative workload, reduce turn-on time for new managed identities, and enforce completeness.

IT Se

Implementing access management policies that comply with the corporate security policy is a key factor for a successful access and Credential Management system. Providing central control makes it possible to accommodate the business and security policies, enabling security administrators to implement them in an efficient and enforceable way.

rv

ic e

The product should provide mechanisms for access control that address component protection, security management, component access, cryptographic support, identification and authentication of system users.

Zo ne
Page 9

.c

om

access Management

Version: 0.0 Date: 07/10/07

ic e

Authentication

Authorization

Role Based Access

Users

IT Se

rv
User Life-Cycle Management Provisioning Identity Data to Various Systems

Administrators

er

Self Administration Enterprise systems and resources

Auditing and Reporting

an

Single Sign On

c.

20

07

Confidential

R an

dy

A.

St

ei

nb

Zo ne
Page 10

Identity Management

Managed Assets

User accounts/Identities

.c
Data Directory Servers Applications Applications Databas es Databases

om

access Management

Version: 0.0 Date: 07/10/07

5.2.3 Role based access Role Based Access Control or RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in that role. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles to provide access to the appropriate systems. 5.2.4 User life-cycle management Lifecycle management is a term used to describe how entities (e.g. identities, accounts) - become available, are interacted with, managed and finally destroyed. The life cycle of a typical user includes the initial creation of the users account, provisioning accounts for the users use, maintenance or modification of the user and users rights, and finally the termination of the user accounts and access rights. 5.2.5 Self Administration Self administration refers to a users ability to perform or request administrative request for their accounts. Typical self-administration features include the ability to change a password, reset a password, update their personal and account information, and place requests for access to sub-systems. 5.2.6 Single Sign on Single Sign-On is a term used to refer to a system that allows a user to log into a system once and thereafter use applications without further Authentication. 5.2.7 Provisioning access data to various systems access provisioning is the act of creating, updating and deleting user account data in given targeted systems, in order to maintain the data used by other applications or resources, up to date with the central access data store.

c.

20

07

Confidential

R an

dy

A.

St

ei

nb

er

an

IT Se

5.2.2 Authorization Authorization is the process of granting or denying access to a resource based upon credentials. Most computer security systems are based on a two-step process. The first stage is authentication, which ensures that a user is who he or she claims to be. The second stage is authorization, which allows the user access to various resources based on the users access and access rights.

rv

ic e

Zo ne
Page 11

5.2.1 Authentication The process of identifying an individual usually based on a user name and password. In security systems, authentication is distinct from authorization, which is the process of giving individuals access to system objects based on their access. Authentication merely ensures that the individual is who he or she claims to be, but says nothing about the access rights of the individual.

.c

om

5.2 System Functions The access Management system functions are described below to give a high level understanding of the functionality.

access Management

Version: 0.0 Date: 07/10/07

5.3 Summary of Capabilities User Administration Account Provisioning Policy Enforcement Life Cycle Management and Workflow Delegated user administration Access Control, Authorization and Authentication Role based Access control (RBAC) User Self Service and Password management Single Sign on capabilities Auditing and Reporting capabilities

6.2 Self Service

6.5 Workflows

6.6 Audit Reporting and Audit Control 6.7 Defining and Enforcing policies

20

07

7. Development Tools
?.

c.

Confidential

R an

dy

A.

6.4 Provisioning

St

6.3 User Account Administration

ei

nb

er

6.1 Password Management

an

6. Product Features

IT Se

rv
Page 12

ic e

Zo ne

.c

5.2.8 Auditing and Reporting In order to comply with the security policies for any company, there are requirements from any access system to provide auditing and reporting capabilituy. This could include auditing some or all transactions at system level and generating reports based on audits and other mechanisms that would a Access in monitoring and maintaining the system and processes on an ongoing basis.

om

access Management

Version: 0.0 Date: 07/10/07

7.1 Environmental Requirements

8. Risks and Constraints

8.1 Constraints

1.

2. 3.

4.

6. 7.

20

07

8.2 Risks
Risk Lack of security awareness among users this is a potential risk as SSN will be replaced with a system generated Probability high Impact high Mitigation Strategy

c.

Confidential

R an

List any contractual constraints

dy

A.

5.

There are about 200 mainframe applications that require PRODUCT TOOL ids. There are currently anywhere between 75 to 78 thousand PRODUCT TOOL ids which translates to less a third of ABC employees. A lot of these are generic IDs which are used by the store associates. The understanding is that there is a 1:1 correlation between the generic Access and person using that id. ABC use the same PRODUCT TOOL database that is shared across many other companies. This poses a challenge in the processes of achieving uniqueness of IDs. Until two months ago when a new hire was established into ABC system, without the request for a PRODUCT TOOL id, a unique user friendly LDAP Access was created for the user. If a request for a PRODUCT TOOL Access came at a later time and the LDAP user Access already existed in the PRODUCT TOOL database, then the user was assigned a new unique PRODUCT TOOL Access which would also become their LDAP id. What this meant was that the LDAP Access had to be changed in order to provide a single user Access to the user. The current process, which has been in place for two months now, interfaces with a system called Master Users Database System (MUDS) that has visibility into all existing PRODUCT TOOL IDs with in and outside of ABC. What this does is, at the time of hire, it looks up the MUDS and reserves a unique ACCESS in the MUDS for the user, without actually creating the PRODUCT TOOL Access (if there is no request for one). It then checks LDAP for the uniqueness and then creates the LDAP id. The process of checking both MUDS and LDAP for uniqueness and generating a new Access continues till an Access is found that is unique in both. This is the ACCESS that is reserved in MUDs for this user. If at a later time a PRODUCT TOOL request is made for this user, the reserved Access is assigned. access management will have to replicate this process. Home Services PRODUCT TOOL processes are outsourced to VENDOR XXX. They are approximately 15000 in number and are mostly generic IDs. These also use MUDS for the Access lookup. There is no single source of contractor information and the requests for their PRODUCT TOOL ids come from individual businesses.

St

ei

nb

er

an

IT Se

rv

ic e

Project team met with the representatives from Risk Management to discuss the risk areas. The current PRODUCT TOOL process was discussed at length. Some key facts and constraints associated with that are documented here:

Zo ne
Page 13

.c

om

access Management

Version: 0.0 Date: 07/10/07

Current password reset does not use SSL and the data is sent as cleartext For access Management to replicate the current process that reserves a PRODUCT TOOL Access for a new user, a programmatic lookup into MUDS will be required. MUDS is owned by VENDOR XXX and contract does not allow any visibility into that. There is an indication that ABC as an organization will not move towards a role based structure any time in the near future. Since the role based access control (RBAC) is an integral part of successful access management solution and is closely tied to the organizational structure, this may result in a less than optimal solution for ABC.

low

high

The selected product should send data over SSL during self administration

high

high

9. Quality Ranges

10. Use Case Diagram

10.1 Overall

c.

20

07

Confidential

R an

dy

A.

St

ei

nb

er

an

IT Se

rv
Page 14

ic e

Zo ne

ACCESS for employees ACCESS in the HR system. The generated ACCESS can potentially be exposed more if the user does not treat it with same level of protection as the SSN.

.c

om

access Management

Version: 0.0 Date: 07/10/07

(from Use Case Vi ew)

Uses

Manage Password

User Self Administration

(from Use Case Vi ew)

ei

nb

er

A.

Administrator

St

R an

dy

c.

20

07

10.4 Audit and Reporting Functions Use case diagram

Auditor

Confidential

10.3 Administrative Functions Use Case diagram

an

Define Policies

Manage Access levels

Manage Identities

Run Audit Reports

IT Se

User

Uses

rv

ic e

User Sign on

(from Use Case Vi ew)

Manage Profile

(from Use Case Vi ew)

Zo ne
Page 15

10.2 User Functions Use Case Diagram

.c

om

access Management

Version: 0.0 Date: 07/10/07

A. Appendices
A.1 A.2 Definitions, Acronyms, and Abbreviations References Id 1. 2. 3. Reference Document

IT Se

rv
Date Owner or Source xxx
xxx

Enterprise access Management Kick off presentation deck

Mm/dd/yy Mm/dd/yy

c.

20

07

Confidential

R an

dy

A.

St

ei

nb

er

an

Integrity.intra.ABC.com

EI_331_PORTAL_FRAMEWORK_BFS - V.1.6.doc

ic e
Page 16

Zo ne

.c

om