GSK - SAP IDM Implementation Strategy Paper V 5 0

GlaxoSmithKline
IdM Scope Approach Document ver. 5.0

Title: SAP NetWeaver IdM Scope Approach for ERP (CERPs) Programme
Issued date Guidance Note No Version Parent GSOP(s) Page Number
24 May 2010 5.0 i of xxvii
SAP NetWeaver IdM Scope Approach
GSK ERP (CERPs) Project

24 May 2010
Current Version: V 5.0
Submitted By: Elizabeth Duke

(SAP Principal Consultant – IDM/AC Project Team)
Approved By:
Approval Date:
Project Revision History

Version Date Revision Brief Description of Changes
Number Updated Author
1.0 04/05/2010 Elizabeth Duke Construction and Design of NW IDM Implementation
Strategy for GSK ERP CERPs Programme
2.0 07/05/2010 Elizabeth Duke Additional content to Scope Document

3.0 12/05/2010 Elizabeth Duke Refine and add additional content to Scope Document
4.0 17/05/2010 Elizabeth Duke Condense content to highlight only System Infrastructure
requirements, sizing and Platform structure as per Jonathan
Simcock in Review Meeting
5.0 08/06/2010 Elizabeth Duke Update of Sandbox minimum specs and update of QA/
DEV & Production sizing specs
Page | i
GlaxoSmithKline
24 May 2010 5.0 ii of xxvii
Version Approver Role Approver Name Embedded Approval

Number and Date
Related Documents/References
Document Name Location & File Version referred:
name
Level 3 IDM Implementation Project Plan v3.1
Page | ii
GlaxoSmithKline
24 May 2010 5.0 iii of xxvii
SAP NetWeaver IdM Scope Approach v 4.0

24 May 2010
Page | iii
GlaxoSmithKline
Strategy and Approach Document
Title: SAP NetWeaver IDM Strategy and Approach for ERP (CERPs) Programme
1 of 27
Table of Contents
1. PURPOSE...........................................................................................................................2
2. SCOPE................................................................................................................................2
3. CONSIDERATIONS..........................................................................................................2
4. SCOPE AND ARCHITECTURE FOR SAP NW IDM...................................................3
4.1. System Requirements – NW IdM Software..........................................................................3
4.2. System Requirements – NW IdM Hardware.........................................................................4
4.2.7. Identity Center servers.......................................................................................................................6
4.3. System Overview.......................................................................................................................6
4.3.1. Notes and Recommendations..........................................................................................................7
4.4. NetWeaver Identity Management 7.1 - Landscape.............................................................7
1.1. NetWeaver Identity Management 7.1 – Landscape Location..........................................8
1.2. Components to be Deployed................................................................................................11
1.2.1. The Virtual Directory Server:..........................................................................................................11
1.2.2. The Identity Center:...........................................................................................................................12
1.2.3. Runtime Components:......................................................................................................................12
1.2.4. Identity Management UI:..................................................................................................................12
1.2.5. Management Console:......................................................................................................................12
1.2.6. SAP Business Objects Access Control components are used in the following way:....12
1.2.7. Client Deployment Strategy............................................................................................................12
2. LEVEL 3 - NW IDM PLANNING...................................................................................13
2.1. IDM and Access Control Integration...................................................................................13
2.1.1. User Identity Center Workflows...........................................................................................14
2.2. NetWeaver Identity Management 7.1 Level 3 Planning...................................................15
2.2.1. Planned System Deployment Timeline........................................................................................16
2.2.2. Phase 1 - Planning and scope (04th – 21st May)..........................................................................16
2.2.3. Phase 2 – Foundation (17th May – 3rd July)..................................................................................16
2.2.3.1. Phase 2a - Resources(17th May – 13th June)...............................................................................17
2.2.3.2. Phase 2b - NW IdM Installation (SCS) – (14th – 30th June).......................................................17
2.2.4. Phase 3 - IdM Build - Sandbox (5th July – 20th August)............................................................17
2.2.6. Phase 3 - IdM Build - Development (1st – 30th September)..........................................................18
2.3. Resources..................................................................................................................................19
2.3.1. Resource – Overview........................................................................................................................20
2.3.2. Role and Responsibilities................................................................................................................20
Table of Figures
Figure 1 - Example of NW IdM Sizing.......................................................................................................... 4
Figure 2 - NW IdM - Identity Center Servers................................................................................................ 6
Figure 3 - NW IdM System Overview........................................................................................................... 7
Figure 4 – NetWeaver IdM Implementation Landscape: Wave 1 & Wave 2................................................8
Page | 1
GlaxoSmithKline
2 of 27
Figure 5 - ERP LPAR Landscape - GRC / IdM............................................................................................ 8

Figure 6 - CERPS Business Application Architecture................................................................................11
Figure 7 - CERPs Build Matrix................................................................................................................... 11
Figure 8 – ERP CERPs NW IdM Workflow Process..................................................................................15
Figure 9: Updated Level 3 Plan Overview with IdM...................................................................................16
Figure 10: ERP CERPs Programme Scope...............................................................................................19
Figure 11: Updated Resource Review with IdM requirement for Level 3 Planning....................................20
1. PURPOSE
The purpose of this document is to provide an approach strategy for the implementation of SAP
NW IDM 7.1 in conjunction with the GRC AC 5.3 for the ERP (CERPs) Programme at Glaxo,
Smith & Kline (GSK). The CERPs Programme is in line with GSK’s strategic vision of deploying
common processes on a Common Technology. The NetWeaver Identity Management 7.1 will
be used initially for CERPs SAP user provisioning environments.
2. SCOPE
The scope of this deliverable is to define the requirements of planning, landscape infrastructure
and system location within the ERP CERPs programme framework in order to prepare for
implementation of a NetWeaver Identity Management 7.1 solution:
The Approach Strategy will outline:
 Architecture to be required
 Integration points with LDAP
 Project plan overview that reflects all activities to be performed, duration and milestones in
line with the Level 3 Plan
 Required Resources
3. CONSIDERATIONS
a) A more in-depth and detailed Implementation Strategy document will need to be

formulated and completed in continuation of the Approach Strategy to ensure the
process for technical installation, integration, connectivity and configuration of NW IdM
7.1 with GRC Access Control 5.3 and relevant backend SAP NW 7.01 environments are
documented and implemented effectively within a template framework.
b) The NW IdM implementation project plan submitted with the Approach Strategy will need
to be expanded to define further task detail in order to ensure monitoring of the project
implementation is effective.
c) Only three SAP NetWeaver Identity Management systems will be recommended for the
Project Landscape i.e. SAP Web AS 7.01 Sandbox, Non-Production & Production. It
is understood that this is outside of current GSK landscape policy but necessary to
ensure a smooth provisioning process where an IdM environment does not conform to
normal landscape strategy due to the fact that it is a provisioning system. Should more
Page | 2
GlaxoSmithKline
3 of 27
NW IdM systems be enforced this would cause additional complex connectivity, which
would deviate from the purpose of implementing an IdM solution i.e. “to provide an
automated user self-service request environment with faster effective compliant control
approval process, automated provisioning, reduction of support desk issues and active
reporting to ensure the effective monitoring and control of user access and role
management”.
d) The NW IdM will only provision SAP environments initially. Non-SAP systems will
continue to be provisioned through the Virtual Provisioning product.
4. SCOPE AND ARCHITECTURE FOR SAP NW IDM
Essential Contents
 All required activities and dependencies
– Installation Requirements
– Hardware & Software
 NetWeaver Identity Management (NW IdM) Landscape
– Number of tiers
– NW IdM Location in NW 7.01 Landscape
– Backend systems in scope
– Connections
– Components to be deployed
 Level 3 Planning
- Appendix A – Implementation Plan
 Resources
– Define Resource requirements
– Roles and responsibilities
4.1. System Requirements – NW IdM Software

The provisioning framework for SAP systems is available for use with the following
components:
 SAP NetWeaver Identity Management: Release 7.1 SPS 4 (latest support pack should
be downloaded at time of installation)
The following features require a minimum Release 7.0 SPS 2:

 Support for time-dependent privilege assignments
 Support for connecting a central user administration central system
 Support for connecting a dual-stack system
 AS ABAP: Release 4.6C or higher
 AS Java/Portal: Release 6.40, 7.00, or 7.10
Page | 3
GlaxoSmithKline
4 of 27
In addition, SPML patches must be deployed on the AS Java as described in SAP Note
1064236.
The provisioning framework for SAP systems provides templates for both AS ABAP and AS
Java systems.
4.2. System Requirements – NW IdM Hardware

No specific requirements for sizing other than minimum requirements for the database
system and SAP NetWeaver AS Java.
Make sure to reserve no more than half the amount of physical memory for the database
to leave capacity for the runtimes.
4.2.1. Minimum Hardware Sizing for Oracle as the database system
The following table is a sample based on the following configuration:
• 100 000 entries

• Oracle as database system
Server Minimum system requirements

DB Unix 64-bit or Microsoft Windows 2003 Server
Memory >= 16 GB
CPU >= 4 CPU (multi/single core) 2Ghz processor Example: Intel® Core™2
CPU 6600 @ 2.40 GHz
Disk >= 1 TB
Dedicated HA Server
MC Microsoft Windows 2003 Server
Memory >= 1 GB
CPU >= 1 CPU 1Ghz processor
Disk >= 1 GB
RT Unix 64-bit or Microsoft Windows 2003 Server
Memory >= 6 GB
Disk >= 5 GB
Two or more servers with identical configuration
UI Unix 64-bit or Microsoft Windows 2003 Server
Memory >= 6 GB
Disk >= 300 GB, Requirements according to SAP NetWeaver AS Java
Two or more servers in a cluster
Figure 1 - Example of NW IdM Sizing
Current ERP CERPs Programme hardware specs for IDM and GRC:
IdM Database: IdM Application: GRC Database: GRC
Application:
SAPS 1085 (+1085 SAPS 2170 SAPS 1085 (+1085 SAPS 2170
HA) HA)
RAM 8GB (+8GB RAM 12GB RAM 4GB (+4GB RAM 12GB
HA) HA)
HDD 1 TB HDD 300GB HDD 128GB HDD 128GB
Page | 4
GlaxoSmithKline
5 of 27
It is understood that the NW IdM system will be on a separate Microsoft SQL Server for
Sandbox and then on Unix Keeping in line with best practice, it is strongly
recommended that the NW IdM system should not be installed on the same shared
server with the GRC AC 5.3 system, due to performance concerns, but rather the two
systems should be allocated their own LPAR environments within the technical server
landscape. The following provides further direction as to how the SBX, Dev, QA and
Production IDM 7.1 can be structured.
4.2.2. Sandbox System – SAP IDM 7.1
The Sandbox System for SAP IDM 7.1 can have all 4 components DB, MC, RT
and UI installed onto one Server either Microsoft or Unix and should have the
following minimum requirements:
2.22 Ghz
4 GB Memory
150 GB Disk Space
4.2.3. Production system – SAP IDM 7.1
Assuming that the production system has high availability requirements, a single
point of failure must be avoided. Therefore, the components are clustered or
duplicated.
There are four main components of the system:
• Database (DB). The database is either a Microsoft SQL Server or Oracle
database. The system platform is any which is supported by the selected
database. There should be at least two physical servers in a cluster for this. The
Identity Center does not require a dedicated database server (unless sizing
requirements demand it), so you may be able to use existing database instances.
Please note the installation and configuration requirements for the database, as
found in the installation guides (SAP NetWeaver Identity Management Identity
Center: Installing the database (Microsoft SQL Server/Oracle)).
• User Interface (UI). This is the end-user and administrator front-end, which
runs on SAP NetWeaver AS Java. High availability is handled by SAP
NetWeaver. The Identity Center does not require a dedicated NetWeaver, so
existing instances may be used.
• Runtime Components (RT). For high availability reasons, there must be at
least two RT servers. See the installation guide for supported platforms (SAP
NetWeaver Identity Management Identity Center Installation overview).
Dedicated servers are not required, so you may be able to use existing servers
for this. The number of RT servers and their placement in the network depends
on the identity management topology and network topology.
• Management Console (MC). This is the developer/IT administrator console,
running on Microsoft Windows, using the Microsoft Management Console. There
will normally not be any high availability requirements on this component, which
Page | 5
GlaxoSmithKline
6 of 27
can be installed on any Microsoft Windows server, and requires very little
resources. A dedicated server is not necessary.
4.2.4. Test / QA / DEV system
The test/QA and DEV system must contain the same components as the
production system, but high availability is not required, and also the performance
demands will be lower, so all components may be installed on the same
Microsoft Windows server. Or they can be installed on different systems, if that is
more convenient.
4.2.5. Synchronizing the configuration
It is assumed that all configuration changes are first tested on the test system,
and then transported to the production system. This is documented in the staging
document (SAP NetWeaver Identity Management Identity Center Implementation
Guide Staging environment).
4.2.6. Backup
As the Identity Center stores all configuration information in the database, this is the only
component which needs to be backed up.
Please see the backup and restore procedures for the relevant database for details on
these operations.
4.2.7. Identity Center servers
In the description of the system landscapes, the following names are used to identify the
different servers/components of the Identity Center.
Server Name Description

DB Database server The Identity Center database runs on this server.
MC Management Console This component is used for configuration of the Identity
Center.
RT Runtime Components This can be one or more servers, where the Identity
Center runtime engines are running.
UI User Interface The Identity Management User Interface runs on SAP
NetWeaver AS Java.
Figure 2 - NW IdM - Identity Center Servers
All components are running in the same environment

4.3. System Overview
A summary of the systems used in this use case are shown in the table below.
System Source Data Replicated/Provisioned Data
LDAP Directory Server Users Users and Groups -

and Groups –
Identity Center Role model Identities (Users)

Page | 6
GlaxoSmithKline
7 of 27
SAP NetWeaver AS Java (with Portal roles, UME roles  Replicated from LDAP:
Portal) UME users and UME
groups
 Provisioned from IC: Role
assignments
SAP NetWeaver AS ABAP ABAP roles and profiles Users and role assignments
Figure 3 - NW IdM System Overview
4.3.1. Notes and Recommendations

When setting up this use case in the Identity Center, take the following points into
consideration:
 In this use case, the corporate LDAP directory is the leading system for maintaining
identities i.e Sun One LDAP. If you maintain user master records locally in the target
system after performing the initial load into the Identity Center, these changes are
not reflected in the identity Center and are not included in the provisioning process.
(Note: Local changes to other attributes with a different source system, for example,
email addresses where the source system is a mail server, or changes to role or role
assignments can be provisioned back to the corresponding source system).
 Assign the business roles to identities in the Identity Center according to the role
model. The meaning of the business roles are then mapped to the corresponding
privileges and the corresponding user role assignments are provisioned to the target
systems.
 This use case shows how to set up identity management for the portal and AS Java
system with one back-end AS ABAP system. You can use the same concepts to set
up provisioning to further AS Java and AS ABAP systems. You can also provision to
non-SAP systems.
4.4. NetWeaver Identity Management 7.1 - Landscape

It is planned to implement only Four NetWeaver Identity Management 7.1 Servers to
support the provisioning of the ERP CERPs programme, namely: Sandbox (SBX), Non-
Production (DEV), Quality/ Testing (QA) and Production (PRD). The following diagram
indicates what backend systems will be connected to the NW IdM systems including
relevant clients.
The following systems have not been included as part of the backend systems in scope:
 SAP ECC AS Java
 SAP SRM AS Java
 SRM MDM Catalogue
 SCM AS Java
 SAP Live Cache
Page | 7
GlaxoSmithKline
8 of 27
 BW AS Java
Figure 4 – NetWeaver IdM Implementation Landscape: Wave 1 & Wave 2
1.1. NetWeaver Identity Management 7.1 – Landscape Location
Figure 5 - ERP LPAR Landscape - GRC / IdM
As Both the GRC and IdM environments will be working full-time. IdM will be handling requests
on a continual basis and then provisioning on a continual basis. When the Risk Analysis is not
Page | 8
GlaxoSmithKline
9 of 27
being called during approval of these requests it will be used independently by users i.e.
Business Owners, Security & Authorisation, Role changes & generation, etc. In addition, GRC
will be doing backend sync reports and jobs with target systems. Independently, IdM will also
be doing backend sync on roles and users. Peak for the backend jobs would be in the off-peak
times or at the weekend, but both systems will be functioning full-time. Therefore, it is always
suggested as best practise for the GRC to be located as a standalone, as the risk analysis
reporting does tend to pull on performances.
In the above planned ERP implementation landscape, it is planned for both the GRC and IdM
Production environments to be situated on separate LPARs, this is an acceptable strategy.
The Non-Production systems for GRC and IdM will be on a shared environment, which should
not be an issue provided correct virtual memory allocation is set.
As both the GRC and IDM systems do not have any impact on financial data or interfere with
regular compliancy reporting, there is no requirement to have GRC or IDM instances across the
full planned SAP ERP CERPs landscape. Therefore, it is suggested that only three instances
of GRC and IDM is required, as set out in figure 5 above, although this should be confirmed with
GSK Compliancy division:
IDM
1 x Sandbox (SBX) – to be utilised for initial installation and testing
1 x Development (DEV) – to be utilised for connectivity and provisioning to DEV and QA
environments (if required)
1 x Quality (QA) – to be utilised for testing
1 x Production (PRD) – to be utilised as the main client for generation of user requests,
approvals and provisioning to SAP Production and Non-Production environments
GRC
1 x Sandbox (SBX) – to be utilised for initial installation, design of workflows and testing
1 x Development (DEV) – to be utilised for connectivity to DEV and QA environments for Risk
Analysis reporting, Simulation and Role Management (if required)
1 x Quality (QA) – to be utilised for Testing
1 x Production (PRD) – to be utilised as the main client for provisioning to SAP Production and
Non-Production environments
(Note: GRC SPM and ERM in regards further planning after WAVE 1:
As SuperUser Privilege Management (ex FireFighter) will continue to be used in the backend
systems, the relevant GRC module will still be required to be installed on all backend
environments. The difference with GRC AC 5.3 from previous versions is that it allows for a
Central Console for SPM therefore allowing SPM (FireFighter) reports to be run and collated
from GRC AC 5.3 system (providing central repository of reports and simpler audit
requirements) – therefore there is no additional requirement for GRC systems in so far as this
aspect is concerned. SPM (FireFighter) reports can still be run individually via GUI directly in
the backend systems if required, as well as utilising the Java graphic frontend of GRC AC 5.3
for Audit and management requirement on the GRC DEV and PRD systems).
In regard Enterprise Role Management (ex-Role Expert) – it is understood that there is a

possible consideration in the planning to implement this component of the GRC AC 5.3 Suite.
Page | 9
GlaxoSmithKline
10 of 27
Once again there is no need to make allowance for additional GRC systems, as ERM is run
solely from the GRC DEV system as all new or changed roles would be generated to the
backend DEV systems, and then transgressed through to the QA systems through the normal
SAP transport framework if required. Once again the GRC ERM would do the generation of
new or changed roles through a role approval workflow via a request. No roles are ever
created, changed and provisioned directly into a PRD environment. The roles on approval
would be created/ changed in the DEV system environments and then transgressed through the
normal transport and QA testing strategy. Therefore, ERM is not installed on the GRC PRD
system, as it is not advised to allow for direct generation of roles on any PRD environment.
SAP is the strategic application platform for ERP Programme and the following SAP business
applications will be deployed as part of CERPS.
 SAP ECC (ABAP)
 SAP BW (ABAP & Java)
 SAP SRM (ABAP) including SRM-MDM Catalogue
 SAP SCM (ABAL & Java) including SAP LiveCache
 SAP PI (Dual)
 SAP IdM (Java)
 SAP GRC (Java)
 SAP TREX (Standalone Engine)
SAP is deployed on SAP’s Web Application Server platform which can be of type ABAP, Java
and/or Dual Stacks (ABAP/Java combined) and this is indicated above for each of the SAP
application in scope of CERPS.
Page | 10
GlaxoSmithKline
11 of 27
Figure 6 - CERPS Business Application Architecture
Figure 7 - CERPs Build Matrix
1.2. Components to be Deployed

SAP NetWeaver Identity Management components are used in the following way:
1.2.1. The Virtual Directory Server:

 Accepts requests from Identity Center.
Page | 11
GlaxoSmithKline
12 of 27
 Deals with all connection to/from SBOP Access Control through the web service API
exposed by SBOP Access Control.
1.2.2. The Identity Center:

 Contains the workflow tasks and the necessary jobs that drive the provisioning to
SBOP Access Control based on the Provisioning Framework for SAP Systems.
 Communicates with the Virtual Directory Server (VDS) using the LDAP protocol.
1.2.3. Runtime Components:
 The Runtime Components (dispatchers, runtime engines and event agents) act as
local or remote agents for the Identity Center and are responsible for processing both
provisioning and synchronization tasks. They are also responsible for performing
reconciliation and bootstrapping. Event agents can be configured to take action
based on changes in different types of repositories such as directory servers,
message queues or others. This mechanism is optional and its only purpose is to
initiate synchronization based on changes in repositories in addition to the scheduled
operations.
1.2.4. Identity Management UI:

 The Identity Management User Interface is used for all end-user registration/self
service, password resets and approval of tasks. It also contains monitoring
information for administrators of the Identity Center.
1.2.5. Management Console:
 The administrator interface in the Microsoft Management Console is used for

configuring the Identity Center, including provisioning/workflow tasks and jobs.
1.2.6. SAP Business Objects Access Control components are used in the
following way:
 Compliant User Provisioning (CUP):
 Provides web services for compliance checks, status checks, etc.
 Workflow for risk analysis and mitigating controls
 Risk Analysis and Remediation (RAR):
 Provides risk analysis services to detect SOD violations and critical permissions
 CUP-RAR communication via internal web services
1.2.7. Client Deployment Strategy
The SAP client concept is only applicable to SAP applications which are deployed on the
SAP Web AS ABAP stack or dual stack of ABAP/Java in the same instance. The SAP
applications which are deployed with SAP Web AS ABAP or SAP Web AS Dual Stack in
the CERPS landscape which NW IDM will be connecting are as followed.
Page | 12
GlaxoSmithKline
13 of 27
 SAP ECC
 SAP SRM
 SAP SCM
 SAP BW
 ERP Portal
 SAP PI
 SAP Solution Manager
 Web Dispatcher
 GRC AC
 NWDI (?)
 TREX (?)
2. LEVEL 3 - NW IDM PLANNING

This section describes the steps required in sequential order to implement the SAP NW IDM
7.1 software application. Further in-depth implementation detail will be covered in the SAP
IDM Strategy Document to be completed after acceptance of the NW IDM Approach.
2.1. IDM and Access Control Integration

Implementation Assumptions:
 Acceptable hardware specifications and sizing of the NW IdM systems have been
approved and installed
 User Request submission source
- The request submission source will be initiated in NW IdM 7.1
 Provisioning roles
- Role source: Where will the roles for provisioning be maintained (AC and/or
IdM).
- The preferred approach is to have one role source for SAP roles which in this
case would be NW IdM. Role updates would be done with the backend
systems on a regular basis to ensure that role assignment is with the correct
backend role. Should the ERM product from GRC be used in future for role
management – NW IdM would then sync with ERM for up to date role
structures.
 Approval workflow
- Approval workflows would be conducted in the NW IDM system with the
exception that when a Risk Analysis is run and an SoD issue arises that the IDM
Approver would need to log in directly to the GRC AC CUP environment to
assign mitigation. The IDM request on mitigation assignment would then be
passed back to NW IDM for provisioning to respective user.
(Note: Should there be no available mitigation control in RAR then the request
would need to be either put on “hold” within CUP or Approver reject the Request
Page | 13
GlaxoSmithKline
14 of 27
and a new mitigation control is then defined and created in the GRC AC RAR
module in relation to the new risk issue encountered)
.
- Need to consider user notifications from AC and/or IdM when rejecting request
at SoD mitigation stage of workflow as NW IdM does not have a web service
connectivity with GRC AC for this functionality.
 Risk analysis
- The risk analysis web service through GRC RAR does not support risk
simulation. Risk simulation can only be performed directly in AC 5.3 RAR
module. (When provisioning new users, the request has to be submitted to AC
for risk analysis. IdM can retrieve the result by polling the risk analysis web
service with Request ID).
- Initially all new users will be created in the Sun One LDAP. Only SAP user
change requests will be processed and provisioned through NW IdM. Requests
for provisioning to non-SAP instances will be provided by Virtualization
Provisioning (VP) powered by CA IdM. It is envisaged that NW IdM will handle
requisition and provisioning of all SAP & Non-SAP in the future and that VP
would be decommissioned. When provisioning existing users, risk analysis can
be called by IdM.
 Request status and audit trails

- Consider requirements for request status and audit trails while defining the
integration solution. (Web services can only pass certain fields while more
details may be viewed natively in AC or IdM.)
 Existing functionality and change control

- IdM change control policy and its impact on solution and implementation are limited
and can be incorporated into the GSK upgrade/ support patch release maintenance
program. When release maintenance is required, Approvers will be requested to
approve active requests by end of day. Users will be advised that requests cannot
be submitted through the portal for a limited time. No other requests after the preset
maintenance time can be generated either on site or remotely. Once maintenance
has been completed (usually over a 48hr period) requests will then be permitted to
be generated through NW IDM via the portal iView object.
2.1.1. User Identity Center Workflows

 Workflow support for identity management operations is an important feature of the
Identity Center.
 Employees, their managers, and the IT team can use workflows to delegate certain
tasks to the responsible people.
Page | 14
GlaxoSmithKline
15 of 27
 You can create Web-based tasks for interactive identity management operations
(request, approval, etc.), but rule definitions that have no interaction are also defined
in the workflow.
 The workflows can either be triggered by a Web interface task or by an “event task”
that recognizes changes.
 The definition of the rule logic is highly flexible. This includes sequential, parallel,
conditional, and approval operations.
 As it is not envisaged to connect with the GSK HCM environment, all workflows in
the Level 3 template with be triggered by a web interface i.e. generates/ submitted
request through the SAP portal.
Figure 8 – ERP CERPs NW IdM Workflow Process
2.2. NetWeaver Identity Management 7.1 Level 3 Planning

The current GRC Security Level 3 planning covers activities which are not contained within
the Programme Level 2 plan. These activities are summarised as below. The designed
Level 3 planning for NW IdM will cover the same activities to encompass uniformity and
consistency from a Template perspective. It is understood that at time of scoping that a
Change Request 423 had already been submitted to encompass NetWeaver Identity
Management 7.1 in the ERP CERPs Programme of which this Scope document is based.
Below is a basic outline of the planned phases with a more detail planning scope defined in
the Project Plan.
Page | 15
GlaxoSmithKline
16 of 27
Figure 9: Updated Level 3 Plan Overview with IdM
2.2.1. Planned System Deployment Timeline

Sandbox (SBX) - 4th – 15th July 2010
Development (DEV) - Beg. September 2010
(Note: As the IDM systems have been brought in after the DEV & QA builds for Project
Landscape – the IDM DEV will also be utilized for Testing)
Production (PRD) - Beg. January 2011
QA, DEV and SBX in Production landscape will be avaible from March 2011 onwards.
The NW IdM implementation plan and timelines are outlined below with further details
on activity tasks in the NW IdM project implementation plan.
2.2.2. Phase 1 - Planning and scope (04th – 21st May)
 Define requirements specifications
- Sizing considerations – Hardware and Software
- Implementation process and methodology
- Define Workflow process
- Define Timeline
- Scope and Architecture
- Define Components to be deployed
- Define Client deployment strategy
- Define Resources
2.2.3. Phase 2 – Foundation (17th May – 3rd July)
(Technical Implementation only)
Page | 16
GlaxoSmithKline
17 of 27
 Design detailed implementation strategy

 Acquire functional requirements
- Create IdM design specifications
 Define role mapping structure
 Define Approvers
 Define Approval workflows
 Define Request Type Structure
 Define configuration
 Define GRC integration process
 Define NW IdM component configuration
- Define landscape connectivity
- Create GBPs and SOPs
 Create NW IdM SRs
2.2.3.1. Phase 2a - Resources(17th May – 13th June)
 Approval of required Resources

 Active Recruitment on-site to NW/ GRC AC Project
2.2.3.2. Phase 2b - NW IdM Installation (SCS) – (14th – 30th June)
 Download components
 Install components
 Perform initial configuration
2.2.4. Phase 3 - IdM Build - Sandbox (5th July – 20th August)
 Configuration of Sandbox:
- Configure Virtual Directory Server
- Configure Identity Center
- Configure Runtime components
- Configure Identity management UI
- Configure Management Console
- Configure Business Objects Access Control components
- Setup connectors in the Test (Sandbox) and Development system
- Configure IdM and GRC AC web services
- Test backend system connectivity and web services
- Setup individual provisioning frameworks in both NW IdM and GRC
AC CUP
- Setup and configure User/ Role Requests structure and process
 Workflows:
- Setup up approval workflows and other processes – NW IdM and
GRC AC CUP
- Setup up SoD exception and mitigation workflows in GRC AC Cup
- Import sample users and roles
- Design role mapping of default and template roles in user request
- Implement authorization concept
- Setup workflow reporting
Page | 17
GlaxoSmithKline
18 of 27
 Setup and run initial loads in development / test system(s)

 Perform data cleansing
 Run and test approval workflows with SoD exception rule
 Run and test initial provisioning in Test and Dev systems
 Setup regular backend batch sync and custom jobs
 Setup regular and compliance reporting
2.2.5. Phase 4 - IdM Sandbox UnitTest (23rd August – 17th September)
 Test Request generation

 Test approval workflows with SoD exception rule
 Test provisioning in Test and Dev connected systems
 Test stability of IdM system
 Sign off of Test NW IdM systems in preparation for IDM DEV Build and Wave
1 Master Data Load
2.2.6. Phase 3 - IdM Build - Development (1st – 30th September)
 Configuration of DEV:
- Configure Virtual Directory Server
- Configure Identity Center
- Configure Runtime components
- Configure Identity management UI
- Configure Management Console
- Configure Business Objects Access Control components
- Setup connectors in the (DEV) Development system
- Configure IdM and GRC AC web services
- Test backend system connectivity and web services
- Setup individual provisioning frameworks in both NW IdM and GRC
AC CUP
- Setup and configure User/ Role Requests structure and process
 Workflows:
- Setup up approval workflows and other processes – NW IdM and
GRC AC CUP
- Setup up SoD exception and mitigation workflows in GRC AC Cup
- Import sample users and roles
- Design role mapping of default and template roles in user request
- Implement authorization concept
- Setup workflow reporting
 Setup and run initial loads in development / test system(s)
 Perform data cleansing
 Run and test approval workflows with SoD exception rule
 Run and test initial provisioning in Test and Dev systems
 Setup regular backend batch sync and custom jobs
 Setup regular and compliance reporting
2.2.7. Phase 4 - IdM DEV Test (1st – 22nd Oct)
 Test approval workflows with SoD exception rule

Page | 18
GlaxoSmithKline
19 of 27
 Test provisioning in Test and Dev systems

 Test stability of IdM systems
 Sign off of Test and Development NW IdM systems in preparation for Wave 1
Master Data Load
2.2.8. Phase 5 - Wave 1 Master Data Load ( 20th Sept – 22nd Oct)
 LDAP integration
 Semi-Automated Provisioning SAP Non-Production
 GRC Integration
 User Data upload – 2,500
 Leavers process
2.2.9. Phase 6 - IdM Test Stage – Wave 1 (25th Oct – 17th Nov)
 Test LDAP integration

 Test semi-automated provisioning into SAP 7.01 systems
 Test stability of NW IdM Non-Production Servers
 Test Leavers process

Figure 10: ERP CERPs Programme Scope
2.3. Resources
Page | 19
GlaxoSmithKline
20 of 27
2.3.1. Resource – Overview

The following diagram shows how the Security Resource profile evolves during course of
2010 and beyond. This overview has needed to be updated to reflect SAP NW IdM
requirements
Figure 11: Updated Resource Review with IdM requirement for Level 3 Planning
2.3.2. Role and Responsibilities

The following table further expands the roles and responsibilities of Programme
members associated with the NW IdM/ GRC Implementation Team. This table only
identifies to reflect the roles and responsibilities for the new requirements.
Role Responsibilities
GRC Functional  Functional implementation of GRC AC 5.3 systems
Consultant
 Configuration of GRC AC 5.3 components (RAR, SPM,
ERM, CUP)
 Assist IdM Consultant in designing SoD exception
workflow in CUP
 Quality Assurance
 Documentation
 Documenting of Issue Log and Resolutions
Page | 20
GlaxoSmithKline
21 of 27
 Product Training and information overview workshops

IdM Technical  Technical IdM Installation
Support
 Technical Guidance
(full-time – 6
month period)  Technical NetWeaver & IdM Support
 Quality Assurance
 Technical Documentation
 Transition to Support
 Technical Issue Resolution
IDM/GRC Team  IdM Functional Implementation / Configuration
Lead Consultant
 Workflow Approval Design Implementation
(full-time till end
of IdM project  GRC Access Control Integration
scope – March  Implement Virtual Directory Server
2011)
 Implement Control Centre
 Documentation
 Transition to Support
 Issue Resolution
 Training
 Preparation of NW IDM Approach Strategy
 Preparation of detailed Implementation Project Plan
 Assistance with NW IdM / GRC Installation infrastructure
and Implementation of NW IDM / GRC Systems
 Integration of Provisioning workflows in conjunction with
GRC AC 5.3 product Suite
 Track and manage progress of NW IdM/ GRC AC Project
integration
 Provide updated NW IdM Project reporting
 Integral role in Configuration, Testing, Documentation
and Knowledge Transfer of the NetWeaver Identity
Management 7.1 framework
 Documenting of Issue Log and Resolutions
 Product Training and information overview workshops
 Design and documenting of IdM best practise processes
to assist with continuance of Governance, Risk
Management and Compliancy
Page | 21
GlaxoSmithKline
22 of 27
Page | 22
GlaxoSmithKline
23 of 27
Glossary of Terms
NW IDM – NetWeaver Identity Management
GRC – Governance, Risk and Compliance (Business Software Area in SAP AG)
CUP – Compliant User Provisioning
AC 5.3 – Access Control v. 5.3
SOD – Segregation of Duty
ERM – Enterprises Role Management
SPM – GRC AC 5.3 SuperUser Privilege Management
Page | 23

GSK - SAP IDM Implementation Strategy Paper V 5 0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GSK - SAP IDM Implementation Strategy Paper V 5 0

Uploaded by

Copyright:

Available Formats

GlaxoSmithKline

IdM Scope Approach Document ver. 5.0

SAP NetWeaver IdM Scope Approach

GSK ERP (CERPs) Project

Submitted By: Elizabeth Duke

Project Revision History

2.0 07/05/2010 Elizabeth Duke Additional content to Scope Document

Version Approver Role Approver Name Embedded Approval

SAP NetWeaver IdM Scope Approach v 4.0

Figure 5 - ERP LPAR Landscape - GRC / IdM............................................................................................ 8

The Approach Strategy will outline:

a) A more in-depth and detailed Implementation Strategy document will need to be

4. SCOPE AND ARCHITECTURE FOR SAP NW IDM

4.1. System Requirements – NW IdM Software

The following features require a minimum Release 7.0 SPS 2:

4.2. System Requirements – NW IdM Hardware

• 100 000 entries

Server Minimum system requirements

HDD 1 TB HDD 300GB HDD 128GB HDD 128GB

4.2.3. Production system – SAP IDM 7.1

Server Name Description

All components are running in the same environment

System Source Data Replicated/Provisioned Data

LDAP Directory Server Users Users and Groups -

Identity Center Role model Identities (Users)

4.3.1. Notes and Recommendations

4.4. NetWeaver Identity Management 7.1 - Landscape

Figure 4 – NetWeaver IdM Implementation Landscape: Wave 1 & Wave 2

1.1. NetWeaver Identity Management 7.1 – Landscape Location

Figure 5 - ERP LPAR Landscape - GRC / IdM

In regard Enterprise Role Management (ex-Role Expert) – it is understood that there is a

Figure 6 - CERPS Business Application Architecture

Figure 7 - CERPs Build Matrix

1.2. Components to be Deployed

1.2.1. The Virtual Directory Server:

1.2.2. The Identity Center:

1.2.3. Runtime Components:

1.2.4. Identity Management UI:

1.2.5. Management Console:

 The administrator interface in the Microsoft Management Console is used for

1.2.7. Client Deployment Strategy

2. LEVEL 3 - NW IDM PLANNING

2.1. IDM and Access Control Integration

 Request status and audit trails

 Existing functionality and change control

2.1.1. User Identity Center Workflows

Figure 8 – ERP CERPs NW IdM Workflow Process

2.2. NetWeaver Identity Management 7.1 Level 3 Planning

Figure 9: Updated Level 3 Plan Overview with IdM

2.2.1. Planned System Deployment Timeline

2.2.3. Phase 2 – Foundation (17th May – 3rd July)

(Technical Implementation only)

 Design detailed implementation strategy

 Create NW IdM SRs

2.2.3.1. Phase 2a - Resources(17th May – 13th June)

 Approval of required Resources

2.2.3.2. Phase 2b - NW IdM Installation (SCS) – (14th – 30th June)

2.2.4. Phase 3 - IdM Build - Sandbox (5th July – 20th August)

 Setup and run initial loads in development / test system(s)

2.2.5. Phase 4 - IdM Sandbox UnitTest (23rd August – 17th September)

 Test Request generation

2.2.6. Phase 3 - IdM Build - Development (1st – 30th September)