Identity Center
Tutorial
- Working with roles and privileges
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Outlook, Excel, and PowerPoint are registered trademarks of Microsoft Corporation. IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML, and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves information purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and
Preface
The product
SAP NetWeaver Identity Center is a high-end identity management solution, capable of handling a large amount of repositories containing an unlimited amount of information. The Identity Center offers a robust, flexible and scalable high-availability solution for workflow, provisioning, data synchronization and joining for a large number of data repositories. The Identity Center provides a framework for a number of jobs.
The reader
This manual is written for people who need an introduction to the workflow module of the SAP NetWeaver Identity Management Identity Center and the managing of roles and privileges.
Prerequisites
To get the most benefit from this manual, you should have the following knowledge:
General knowledge about the Identity Center and job definitions for instance as described in SAP NetWeaver Identity Management Identity Center Getting Started and SAP NetWeaver Identity Management Identity Center Tutorial: Basic Synchronization.
General knowledge about provisioning and task definitions as described in SAP NetWeaver Identity Management Identity Center Tutorial – Provisioning.
Knowledge of Microsoft SQL Server or Oracle. The following software is required:
SAP NetWeaver Identity Management Identity Center version 7.0 or newer must be correctly installed and licensed.
An Identity Center where at least one dispatcher has been configured and is running. An Identity Center Workflow web interface configured for this Identity Center and identity store.
The data source used in this tutorial (hr.csv) is included with the installation. The file is located in the \Tutorial\Data source directory. In this tutorial the default installation folder is used, which is C:\Program Files\SAP\IdM\Identity Center.
The manual
The manual is a tutorial giving an introduction to the privileges, roles and workflow functions of the Identity Center.
Related documents
You can find useful information in the following documents:
SAP NetWeaver Identity Management Identity Center: Installing the database (Microsoft SQL Server/Oracle)
SAP NetWeaver Identity Management Identity Center Getting Started
SAP NetWeaver Identity Management Identity Center Tutorial: Basic Synchronization SAP NetWeaver Identity Management Identity Center Tutorial – Provisioning
Table of contents
Introduction ... 1
Roles and role-based provisioning...1
The identity store ...2
Workflow ...2
Access control on tasks ...3
Use cases ...3
Tasks, roles and privileges ...5
The data source...8
The data flow and the task structure ...9
Preparations ...9
Section overview ...11
Section 1: Creating the identity store ... 12
Adding the identity store...12
Configuring the identity store...14
Section 2: Building the identity store ... 15
Defining a repository definition for the data source ...15
Reading the source data into the identity store...18
Verifying the contents of the identity store ...23
Enabling the delta ...25
Section 3: Creating the privileges ... 26
Creating folders for privileges...26
Defining repository definitions for folders...27
Creating the privileges ...29
Section 4: Creating the provisioning tasks ... 30
Creating global Jscript GetMskeyvalueFromPriv...30
Creating the provisioning tasks for the Building repository definition...32
Creating the provisioning tasks for the Project repository definition ...39
Testing the tasks ...44
Defining tasks on the repository definitions...46
Section 5: Creating the Workflow tasks... 49
Creating the folder ...49
Adding the Workflow tasks...50
Section 6: Creating the roles... 62
Starting the Workflow web interface...62
Creating the roles...64
Section 7 Use case Physical access control ... 66
Building the role hierarchy...66
Provisioning to project folder ...85
Introduction
The purpose of this tutorial is to give an introduction to managing and assigning roles and privileges, and the Workflow web interface of the SAP NetWeaver Identity Management Identity Center. The tutorial shows how to create roles and privileges, and how to define mechanisms for assigning these to identity store entries using Workflow. We create Workflow tasks to create roles and manage the roles and privileges. The privileges and provisioning tasks are created directly in the Identity Center user interface.
Roles and role-based provisioning
When implementing a provisioning solution, you can use two different provisioning mechanisms:
Role-based provisioning: The Identity Center supports the use of roles to assign privileges to users.
Rule-based provisioning: Some users need privilege assignments which do not easily fit into the roles. These can be assigned by defining rules. In this case, if a user entry matches a given set of rules, a privilege is assigned and thereby also the required provisioning.
In this tutorial, we illustrate role-based provisioning.
A role hierarchy can be defined, where each role can be assigned any number of privileges. By assigning one or more roles to a user, the necessary provisioning is done automatically for this user, to grant access or set other information in the required applications. When roles are removed from a user, de-provisioning will ensure that the privileges are removed.
The identity store
The identity store is used to hold any types of entries. Entry types are used to group these entries.
In this tutorial, the following entry types are used:
MX_PERSON A person entry with attributes describing a person, such as first name, last name, telephone number, e-mail address etc. In addition, it can be assigned to any number of roles and privileges.
MX_PRIVILEGE A privilege entry type that defines a privilege to a given resource, for instance access in a given system. A user can be assigned any number of privileges, either directly or as a result of roles having privileges. Assigning and removing privileges can automatically start tasks to perform
provisioning and de-provisioning.
MX_ROLE Roles can be created as a hierarchy, each role having a number of
privileges. Assigning a role to a user automatically assigns all the privileges of the role to the user. In addition, any child roles and privileges are
assigned to the user.
Workflow
The Identity Center's Workflow is designed and configured through a feature-rich graphical user interface and is tightly integrated with the identity store. A workflow is started every time a provisioning request is initiated. The Identity Center Workflow can be used to:
Collect identity information from the specific individuals.
Enforce single- or multi-stage approvals from authorized personnel.
Generate notifications to designated users when manual actions need to be performed, or report the outcome of completed tasks.
Access control on tasks
The Identity Center Workflow module is based on executing tasks. Who is allowed to execute which tasks is controlled by the task access control that can be set individually on each task. The access control consists of two components:
Who is allowed to execute the task. On which entries can the task be executed.
When defining who can execute a task, it is possible to define one of the following:
Anonymous, which means that the user doesn't have to be logged-in to be able to execute the task (the task will usually appear on the log-in site).
Logged-in user or identity store entry (usually a person, but it could be a privilege, a role or a dynamic group as well).
Referral, where the access is given through a referral via an attribute specified with the "Referral attribute" field. The task is available to all users who are referred to by the given referral attribute.
The MSKEYVALUE of the entry is used for identification. Also note that multiple access control rules can be defined in each task.
When defining on which (on behalf of which) entries a task can be executed, the following options can be used:
Everybody.
User or identity store entry/self service – a given user, privilege or role, meaning that the task can be executed on the given user, all users with the given privilege or all users with the given role.
Filter – a filter (typically an SQL statement) can be used to define a set of entries on behalf of which the task can be executed.
Use cases
Two use cases are used in this tutorial – one modeling the physical access control in a building (workplace), and other modeling a development project group with access to common (or role specific) project resources.
Physical access control
This use case models a workplace (building) where users (employees) are given access rights to building areas based on their job-role.
The model is kept as simple as possible. We take the following into the consideration: All employees need the access to the building (access right to a main entrance). The IT personnel need access to the server room.
Based on the information above, four roles are defined for this use case: ROLE:Employee, ROLE:IT, ROLE:Adm and ROLE:Manager. The defined privileges are PRIV:MainEntrance, PRIV:ServerRoom and PRIV:ArchiveRoom, which give the user access rights to the main entrance, the server room and the archives respectively.
Project resources
This use case models a typical development project group, where all group members are given access to the resources needed for the project. The resources used by the project group could be a project archive (physical or non-physical), software, domain or other tools.
To keep it simple, the project group members need access to only one project resource in this scenario. The resource is a non-physical project archive.
The access to the project archive is given users by the privilege PRIV:ProjectArchive (the only privilege defined for this use case). Six roles are defined for the use case: ROLE:Developer, ROLE:Doc, ROLE:Tester, ROLE:HeadDeveloper, ROLE:TestLeader and ROLE:ProjectLeader.
Tasks, roles and privileges
The following Workflow tasks are defined to create/manage roles and privileges:
Create role This task is used to create roles in the identity store. MSKEYVALUE is used to identify the roles and the typical value could be ROLE:Employee.
Edit role properties This task is used to manage the roles – to modify some information about the role. Here we can build the hierarchy by adding child roles and we can assign/connect privileges to the role.
Assign role This task is used to assign a role to a user. You can add new or remove existing role members.
Four provisioning tasks are also created, one for provisioning and one for de-provisioning of users for the two repository definitions Building and Project. Every time a user is given a particular privilege, a file will be created (containing the timestamp of when the privilege was assigned to the user) and provisioned to the respective folder:
#Building_Provisioning This task is referenced from the Building repository definition using the attribute MX_PROVISIONTASK. The task contains the shell execute pass Add file to building folder which creates a file containing the timestamp of when a privilege is assigned to user and provisions it to the building folder.
#Building_Deprovisioning This task is referenced from the Building repository definition using the attribute MX_DEPROVISIONTASK. The task contains the shell execute pass Delete file from building folder which deletes the previously created file from the building folder.
#Project_Provisioning This task is referenced from the Project repository definition using the attribute MX_PROVISIONTASK. The task contains the shell execute pass Add file to project folder which creates a file containing the timestamp of when a privilege is assigned to user and provisions it to the project folder.
#Project_Deprovisioning This task is referenced from the Project repository definition using the attribute MX_DEPROVISIONTASK. The task contains the shell execute pass Delete file from project folder which deletes the previously created file from the project folder.
We define ten roles in this tutorial:
ROLE:Employee This role gives the privilege PRIV:MainEntrance.
ROLE:IT This role gives the privilege PRIV:ServerRoom. In addition, it inherits the privilege PRIV:MainEntrance from its child role ROLE:Employee.
ROLE:Adm This role gives the privilege PRIV:ArchiveRoom. In addition, it inherits the privilege PRIV:MainEntrance from its child role ROLE:Employee.
ROLE:Manager This role has two child roles – ROLE:IT and ROLE:Adm, and thus inherits the privileges PRIV:MainEntrance, PRIV:ServerRoom and PRIV:ArchiveRoom.
ROLE:Developer ROLE:Developer gives no privileges on its own, but inherits the privilege PRIV:ProjectArchive from the role ROLE:ProjectLeader.
ROLE:HeadDeveloper This role inherits the privilege PRIV:ProjectArchive from
ROLE:ProjectLeader. It has one child role – ROLE:Developer, and is a child role itself.
ROLE:Tester ROLE:Tester gives no privileges on its own, but inherits the privilege PRIV:ProjectArchive from the role ROLE:ProjectLeader.
ROLE:TestLeader This role inherits the privilege PRIV:ProjectArchive from
ROLE:ProjectLeader. It has one child role – ROLE:Tester, and is a child role itself.
ROLE:Doc This role inherits the privilege PRIV:ProjectArchive from ROLE:ProjectLeader, and has no child roles but it is a child role itself.
ROLE:ProjectLeader This role has three child roles – ROLE:Doc, ROLE:TestLeader and ROLE:HeadDeveloper. It gives the privilege PRIV:ProjectArchive.
Four privileges are defined in this tutorial:
PRIV:MainEntrance This privilege gives the users the right to access the building (main entrance).
PRIV:ServerRoom The privilege gives the user access to the server room. Often given to IT personnel.
PRIV:ArchiveRoom The privilege gives the user access to the archive. Often given to the administration staff.
PRIV:ProjectArchive This privilege gives the project members access to common (non-physical) project archive.
The data source
The data source, an ASCII file hr.csv, used in this tutorial is included with the installation. The file is located in the \Tutorial\Data source directory. In this tutorial the default installation folder is used, which is C:\Program Files\SAP\IdM\Identity Center.
The ASCII file hr.csv holds the basic information about the person objects (people in the organization). This file contains the following attributes:
EmployeeID LastName FirstName Title Dep (department) Location
The data flow and the task structure
The following diagram illustrates the data flow that we are going to implement in this tutorial:
There is a job (Employees to Identity store) that reads the data from the source file hr.csv and updates the entries in the identity store. The entry type for these entries is MX_PERSON. We create four privileges (PRIV:MainEntrance, PRIV:ServerRoom, PRIV:ArchiveRoom and PRIV:ProjectArchive) that we can assign to the entries. The privileges contain links to the repository definitions which again contain links to the tasks that are executed when the privilege is assigned or removed.
The task structure is shown in the illustration above. There are separate task structures for each of the target repositories (the folders building and project).
Preparations
Before you proceed with the tutorial, there are a couple of things that must be specified.
Defining a global constant
To be able to reference the files created in this tutorial in a uniform way, we create a global constant containing the path to the directory where the target repositories for the files (folders building and project) are to be placed:
1. Select the "Global constants" entry in the console tree and choose New/Constant… from the context menu (right-click the entry to open the context menu):
Specifying the system log level
To be able to view the log information shown in this tutorial, you must make sure that the log level for the system log is set to "Info". If necessary, change the log level and choose "Apply".
Section overview
The tutorial consists of the following sections:
Section 1: Creating the identity store This section describes how to create the identity store and enable it for workflow.
Section 2: Building the identity store In this section we are going to read the contents of the file hr.csv into the identity store.
Section 3: Creating the privileges This section shows how to create the privileges. Section 4: Creating the provisioning tasks This section describes how to create the tasks
responsible for provisioning and de-provisioning of users.
Section 5: Creating the Workflow tasks This section shows how to create the Workflow tasks.
Section 6: Creating the roles In this section we create roles by executing the Workflow tasks created in the previous section. Section 7: Use case Physical access control In this section we learn how to assign roles and their
privileges to a user, using the Workflow interface. Section 8: Use case Project resources This section introduces reverse privilege inheritance
direction (top-down inheritance direction). The section shows the difference between the bottom-up and top-down inheritance direction of the privileges and how to implement reverse inheritance.
Section 9: Deleting roles In this section we learn how to delete roles we previously created.
Section 1: Creating the identity store
This section describes how you create and initialize the identity store.
Adding the identity store
First, we create the identity store.1. Select the entry "Identity stores" in the console tree, and choose New/Identity store... from the context menu to start the Identity store wizard.
2. Choose "Next >".
Enter a name for the identity store.
Disable the automatic attribute creation. This option is used to control what happens when an attribute which does not exist or an attribute which is not defined as a legal attribute on an entry type is written to the identity store.
If the "Automatically create new attributes" is enabled, the new attribute is created and added to the entry type. If the option is disabled, an error is returned.
3. Choose "Next >".
We will use the MX_PERSON entry type, so we do not need any additional entry types. 4. Choose "Next >" and then "Finish" to complete the wizard.
Configuring the identity store
To configure the identity store:1. Select the "PrivRoles" identity store in the console tree and select the "Workflow" tab:
Select "Identity store" as the authentication method. This is necessary to be able to log into the workflow.
2. Choose "Apply". 3. Choose "Add user…".
Select "MX_PERSON" in the "Entry type" field.
Fill in a user name and password you will use to log in to the Workflow interface. 4. Choose "OK".
Section 2: Building the identity store
In this section we are going to read the contents of the source file hr.csv into the identity store.
Defining a repository definition for the data source
A repository definition is used to hold constants and variables which are common for one data source (repository). The repository constants can be accessed from the context menu in the same way as global constants.1. Start the repository wizard by selecting the "Repositories" entry in the console tree, and choosing New/Repository… from the context menu.
2. Choose "Next >".
3. Choose "Next >".
Name the repository definition Employees. 4. Choose "Next >".
Fill in the file name.
5. Choose the "…" button.
Navigate to and select the file hr.csv. 6. Choose "Open".
Reading the source data into the identity store
We have now created a repository definition for the hr.csv file and defined an identity store that we can use when creating the job which will read the source data to the identity store.
Creating the folder and job
First, we are going to create a folder for the jobs in the tutorial, and the job definition for this job.
1. Create a folder called "PrivRoles job folder" that can be used to hold the jobs. Select the Identity Center's entry in the console tree and choose New/Folder… from the context menu to create the folder.
2. Create a job by selecting the folder's entry and choosing New/Empty job from the context menu.
Modify the name of the job in the console tree. Enable the job and select a dispatcher.
3. Choose "Apply".
This job will contain two passes; one to read the source (ASCII) file hr.csv into the temporary table (tutorial_employees), and another to read from this table into the identity store. This must be done in a single job. The reason is that the first pass will delete the temporary table every time it executes, and then fill it with the data from the hr.csv file. If the second pass was a separate job (which could then be run asynchronously from the first), it could start just when the table was deleted or just partly filled, and then remove the missing people from the identity store.
Reading the source file
First, we will create the pass that reads the source (hr.csv) file:
1. Select the job in the console tree and choose New/From ASCI file from the context menu.
Enter Read Employees as the name of the pass in the console tree.
Repository
Select the "Employees" in the "Repository" list. 2. Select the "Source" tab and fill in the following:
File name
Use the context menu to insert the repository constant %$rep.FILENAME% that refers to the file name.
Field separator
Enter a comma sign (,) as the field separator.
Header line
Make sure that "Header line" is selected. 3. Select the "Destination" tab:
Fill in the fields with the following values:
Database
Use the context menu to insert the system parameter %$ddm.identitycenter% that refers to the Identity Center database.
Table name
Enter tutorial_employees as the table name.
Note:
Do not use hyphen in table names, as this will cause problems with some database drivers.
Definitions
Choose "Insert template" and select "Data source template" to create the pass definitions. 4. Choose "Apply".
Running the job
At this point, we are ready to test the pass. Run the job by viewing the job properties and choosing "Run now". View the job log to verify that the job ran successfully, and that a number of entries have been processed.
Updating the identity store
The next step is to create the pass that writes the data to the identity store:
1. Select the "Read Employees" pass and choose New/To Identity store from the context menu and select the "Source" tab:
Modify the pass name in the console tree.
Database
Use the context menu to insert the system parameter %$ddm.identitycenter%.
SQL statement
Enter the SQL statement to select all rows from the table created in the previous pass (SELECT * FROM tutorial_employees;).
2. Select the "Destination" tab:
Identity store
Select the "PrivRoles" identity store.
Entry type
Select the entry type "MX_PERSON".
Definitions
Choose "Insert template" and select "Data source template" to insert the definitions for the pass.
Modify the definition to use the attributes from the entry type. You can use the context menu to find the destination attributes. Give the attribute MSKEYVALUE the EmployeeID values, and add the attribute DISPLAYNAME constructed of employee's first and last name (as shown above).
3. Choose "Apply".
Running the job
Verifying the contents of the identity store
If everything has gone well, the identity store should now contain all entries from the hr.csv file.
Note:
Make sure that the Monitoring web interface is configured for the Identity Center you are using. 1. Start the Monitoring web interface.
Note:
Notice that login to Monitoring is limited to <prefix>_user. This user is by default set to mxmc_user, but can be configured in config.xml (and needs to be configured by those using a database with prefix other than <mxmc>). To configure the login user, insert the
following line into the config.xml file:
<databaseuser>%PREFIX%_user</databaseuser>. 2. Choose "Identity store" in the menu.
3. Select the "PrivRoles" identity store and then "Search" to return all entries in the identity store.
Enabling the delta
We now have two working passes. The next step is to ensure that only modified entries in the data source are written to the identity store. The delta mechanism must be enabled on the "To Identity store" pass (Employees to ID store) of the "Employees to Identity store" job.
1. Select the "Employees to ID store" pass and select the "Delta" tab:
Fill in the fields with the following values:
Enable delta
Select this check box to enable delta on this pass.
Delta database
Use the context menu to insert the system parameter %$ddm.identitycenter% to specify that you want to use the Identity Center database for the delta database.
Delta identifier
Enter Employees_to_IDStore as the delta identifier. This must be unique within one delta database.
Delta key
This is automatically filled in with the value from the first line of the definitions on the "Destination" tab.
Skip unchanged entries and Mark for deletion
Make sure that both "Skip unchanged entries" and "Mark for deletion" are selected. 2. Choose "Apply".
Section 3: Creating the privileges
In this section you will learn how to create privileges. The privileges that need to be created are: PRIV:MainEntrance
PRIV:ServerRoom PRIV:ArchiveRoom PRIV:ProjectArchive
The focus in this tutorial is to show the principles and mechanisms of working with roles and privileges, and not so much on configuration of the external systems. So when a user is given a particular privilege, a file will be created (containing the timestamp of when the privilege was assigned to the user) and provisioned to the respective folder. In a production system, these privileges would create and delete users or grant or revoke access rights in target systems.
Creating folders for privileges
Before creating privileges, create folders where users with the given privilege will be
provisioned to. These folders will function as target repositories for the provisioning data. We create the folder building where the users assigned the privileges PRIV:MainEntrance,
PRIV:ServerRoom and PRIV:ArchiveRoom are provisioned to. And we create the folder project where the users with the privilege PRIV:ProjectArchive are provisioned to.
Go to C:\Tutorial (the directory which we created a global constant for) and create the two folders.
Defining repository definitions for folders
Here we will create repository definitions Building and Project for the two target folders building and project.
To create repository definitions for the folders building and project, do the following: 1. Start the repository wizard by selecting the "Repositories" entry in the console tree, and
choosing New/Repository… from the context menu. 2. Choose "Next".
3. Choose "Next >".
Name the repository definition Building.
4. Choose "Next >", and then "Finish", to insert the new repository definition.
5. Expand the "Building" entry (under Management\Repositories) in the console tree, select "Constants" and choose New/Constant… from the context menu.
Specify the name of the constant and the directory where the target repository (folder) is stored. Use the context menu to insert the constant %$glb.TUTORIAL_PATH%.
6. Choose "OK" to close the dialog box and insert the constant.
7. Repeat the same procedure to define the repository definition for the project folder. Name the repository definition Project and define a constant PATH with the value
Creating the privileges
The target folders and their repository definitions are defined and we can now add the privileges:
1. Select "Identity store metadata\Privileges" under your identity store in the console tree and choose New/Privilege… from the context menu.
Name
Enter the name of the privilege.
Repository
Select the correct repository definition for this privilege. By adding the repository reference to the privilege, you could re-use the tasks for other privileges controlling other folders. 2. Choose "OK" to close the dialog box and insert the new privilege.
3. Repeat the process for privileges PRIV:ServerRoom, PRIV:ArchiveRoom and PRIV:ProjectArchive. For the PRIV:ProjectArchive privilege, select Project in the "Repository" field.
Section 4: Creating the provisioning tasks
In this section, the tasks for provisioning and de-provisioning of users are created. It is also shown how you define these on the repository definitions Building and Project created in previous section. To easily identify the tasks we use the following syntax:
#<Repository name>_<Operation>
For instance:
#Building_Provisioning #Building_Deprovisioning
Before the provisioning tasks are created, the Java script GetMskeyvalueFromPriv used by the provisioning tasks need to be defined.
Creating global Jscript GetMskeyvalueFromPriv
When a user is given a particular privilege, a file will be created (containing the timestamp of when the privilege was assigned to the user) and provisioned to the respective folder. Name of the file has the following naming convention:
<MSKEYVALUE of the provisioned user>-<cleaned MSKEYVALUE of the privilege>.txt
For instance:
3001-PRIV_MainEntrance.txt
Cleaned MSKEYVALUE of the privilege is MSKEYVALUE where the colon (":") is replaced by the underscore ("_") – for MSKEYVALUE "PRIV:MainEntrance" the cleaned
MSKEYVALUE will be "PRIV_MainEntrance". The reason is that it is not possible to use the colon (":") in a file name.
The global Java script GetMskeyvalueFromPriv is used by the provisioning tasks to obtain the cleaned MSKEYVALUE of the privilege assigned to the user.
To create the script, do the following:
1. Go to Management\Global scripts and select "JScript" in the console tree. 2. Choose New/Script… from the context menu.
3. Choose "OK".
Define the following script (you can copy and paste the script defined under and replace the template definition):
// Main function: GetMskeyvalueFromPriv
// --- This function returns the MSKEVALYE for the privilege which caused this task // to execute.
// Some UserFunc.uErrMsg calls are included for debugging. Remove the comment "//" // before these calls to get the information in the log file.
function GetMskeyvalueFromPriv() {
// get audit ID, then changevalues which holds the mskey of the privilege added // then get the value of the attribute MSKEYVALUE for that entry
// --- First get the AuditID which is currently executing AuditID = UserFunc.uGetAuditID();
// UserFunc.uErrMsg(1,"AuditID:"+AuditID);
// --- Then get which values were changed
// This returns "<Attribute name>:<OPERATION>;<New value>!!<Old value>" ChangeValues = UserFunc.uGetChangeValues("!!",AuditID);
Values = temp[1].split("!!");
// UserFunc.uErrMsg(1,"Values (New/Old):"+Values[0]+"/"+Values[1]);
// --- If privilege was deprovisioned, its in Old Value, return [1] Val0len = UserFunc.Len(Values[0]); // UserFunc.uErrMsg(1,"Lenght of Values[0]:"+Val0len); if (Val0len < 1) { PrivAssignedMSKEY = Values[1]; } else { PrivAssignedMSKEY = Values[0]; }
// --- Got MSKEY of privilege, now get the MSKEYVALUE
PrivMSKEYVALUE = UserFunc.uIS_GetValue(PrivAssignedMSKEY,0,"MSKEYVALUE");
// --- Replace : with _ to make it "file-name friendly"
PrivMSKEYVALUEclean = UserFunc.uReplaceString(PrivMSKEYVALUE, ":", "_");
// UserFunc.uErrMsg(1, "Returning MSKEYVALUE:" + PrivMSKEYVALUEclean); return PrivMSKEYVALUEclean;
}
4. Choose "OK" and the global script is added.
Creating the provisioning tasks for the Building
repository definition
Here we create the tasks for provisioning and de-provisioning to the Building repository definition.
Creating a folder for the Building tasks
First create a folder that will be used for the tasks:Note:
When creating a new identity store, a folder "Provisioning folder" is added to the identity store. Instead of creating new folder for provisioning to the Building repository definition, you could also rename the already existing folder.
1. Select the "PrivRoles" identity store and choose New/Folder… from the context menu.
2. Choose "OK". The folder is included in the console tree.
Deselect "Show folder in workflow" as the tasks in this folder should not be displayed in the workflow.
Adding the task #Building_Provisioning
This task will create a file in the building folder. The contents of the file are date and time when the user was provisioned.
Note:
Note that this is given as an example only, and that there are no checks for illegal characters in the file name.
To create the task "#Building_Provisioning":
1. Select the folder you just created and choose New/Action task/Empty job from the context menu.
Rename this task to #Building_Provisioning.
Select the Building repository definition in the "Repository" field. 2. Choose "Apply".
3. Select the job in the console tree:
Modify the job name in the console tree. Modify the job properties:
Enabled
Select this check box to enable the job to be run by a dispatcher.
Run by dispatchers
Select a dispatcher that should be responsible for running this job. 4. Choose "Apply".
5. Select "Script" in the console tree (under the job), then choose New/Link global script and select "GetMskeyvalueFromPriv" to establish the link to the global script
GetMskeyvalueFromPriv.
6. Select the job and choose New/Shell execute to create a pass in the console tree.
In a "Destination" tab add the following line to the definitions (you can use the context menu to insert the constants/attributes/scripts or copy and paste the lines below):
cmd /c echo Privilege assigned %$ddm.date% %$ddm.time% >
Adding the task #Building_Deprovisioning
This task will delete the file created by the #Buildling_Provisioning task. To create the task "#Building_Deprovisioning":
1. Select the folder Building provisioning folder and choose New/Action task/Empty job from the context menu.
Rename this task to #Building_Deprovisioning.
Select the Building repository definition in the "Repository" field. 2. Choose "Apply".
Modify the job name in the console tree. Modify the job properties:
Enabled
Select this check box to enable the job to be run by a dispatcher.
Run by dispatchers
Select a dispatcher that should be responsible for running this job. 4. Choose "Apply".
5. Select "Script" in the console tree (under the job), then choose New/Link global script and select "GetMskeyvalueFromPriv" to establish the link to the global script
GetMskeyvalueFromPriv.
6. Select the job and choose New/Shell execute to create a pass in the console tree.
In a "Destination" tab add the following line to the definitions (you can use the context menu to insert the constants/attributes/scripts or copy and paste the line below):
cmd /c Del "%$rep.PATH%\%MSKEYVALUE%-$FUNCTION.GetMskeyvalueFromPriv(???)$$.txt"
Creating the provisioning tasks for the Project
repository definition
Here we create the tasks for provisioning and de-provisioning to the Project repository definition.
Creating a folder for the Project tasks
First create a folder that will be used for the tasks:1. Select the "PrivRoles" identity store and choose New/Folder… from the context menu.
Enter Project provisioning folder as name for the folder. 2. Choose "OK". The folder is included in the console tree.
Deselect "Show folder in workflow" as the tasks in this folder should not be displayed in the workflow.
Adding the task #Project_Provisioning
This task is similar to the task "#Building_Provisioning" created previously. Thus, we can copy this task from folder Building provisioning folder to Project provisioning folder:
1. Copy the #Building_Provisioning task into the Project provisioning folder:
2. Select the task in the console tree:
Rename this task to #Project_Provisioning.
Select the Project repository definition in the "Repository" field. 3. Choose "Apply".
4. Select the job in the console tree:
Modify the job name in the console tree. Modify the job properties:
Enabled
Select this check box to enable the job to be run by a dispatcher.
Run by dispatchers
Select a dispatcher that should be responsible for running this job. 5. Choose "Apply".
Adding the task #Project_Deprovisioning
This task is similar to the task "#Building_Deprovisioning" created previously. Thus, we can copy this task from folder Building provisioning folder to Project provisioning folder: 1. Copy the #Building_Deprovisioning task into the Project provisioning folder:
2. Select the task in the console tree:
Rename this task to #Project_Deprovisioning.
Select the Project repository definition in the "Repository" field. 3. Choose "Apply".
4. Select the job in the console tree:
Modify the job name in the console tree. Modify the job properties:
Enabled
Select this check box to enable the job to be run by a dispatcher.
Run by dispatchers
Select a dispatcher that should be responsible for running this job. 5. Choose "Apply".
Testing the tasks
You are now ready to test the tasks created: #Building_Provisioning
#Building_Deprovisioning #Project_Provisioning #Project_Deprovisioning
Note:
Make sure that the dispatcher is running. You should also make sure to first test the tasks #Building_Provisioning and #Project_Provisioning, before testing the tasks
#Building_Deprovisioning and #Project_Deprovisioning. This makes it easier to observe that files first are added and then removed from their respective target folders. Also make sure to use the same MSKEYVALUE when testing the provisioning and de-provisioning tasks.
First, you need to find the MSKEYVALUE of an entry in the identity store that we can use for the test. We have already assigned the employee ID to the MSKEYVALUE and you can use any of these.
Test the task:
1. Select the "#Building_Provisioning" task in the console tree and choose "Test provisioning task…" from the context menu:
Enter the MSKEYVALUE of one of the entries in the identity store. 2. Choose "OK".
View the contents of the folder to verify that the entry has been created.
Following the same procedures, you can now test the tasks #Building_Deprovisioning, #Project_Provisioning and #Project_Deprovisioning.
Troubleshooting
If any problems should occur during the execution, you can check some of the following: Verify that the dispatcher is running and that it is enabled for provisioning jobs. Verify that all tasks and jobs are enabled.
Verify that the job has been defined for the given dispatcher. View the logs.
System log
Verify that the dispatcher has requested the given job. Job log
View any error messages in the job log to see if you can find the cause of the problem. If you need to investigate a job more thoroughly, you can specify a different log file name for the job in the "Logging" tab of the job properties. You can also deselect the check box "Reset output file" to avoid overwriting the log file each time the job is run. This can be useful when debugging a provisioning job that may be run several times in sequence. If you need more logging info from a specific job, you can create a specific dispatcher and increase the log level in the dispatcher's .prop file. Specify that the job is to be run by this specific dispatcher. Make sure that the dispatcher is not running. To run the job, start the dispatcher from the command line with the following command:
dispatcher_service_<dispatcher name> test runonce
Defining tasks on the repository definitions
In this section we add links to the provisioning and de-provisioning tasks on the repository definitions Building and Project.
Defining tasks on the repository definition Building
To define links on the repository definition Building, do the following:1. View the constants of the Building repository definition under "Repositories" in the console tree.
2. Before creating the constant MX_PROVISIONTASK, which will reference the
provisioning task from the repository definition, make sure that you have the correct Task ID for the provisioning task #Building_Provisioning.
Note:
Task ID is displayed in the "Task ID/Name" field of the task's "Options" tab, as shown in picture below (circled in with red).
3. Select "Constants" in the console tree and choose New/Constant… from the context menu.
Enter "MX_PROVISIONTASK" as the name of the repository constant (the name of the constant must be MX_PROVISIONTASK with the exact same casing). Enter the correct Task ID for the provisioning task "#Building_Provisioning", in this case "1".
4. Choose "OK" to add the new constant to the repository definition.
5. Following the same procedure, add the repository constant "MX_DEPROVISIONTASK" (the name of the constant must be MX_DEPROVISIONTASK with the exact same casing) with its correct value (here "3"). This will define a link to the de-provisioning task
Now we have defined links to the provisioning and de-provisioning tasks on the Building repository definition.
Defining tasks on the repository definition Project
To define the provisioning and de-provisioning tasks on the repository definition Project, follow the same procedure as for the repository definition Building described above.
Section 5: Creating the Workflow tasks
To be able to define and manage roles and role assignments through the Workflow interface, the necessary tasks must be created. We will create the following five Workflow tasks:
Create role – task is used to create new roles.
Edit role properties – this task is used to edit role hierarchy by adding child roles and privileges to a role. The task is also used to change role name and it is possible to add a short description of the role.
Assign role – task is used to add members to a role. Delete role – this task deletes the role.
Edit privilege properties – this task is primarily used to edit privilege inheritance direction. It is also possible to add/remove role references and add a short description of the privilege.
Creating the folder
Before creating the Workflow tasks, create a separate folder for them:
1. Select the "PrivRoles" identity store in the console tree and choose New/Folder… from the context menu.
Enter "Workflow" as name for the folder. 2. Choose "OK".
Select "Automatically expand folder" to specify that the tasks in this folder are automatically displayed when you log on to the Workflow interface.
3. Choose "Apply".
Adding the Workflow tasks
The folder is now created and the next step is to create the Workflow tasks.
Adding the "Create role" task
To define the task Create role, do the following:1. Select the "Workflow" folder and choose New/Unordered task group from the context menu.
Modify the task name in the console tree. Select "Show on welcome page".
2. Select the "Attributes" tab:
Select "MX_ROLE" as entry type and configure the attributes for the task as displayed above.
Select "This task creates a new entry". 3. Choose "Apply".
Enter the name of the identity store user you added previously (admin). You might use "Check name" to ensure that the name you entered is correct and exists. This allows the "admin" user to create new roles.
5. Choose "OK".
The resulting access control is displayed in the details pane:
Adding the "Edit role properties" task
The task Edit role properties is used to add child roles and privileges to a role. The task is also used to change role name and it is possible to add a short description of the role.
To define task Edit role properties, do the following:
1. Select the "Workflow" folder and choose New/Unordered task group from the context menu.
Modify the task name in the console tree. Select "Show on welcome page".
2. Select the "Attributes" tab:
Select "MX_ROLE" as entry type and configure the attributes for the task as displayed above.
3. Choose "Apply".
4. Select the "Access control" tab and define access for the admin user as done for the previous task (Create role).
Adding the "Assign role" task
The task Assign role is used to add members to a role. To define task Assign role, do the following:
1. Select the "Workflow" folder and choose New/Unordered task group from the context menu.
Modify the task name in the console tree. Select "Show on welcome page".
Select "MX_PERSON" as entry type and configure the attributes for the task as displayed above. Selecting "List in search result" for the DISPLAYNAME attribute will result in person's name showing in Workflow search list, in addition to MSKEYVALUE (which is the employee ID).
3. Choose "Apply".
4. Select the "Access control" tab and define access for the admin user as done for the previous tasks.
5. Choose "Apply".
Adding the "Delete role" task
To define task Delete role, do the following:1. Select the "Workflow" folder and choose New/Unordered task group from the context menu.
Modify the task name in the console tree. Select "Show on welcome page".
2. Select the "Attributes" tab:
Select "MX_ROLE" as entry type and configure the attributes for the task as displayed above.
3. Choose "Apply".
4. Select the "Access control" tab and define access for the admin user as done for the previous tasks.
5. Choose "Apply".
To be able to actually delete a role, it is necessary to create a separate action task and job for doing this.
6. Select the task and choose New/Action task/Empty job from the context menu.
The task and the job are inserted in the console tree. 7. Select the job in the console tree:
Enable the job and select the dispatcher to run the job. 8. Choose "Apply".
9. Select the job and choose New/To Identity store from the context menu.
In the "Destination" tab do the following:
Select "-- Self --" in the "Identity store" field. This is to optimize the export/import. Select the MX_ROLE entry type in the "Entry type" field.
Modify the definitions as shown above (add MSKEYVALUE and changeType). Use the context menu to insert these.
Adding the "Edit privilege properties" task
The last of the five Workflow tasks that we create in this tutorial is the "Edit privilege
properties" task. It is primarily used to edit privilege inheritance direction, but it is also possible to add/remove role references and add a short description of the privilege.
To define task Edit privilege properties, do the following:
1. Select the "Workflow" folder and choose New/Unordered task group from the context menu.
Modify the task name in the console tree. Select "Show on welcome page".
2. Select the "Attributes" tab:
Select "MX_PRIVILEGE" as entry type and configure the attributes for the task as displayed above.
3. Choose "Apply".
4. Select the "Access control" tab and define access for the admin user as done for the previous tasks.
5. Choose "Apply".
All Workflow tasks are now created. The next step is to create the roles using the Workflow user interface.
Section 6: Creating the roles
You can now create roles using the Workflow tasks. The following roles will be created: ROLE:Employee ROLE:IT ROLE:Adm ROLE:Manager ROLE:Tester ROLE:TestLeader ROLE:Developer ROLE:HeadDeveloper ROLE:Doc ROLE:ProjectLeader
Starting the Workflow web interface
Note:
Make sure the Workflow web interface is configured for the Identity Center you are using. We will now start the Workflow web interface:
1. Start the Workflow web interface from the "Start" menu (All Programs/SAP NetWeaver Identity Management/Identity Center Workflow).
2. Choose "Login" in the menu to the left.
3. Choose "Login".
Creating the roles
In Workflow web interface, create the role ROLE:Employee and the rest of the roles mentioned above:
1. Choose "Create role" in the list of available tasks.
Enter "ROLE:Employee" as role's unique ID (and a short description of a role if you wish). 2. Choose "OK" to create a role. You return to a task list. When the task completes
successfully, the progress indicator turns green.
Note:
You might have to press the "Refresh" button before the progress indicator turns green. If the indicator still doesn't turn green, check that your dispatcher is running.
In the Identity Center user interface (Identity store metadata\Roles), you can observe the roles you just created:
Section 7 Use case Physical access control
This use case models a workplace (building) where users (employees) are given access rights to building areas based on their job-role. In this use case, you will learn how to use the created Workflow tasks to do the following:
Build the role hierarchy:
Add the link between the roles and the privileges.
Assign roles, and thereby privileges, to the identity store entries. In previous sections, you have created both privileges and roles needed.
Building the role hierarchy
To build the role hierarchy for the Physical access control use case, do the following: 1. In Workflow web interface, choose "Edit role properties" in the list of available tasks:
2. Choose "Search".
3. Select the role "ROLE:Adm".
4. Choose "…" to define child roles.
6. Choose the "Add" button to the left of ROLE:Employee to add the role to the child role list.
9. Repeat the steps for other roles to complete the hierarchy:
Role name Defined child roles
ROLE:IT ROLE:Employee
ROLE:Manager ROLE:Adm, ROLE:IT
In the Identity Center (Identity store metadata\Roles), you can observe the role hierarchy you just built:
Adding the privileges
To add privileges to the roles, do the following:
1. Choose "Edit role properties" in the list of available tasks and select "ROLE:Employee" from the list of available roles:
3. Choose the "Add" button to the left of the privilege PRIV:MainEntrance.
4. Choose "OK".
The privilege PRIV:MainEntrance is added to the role ROLE:Employee.
5. Choose "OK" to confirm and complete the task. You return to a task list. When the task completes successfully, the progress indicator turns green.
6. Repeat the steps for other roles:
To the ROLE:IT role, add the privilege PRIV:ServerRoom To the ROLE:Adm role, add the privilege PRIV:ArchiveRoom
Assigning roles/privileges to identity store entries
The necessary tasks and mechanisms are implemented and ready. We can now assign roles and privileges to, and remove those from the entries in the identity store (provisioning and de-provisioning).
Provisioning to building folder
Assigning roles ROLE:Employee, ROLE:IT, ROLE:Adm or ROLE:Manager to users, will result in provisioning to the building folder. To assign roles and privileges, do the following:
1. In Workflow web interface, choose "Assign role" from the list of available tasks.
2. Choose "Search" to list all identity store entries. They are listed with their MSKEYVALUE and display name.
3. Find and select "3001".
5. Add the role "ROLE:Employee".
6. Choose "OK".
7. Choose "OK" to complete the task and assign the role. You return to a task list. When the task completes successfully, the progress indicator turns green.
Now you can open the building folder and observe that the user "3001" is given the privilege PRIV:MainEntrance and provisioned to the folder.
8. Repeat the process for the other roles provisioning to the building folder: Entry "3002" ROLE:IT
Entry "3003" ROLE:Adm Entry "3004" ROLE:Manager The result is the following:
Entry "3002" has two privileges – PRIV:ServerRoom from the role ROLE:IT and PRIV:MainEntrance inherited from the role ROLE:Employee.
Entry "3003" has two privileges – PRIV:ArchiveRoom from the role ROLE:Adm and PRIV:MainEntrance inherited form the role ROLE:Employee.
Entry "3004" has three privileges all inherited from the roles lower in the hierarchy – PRIV:MainEntrance inherited from the role ROLE:Employee, PRIV:ServerRoom inherited from the role ROLE:IT and PRIV:ArchiveRoom inherited from the role ROLE:Adm. This will provision entries to the building folder:
De-provisioning from building folder
Removing the assigned role(s) from the user, and thus removing the (inherited) privilege(s), will result in de-provisioning from the building folder. To remove assigned role(s), do the following: 1. In Workflow web interface, choose "Assign role" from the list of available tasks.
2. Select one of the entries you previously assigned a role to, entry "3001" for instance.
3. Choose "…" to change the role membership.
Choose "Search" under the "Assignments" (on the right side of the pane) to list all roles this entry already is a member of.
4. Remove the role ROLE:Employee (choose to do so).
5. Choose "OK".
Now open the building folder and observe that the user was de-provisioned (removed) from the folder.
Section 8: Use case Project resources
This use case models a typical development project group, where all group members are given access to the resources needed for the project. The use case introduces reverse privilege inheritance direction (top-down inheritance direction) – you learn the difference between the bottom-up and top-down inheritance direction of the privileges and how to implement reverse inheritance.
Direction of the privilege inheritance
The privileges are by default inherited upwards in the hierarchy, from the roles lower in the hierarchy (bottom-up). But it is also possible for privileges to be inherited top-down (reverse). The use case Physical access control, with its roles ROLE:Manager, ROLE:IT, ROLE:Adm and ROLE:Employee and the privileges PRIV:MainEntrance, PRIV:ServerRoom, and
PRIV:ArchiveRoom, illustrates the normal privilege inheritance direction (bottom-up). The role ROLE:Manager inherits privileges from its child roles, so the members of this role will have all the three privileges mentioned.
The use case Project resources, however, illustrates the reverse privilege inheritance direction (top-down). The privilege PRIV:ProjectArchive, assigned to the role ROLE:ProjectLeader, will be inherited downwards by all the child roles in the tree until every role member has the
Building the role hierarchy
Using the Workflow tasks build the role hierarchy for this use case:
Use the same procedure as when building the role hierarchy for the use case Physical access control, shown on page 66.
Adding the privilege and implementing the reverse
inheritance direction
Since the bottom-up privilege inheritance direction is default, it means that we need to make an explicit change to the privilege inheritance properties after adding a privilege to a role, to obtain the reverse privilege inheritance.
To add the privilege PRIV:ProjectArchive to the role ROLE:ProjectLeader and implement the reverse inheritance, do the following:
1. In Workflow web interface, choose "Edit privilege properties" from the list of available tasks.
2. Choose "Search" to list all privileges available.
4. Choose "…" to define role with reverse inheritance and choose "Search" to list all roles available.
6. Choose "OK".
7. Choose "OK" to confirm and complete the task. You return to a task list. When the task completes successfully, the progress indicator turns green.
Now you have implemented the reverse inheritance direction of the privilege PRIV:ProjectArchive.
Provisioning to project folder
Assigning any of the roles ROLE:Tester, ROLE:TestLeader, ROLE:Developer,
ROLE:HeadDeveloper, ROLE:Doc or ROLE:ProjectLeader to users, will result in provisioning to the project folder. Assigning any of these roles to users will give the user the privilege PRIV:ProjectArchive.
Do the following assignments: Entry "3005" ROLE:Tester Entry "3006" ROLE:TestLeader Entry "3007" ROLE:Developer Entry "3008" ROLE:HeadDeveloper Entry "3009" ROLE:Doc Entry "3010" ROLE:ProjectLeader
Section 9: Deleting roles
To delete role, you must:1. In Workflow web interface, choose "Delete role" from the list of available tasks.
2. Select the role "ROLE:ProjectLeader" (you can select any role to delete, but here we select the role "ROLE:ProjectLeader").
3. Choose "OK" to confirm and complete the task which will delete the role. You return to a task list.
Deleting the role ROLE:ProjectLeader will also delete the privilege given to the role. This results in de-provisioning of all users that lost the privilege (all users that were added in the previous section):
