Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model-Lecture

Transcription

1 Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model-Lecture NIQ21 Novell Training Services ATT LIVE 2012 LAS VEGAS

2 Legal Notices Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc., reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes. Any products or technical information provided under this Agreement may be subject to U.S. export controls and the trade laws of other countries. You agree to comply with all export control regulations and to obtain any required licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws. You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the Novell International Trade Services Web page ( for more information on exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export approvals. Copyright 2012 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher. Novell, Inc., has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed on the Novell Legal Patents Web page ( and one or more additional patents or pending patent applications in the U.S. and in other countries. Novell, Inc. 404 Wyman Street, Suite 500 Waltham, MA U.S.A. Online Documentation: To access the latest online documentation for this and other Novell products, see the Novell Documentation Web page ( Novell Trademarks For Novell trademarks, see the Novell Trademark and Service Mark list ( Third-Party Materials All third-party trademarks are the property of their respective owners. 2

3 Contents SECTION 1 Security: Roles and Permissions 5 Objective 1 Benefits and Model Overview 6 Objective 2 The Model 10 Objective 3 Domains 13 Objective 4 Domain Administrators 19 Objective 5 Teams and Proxy 22 Objective 6 Navigation Access 27 Objective 7 Examples 31 Exercises SECTION 2 Entitlements Creation to Implementation 37 Objective 1 What is an Entitlement 38 Objective 2 Entitlements Schema 43 Objective 3 Entitlements Design 45 SECTION 3 Resource Model 49 Objective 1 Resource Model 50 Objective 2 Creating Resources 55 Objective 3 Assigning Resources 63 Objective 4 Role Mapping Administrator 65 Exercises

4 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture 4

5 Security: Roles and Permissions SECTION 1 Security: Roles and Permissions The following will be covered: 1. Benefits and Model Overview on page 6 2. The Model on page Domains on page Domain Administrators on page Teams and Proxy on page Navigation Access on page Examples on page 31 5

6 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Objective 1 Benefits and Model Overview 6

7 Security: Roles and Permissions SLIDE: User Application User Types The Domain Administrator is an administrator who has the full range of capabilities within a particular domain, which gives a user assigned to be this type of administrator the ability to perform all operations on all objects within the domain for all users. 7

8 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture The Domain Manager is a delegated administrator who has the ability to perform selected operations for a subset of authorized objects within the domain for all users. The Team Manager is a business line manager who can perform selected operations for a subset of authorized objects within the domain, but only for a designated set of users (team members). Designers use the Designer for Identity Manager to customize the User Application for your enterprise. Designer is a tool aimed at information technology professionals such as enterprise IT developers, consultants, sales engineers, architects or system designers, and system administrators who have a strong understanding of directories, databases, and their information environment and who act in the role of a designer or architect of identity-based solutions. To create or edit or edit workflow objects in Designer, the user needs the following rights on the RequestDefs.AppConfig container for the specific User Application driver. [Entry Rights] Supervisor or Create. [All Attribute Rights] Supervisor or Write. To initiate a workflow, the user must have Browse [Entry Rights] on the RequestDefs.AppConfig container for the specific User Application driver or individually per request definition object if you are using a delegated model. Business users interact with the User Application s Identity Self-Service, Work Dashboard, and Roles and Resources tabs. A business user can be: An authenticated user (such as an employee, a manager, or a delegate or proxy for an employee or manager). A delegate user is a user to whom one or more specific tasks (appropriate to that user s rights) can be delegated, so that the delegates can work on those specific tasks on behalf of someone else. A proxy user is an end user who acts in the role of another user by temporarily assuming that user s identity. All of the rights of the original user apply to the proxy. Work owned by the original user continues to be owned by that user. An anonymous or guest user. The anonymous user can be either the public LDAP guest account or a special account set up in your Identity Vault. The User Application Administrator can enable anonymous access to some features of the Identity Self-Service tab (such as a search or create request). In addition, the User Application Administrator can create pages that allow the user to request a resource. The user s capabilities within the User Application depend on what features the User Application Administrator has enabled for them. They can be configured to: View hierarchical relationships between User objects by using the Org Chart portlet. View and edit user information (with appropriate rights). 8

9 Security: Roles and Permissions Search for users or resources using advanced search criteria (which can be saved for later reuse). Recover forgotten passwords. The User Application can be configured so that users can: Request a resource (start one of potentially many predefined workflows). View the status of previous requests. Claim tasks and view task lists (by resource, recipient, or other characteristics). View proxy assignments. View delegate assignments. Specify one s availability. Enter proxy mode in order to claim tasks on behalf of another. View team tasks, request team resources, and so forth. 9

10 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Objective 2 The Model The Roles Based Provisioning Module uses a security model that recognizes three general categories of administrators and managers. SLIDE: The Model; The Domain Administrator is an administrator who has the full range of capabilities within a particular domain, which gives a user assigned to be this type of administrator the ability to perform all operations on all objects within the domain for all users. The Domain Manager is a delegated administrator who has the ability to perform selected operations for a subset of authorized objects within the domain for all users. The Team Manager is a business line manager who can perform selected operations for a subset of authorized objects within the domain, but only for a designated set of users (team members). 10

11 Security: Roles and Permissions Domain Administrators and Domain Managers are designated through system role assignments. The Roles Based Provisioning Module allows you to assign users to any of the following system roles: Table 1-1 System Roles for Domain Administrators and Domain Managers Role Compliance Administrator Configuration Administrator Description A Domain Administrator who has the full range of capabilities within the Compliance domain. The Compliance Administrator can perform all possible actions for all objects within the Compliance domain. A Domain Administrator who has the full range of capabilities within the Configuration domain. The Configuration Administrator can perform all possible actions on all objects within the Configuration domain. The Configuration Administrator controls access to navigation items with the Roles Based Provisioning Module. In addition, the Configuration Administrator configures the delegation and proxy service, the digital signature service, the provisioning user interface, and the workflow engine. 11

12 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Role Provisioning Administrator Provisioning Manager Resource Administrator Resource Manager Role Administrator Role Manager Security Administrator Description A Domain Administrator who has the full range of capabilities within the Provisioning domain. The Provisioning Administrator can perform all possible actions for all objects within the Provisioning domain. A Domain Manager who can perform only allowed actions for a subset of objects within the Provisioning domain. A Domain Administrator who has the full range of capabilities within the Report domain. The Report Administrator can perform all possible actions for all objects within the Reports domain. A Domain Manager who can perform only allowed actions for a subset of objects within the Resource domain. A Domain Administrator who has nearly the full range of capabilities within the Role domain. The Role Administrator can perform all possible actions for all objects (except for the System Roles) within the Role domain.d A Domain Manager who can perform only allowed actions for a subset of objects within the Role domain. A Domain Administrator who has the full range of capabilities within the Security domain. The Security Administrator can perform all possible actions for all objects within the Security domain. The Security domain allows the Security Administrator to configure access permissions for all objects in all domains within the Roles Based Provisioning Module. The Security Administrator can configure teams, and also assign domain administrators, delegated administrators, and other Security Administrators. These roles are assigned through the Administrator Assignments user interface on the Administration tab. During the installation a unique user identity (administrative account) can be provided for each role but it is recommended that during the install only one account is setup as the administrator for everything and then after delegate specific to users. 12

13 Security: Roles and Permissions Objective 3 Domains SLIDE: Security Domain SLIDE: Provisioning Domain 13

14 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Permission Initiate PRD Description Allows the user to initiate the selected provisioning requests. NOTE: The Initiate PRD permission has no effect on the behavior of the Novellinstalled PRDs for resources, roles, and attestation within the User Application, since these PRDs cannot be initiated directly from the User Application. However, this permission does control whether these PRDs can be initiated from a SOAP call. Retract PRD View Running PRD Configure Delegate Manage Addressee Task Allows the user to retract the selected provisioning requests when they are in progress. Allows the user to view the selected provisioning requests when they are in progress. Allows the user to configure delegate assignments for the selected provisioning requests. Allows the user to manage tasks associated with the selected provisioning requests that have been addressed to other users. When this permission is enabled, Domain and Delegated Administrators can manage tasks for all users, including addressees and recipients. Team Managers are able to manage tasks for addressees, but not for recipients. Configure Availability Allows the user to configure availability for tasks associated with the selected provisioning requests. SLIDE: Configuration Domain 14

15 Security: Roles and Permissions Table 1-2 User Access to the Team Configuration Page User Security Administrator Other Domain Administrators Team Manager Capabilities Can perform all operations on the Team Configuration page. Can define a team for the domain over which the administrator has authority. Can view a team definition for which he/she is configured to be the manager. When a team manager edits a team, the team definition itself is read-only, because the team manager cannot modify the team configuration. The members of a team can be specified individually as a set of users, groups, or containers, or can be defined based on a business relationship, such as the Manager- Employee relationship. Alternatively, the team member list can include all users within the container. SLIDE: Resource Domain Permission Create Resource Description Allows the user to create resources. This permission is hidden when a particular resource is selected. 15

16 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Permission Delete Resource Update Resource View Resource Assign Resource Revoke Resource Report On Resource Description Allows the user to delete the selected resources. Allows the user to update the selected resources. Allows the user to view the selected resources. Allows the user to assign users to the selected resources. Allows the user to revoke user assignments for the selected resources. Allows the user to generate reports that provide information about the selected resources. SLIDE: Role Domain Permission Create Role Description Allows the user to create roles. This permission is hidden when a particular role is selected. 16

17 Security: Roles and Permissions Permission Delete Role Description Allows the user to delete the selected roles. This setting applies only at the container level. At installation time, no user has the ability to delete system roles. However, the administrator may grant user access to the system roles. The permission to delete roles should not be given for the RoleConfig, Level20, and System roles containers. Also, in general, you should not set permissions on those containers, because permissions on these containers will be propagated to the system roles. Instead, you should create role subcontainers under the role level container and set permissions on each subcontainer. Update Role and Role Relationship Allows the user to update the selected roles and modify role relationships. This setting applies only at the container level. View Role Allows the user to view the selected roles. This setting applies only at the container level. Assign Role To User Allows the user to assign users to the selected roles. IMPORTANT: Only the Security Administrator can assign system roles on the Work Dashboard tab and the Roles and Resources tab. Revoke Role From User Assign Role To Group And Container Revoke Role From Group And Container Report On Role Allows the user to revoke user assignments for the selected roles. Allows user to assign groups and containers to the selected roles. Allows the user to revoke group and container assignments for the selected roles. Allows the user to generate reports that provide information about the selected roles. Permission Create SoD Description Allows the user to create separation of duties constraints. This permission is hidden when a particular SoD constraint is selected. Update SoD Allows the user to update the selected separation of duties constraints. 17

18 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Permission Delete SoD View SoD Report On SoD Description Allows the user to delete the selected separation of duties constraints. Allows the user to look at the selected separation of duties constraints. Allows the user to generate reports that provide information about the selected separation of duties constraints. SLIDE: Compliance Domain 18

19 Security: Roles and Permissions Objective 4 Domain Administrators Domain Administrators and Domain Managers are authorized to perform provisioning and security tasks for the Identity Manager User Application. SLIDE: Domains The domain determines what types of objects the administrator can act on. An administrator assignment can only be associated with a single domain. Compliance Configuration Provisioning Resource Role Security 19

20 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture SLIDE: Domain Permissions When the All Permissions checkbox is checked, the assignment creates a Domain Administrator. When it is unchecked, the assignment creates a Delegated Administrator. When the domain selected is Security, Configuration, or Compliance, the assignment automatically gives full permissions for the selected domain, and the All Permissions checkbox is not displayed. SLIDE: Assign To? The label for the control, and the objects available for selection, vary according to the type of assignment you ve specified. User Group 20

21 Security: Roles and Permissions Container Role SLIDE: Role Administrator View SLIDE: Role Manager View 21

22 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Objective 5 Teams and Proxy The team managers are those users who can administer requests and tasks for the team. Team managers can also be given permission to set proxies and delegates for team members. Team managers can be users or groups. The team members are those users who are allowed to participate on the team. Team members can be users, groups, or containers within the directory. Alternatively, they can be derived through directory relationships. For example, the list of members could be derived by the manager-employee relationship within the organization. In this case, the team members would be all users that report to the team manager. NOTE: The Provisioning Application Administrator can configure the directory abstraction layer to support cascading relationships, in which case several levels within an organization may be included within a team. The number of levels to include is configurable by the administrator. The team options determine whether the provisioning request scope, which specifies whether the team can act on an individual provisioning request, one or more categories of requests, or all requests. The team options also determine whether team managers can set proxies for team members and/or set the availability of team members for the purpose of delegation. 22

23 Security: Roles and Permissions NOTE: Note: The Team Owner can only view their team. They can not modify the team. Unless they happen to be an Administrator for the Domain in which the team is create in or are a Security Administrator SLIDE: Team Configuration 23

24 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture The Team Configuration page allows you to create teams and define permissions for these teams. A team definition specifies a domain type (Provisioning, Role, or Resource), as well as a set of team members and managers. The Team Configuration page is accessible to the following users: SLIDE: Team Domains The domain determines what types of objects the team members can act on. A team can only be associated with a single domain. Provisioning Domain Role Domain Resource Domain NOTE: If a particular user has been designated as a domain administrator, Novell recommends that this user should not also be designated as a manager of a team for the same domain for which the user is a domain administrator. SLIDE: Team Managers and Members 24

25 Security: Roles and Permissions The managers for a team can be a one or more users or groups. When you define a team, you can specify whether you want the team managers to also be members of the team. The members of a team can be specified individually as a set of users, groups, or containers, or can be defined based on a business relationship, such as the Manager- Employee relationship. Alternatively, the team member list can include all users within the container. SLIDE: Team Provisioning Domain Permissions The permissions for a team define the actions that team members can take on a particular scope of object instances within the domain type selected for a team. For example, if you select the Role domain as the domain type for a team, the team permissions determine what actions the members can take on the set of role instances selected as the scope for the team. These permission might specify, for the selected scope of roles, that members can perform actions such as assigning roles to users, viewing role assignments, and reporting on role assignments. 25

26 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture SLIDE: Team Resource Domain Permissions SLIDE: Team Role Domain Permissions 26

27 Security: Roles and Permissions Objective 6 Navigation Access The Navigation Access Permissions page allows you to set the access permissions for some of the navigation items within the User Application. It allows you to control access to three of the main header tabs with the application: Roles & Resources tab, Identity Self-Service tab, and Work Dashboard tab. In addition, it allows you to define permissions for lower-level navigation items within the Provisioning & Security, Roles & Resources, and Work Dashboard areas of the application. 27

28 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture NOTE: The Compliance and Administration tabs cannot be configured through the Navigation Access Permissions page. The Compliance tab is only visible to Compliance Administrators, and the Administration tab is only visible to Security Administrators, Domain Administrators (such as the Role Domain Administrator and Resource Domain Administrator), and Configuration Administrators. 28

29 Security: Roles and Permissions Make a Process Request By default, the Make a Process Request navigation item is shown on the Work Dashboard. To hide the Make a Process Request item, remove all trustees for this item. If you remove all trustees, only Configuration Administrators will be able to see the item. To show the Make a Process Request item on the Work Dashboard again, select Make a Process Request and choose the users, groups, roles, or containers that you want to be able to access the item. NOTE: If a user does not have access to the default tab (or to the default menu item within a navigation area), the User Application will attempt to display a tab (or menu item) for which the user has authorization. If the user has not been given authorization for any tab or menu item, the default page will display. If the user is not authorized for the default page, or if the user goes directly to an unauthorized bookmark, an error message is displayed indicating that the user does not have the proper authorization. If the user has been authorized to access a tab, but nothing under the tab, the page will still show and an error message will be displayed indicating that the user does not have the proper authorization. Conversely, if the tab has not been authorized, the tab will not show. However, if the user is authorized to access menu items under the tab, the user will be able to access these menu items by using bookmarks. Proxy Mode When a user is in proxy mode, the navigation access permissions for menu items on the Dashboard will show the proxied user's permissions, not the permissions for the logged in user. For all other navigation, the menu items will be controlled by the permissions set for the logged in user. The Manage control (for selecting a user, group, role, or container) is not available in proxy mode, even if a user is proxying for a user that is a Domain Administrator or Domain Manager. The navigation items for which you can define permissions are shown the navigation areas appear in bold. SLIDE: Example: Identity Self-Service Access When a user with trustee rights logs on to the User Application, the navigation item is displayed. Otherwise, the navigation item is hidden. You can add users, groups, roles, and containers as trustees 29

30 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture 30

31 Security: Roles and Permissions Objective 7 Examples In this section you will look at some case for security requirements followed by the solution to meet the specified requirements. This will give you some idea of the flexibility of the new security model of the Roles Based Provisioning Model. 31

32 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture 32

33 Security: Roles and Permissions 33

34 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture 34

35 Security: Roles and Permissions Exercises Proceed with exercise How to Define Navigation Access Permissions in Lab Manual for the course. 35

36 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Proceed with exercise Assign Security and Create Teams in Lab Manual for the course. 36

37 Entitlements Creation to Implementation SECTION 2 Entitlements Creation to Implementation Identity Manager allows you to synchronize data between connected systems. Entitlements allow you to set up criteria for a person or group that, once met, initiate an event to grant or revoke access to business resources within the connected system. This gives you one more level of control and automation for granting and revoking resources. The following will be covered: 1. What is an Entitlement on page Entitlements Schema on page Entitlements Design on page 45 37

38 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Objective 1 What is an Entitlement You must know beforehand what you want to accomplish with entitlements. Entitlements work from the functionality you build into Identity Manager drivers through policies. These driver policies implement rules and process the events between the Identity Vault and the connected system. If the policies in the Identity Manager driver do not specify what you want to do, entitlements cannot work. For example, if you don t specify the action section of the Check User Modify for Group Membership rule in the Command policy, attempts to grant or revoke a group membership entitlement are ignored. 38

39 Entitlements Creation to Implementation SLIDE: Entitlements Business Case Example: PBX System allows office phone to be forwarded to cell phone if an attribute is set to true and cell phone number provided in another attribute Want to allow employees who have cell phone and are out of office often the ability to have this feature turned on but must have manager approval Programmer Solution Add entitlement object for cell phone forwarding to PBX driver Implement policy in subscriber channel of PBX driver to set attribute to true in PBX and copy the cell phone from vault into PBX attribute when entitlement granted Implement policy to undo above changes if entitlement revoked Administrator Solution Create a workflow to allow employees to request the service and managers to approve Create a workflow to allow employee to remove the request without manager approval 39

40 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Entitlements can be granted based upon a criteria or based upon a action of a user. In this example above, some users might have multiple Entitlements and some might have none. This all depends upon how the administrator has configured the IDM 3.6 drivers for Entitlements. Some tasks might be done with standard policy and some tasks will be done with an Entitlement. Entitlements cannot be managed in any way with imanager. It all has to be done with Designer. After you add an Identity Manager driver to an Identity Vault in the Designer modeler, you can right-click on the driver from the Outline View and select Add Entitlement. You are prompted through the Entitlement Wizard to designate the type of entitlement you want, and the wizard then steps you through the creation process. Not all Identity Manager Drivers come with pre-configured Entitlements on the driver. The list above is what has been pre-configured. This however does not limit you. You can create your own custom implementations of Entitlements on any driver. 40

41 Entitlements Creation to Implementation Figure 2-1Entitlement Types There are two types of Entitlements that can be used and configured. Entitlements can be either Valueless or Valued. The Valueless Entitlement is like a question with a yes or no answer. For example, Does this user get an account in Active Directory? (Yes, No). If they meet the criteria they get an Active Directory account. The Entitlement does not have to query the application to make this happen with a Valueless Entitlement. The second Entitlement is Valued. This is where the Entitlement has to make a query into the connected to system to apply the Entitlement. For example, let s say we have two groups in Active Directory called Internet Access and Managers. A user has to be a member of BOTH groups to get Internet access. If we want to grant the Entitlement in the IDM 3.5 system we will need to be able to assign the user to those Active Directory groups if they meet the criteria. How the criteria is set will be discussed during the slide at SLIDE: Entitlement Service Drivers on page

42 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Each agent can manage any Entitlement, so theoretically, multiple agents can manage the same entitlement. However, the agents don't know about each other, so there is no sort of priority of one agent over another. You could attempt to manage this priority with ACLs, but that would get very complicated. As a result, managing one entitlement with more than one agent is not supported. A better idea is to create additional entitlements, and manage the state through policy. 42

43 Entitlements Creation to Implementation Objective 2 Entitlements Schema During the install of Identity Manager we extended edirectory's schema for the Entitlement class. There is also a DirXML-EntitlementReceipient Aux class that has been extended and attributes added to this Auxiliary class. These attributes are very important. The attribute DiRXMLEntitlementRef keeps track of the Entitlement that the user has been granted or revoked. If you look in imonitor you can see how this is stored. SLIDE: Entitlement Attribute Example - imonitor View imonitor is the best tool to use to see the DirXML-EntitlementRef attribute. You can see in this slide example the Entitlement and the time that it was granted. You can also see when the Entitlement has been revoked. Using the imanager other tab does not quite show you the Entitlement effectively. 43

44 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture SLIDE: Entitlement Attribute Example - imanager View In the imanager view it allows you to delete the entitlement. 44

45 Entitlements Creation to Implementation Objective 3 Entitlements Design You need to know precisely what you want to accomplish with Identity Manager, then you can correctly design granting and revoking capabilities for any connected system resources. The following four-step procedure can help you plan to create and use entitlements: 1. Know what you want to accomplish in your business situation. You can design and implement almost anything through Identity Manager, but you need to know what you want to do before implementing something that isn t defined. Make a numbered list of what you want to do. 2. Define an entitlement that represents one point from your numbered list. You can create valueless and valued entitlements. Valued entitlements can get their values from an external query, they can be administrator defined, or they can be free form. 45

46 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture 3. Add policies to the Identity Manager Driver to implement the designed entitlement. To create a policy for an Identity Manager driver, you need to be conversant in XSLT or DirXML script, in the way the connected system handles and receives information, and with the way Novell edirectory TM stores information. Unless you are a good DirXML* programmer, this is a job for consultants. 4. In the slide Figure 2-1, Entitlement Types, on page 41 we talked about the two types of Entitlements Valueless and Valued. These Entitlements are created to perform the functions that where mentioned. One being a Yes or No and the other applying it to something on the connected system. Having these Entitlements in place does nothing unless they are granted by some means. The 3 ways of granting Entitlements are Role Based Entitlements (policy), Workflow, and the Roles Subsystem of the Roles Based Provisioning Module. These are the steps to successfully implement Entitlements. Step two is not stressed in this presentation because Policy is a prerequisite to this course and is covered in the ATT Identity Manager course. If you create your own Entitlements, you MUST add policy in the driver for them to work. No policy no Entitlement, they work together. SLIDE: Entitlement Service Drivers The following drivers change the EntitlementRef attribute on the user object. This is modified depending upon which agents is being used. 46

47 Entitlements Creation to Implementation The process for creating the entitlement in Designer is to first create the Entitlement object, defining the query parameters. Then you must write the policies that will check when the entitlement is granted or revoked and do the appropriate actions. These policies are typically going to go in the Subscriber Channel of the driver. 47

48 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture 48

49 Resource Model SECTION 3 Resource Model In this section the topic the new resource model introduced with RBPM 3.7 will be reviewed and how you can use this to manage the resources in your organization. The following will be covered: 1. Resource Model on page Creating Resources on page Assigning Resources on page Role Mapping Administrator on page 65 49

50 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Objective 1 Resource Model A resource is any digital entity such as a user account, computer, or database that a business user needs to be able to access. The User Application provides a convenient way for end users to request the resources they need. In addition, it provides tools that administrators can use to define resources. Each resource is mapped to an entitlement. A resource definition can have no more than one entitlement bound to it. A resource definition can be bound to the same entitlement more than once, with different entitlement parameters for each resource. 50

51 Resource Model 51

52 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture NOTE: If a role is assigned to a container or group, then a users within the container or group may automatically be granted access to the resource(s) associated with the role. 52

53 Resource Model Figure 3-1Process flow diagram for resource request The steps in the process as shown in Figure 3-1 on page 53: 1. A user requests a resource within the User Application 2. A User Request object is created in the Identity Vault 3. The Role and Resource Service Driver processes the new request 4. The Role and Resource Service Driver starts a workflow, and changes the request status 5. The approval process is performed within the User Application. Upon completion of the approval process, the workflow activity changes the request status 6. The Role and Resource Driver picks up the change in the status, and begins to provision the resource, if all of the necessary approvals have been provided 7. The User Object attributes are updated to included the resource binding and approval information 8. An entitlement request is made for the SAP Profile 9. The SAP Driver processes the entitlement and creates the profile in SAP 53

54 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture 54

55 Resource Model Objective 2 Creating Resources The purpose of the Roles and Resources tab is to give you a convenient way to perform roles-based provisioning actions. These actions allow you to manage role definitions and role assignments within your organization, as well as resource definitions and resource assignments. Role assignments can be mapped to resources within a company, such as user accounts, computers, and databases. Alternatively, resources may be assigned directly to users. For example, you might use the Roles and Resources tab to: Make role and resource requests for yourself or other users within your organization Create roles and role relationships within the roles hierarchy Create separation of duties (SoD) constraints to manage potential conflicts between role assignments Look at reports that provide details about the current state of the Role Catalog and the roles currently assigned to users, groups, and containers 55

56 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture SLIDE: Resource Catalog The purpose of the resource functionality within the User Application is to give you a convenient way to perform resource-based provisioning actions. These actions allow you to manage resource definitions and resource assignments within your organization. Resource assignments can be mapped to users or to roles within a company. For example, you might use resources to: Make resource requests for yourself or other users within your organization Create resources and map them to entitlements SLIDE: Define Resource To define a resource: 1. Figure 3-2, Resource definition descriptive information, on page Figure 3-3, Resource definition details: Entitlements, Request Form, and Approvals, on page 57 Figure 3-2Resource definition descriptive information 56

57 Resource Model Field Display Name Description The text used when the resource name displays in the User Application. You cannot include the following characters in the Display Name when you create a resource: < >, ; \ " + # = / & * You can translate this name in any of the User Application s supported languages. Description Categories Owners The text used when the role description displays in the User Application. Like the Display Name, you can translate it to any of the User Application s supported languages. Allow you to categorize resources for resource organization. Categories are used for filtering lists of resources. Categories are multi-select. Users who are designated as the owners of the resource definition. The resource owner does not automatically have the authorization to administer changes to a resource definition. Figure 3-3Resource definition details: Entitlements, Request Form, and Approvals SLIDE: Select Entitlement 57

58 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Each resource is mapped to an entitlement. A resource definition can have no more than one entitlement bound to it. A resource definition can be bound to the same entitlement more than once, with different entitlement parameters for each resource. Specify the details of the entitlement binding. The details vary depending on the type of entitlement you are associating with the resource: SLIDE: Entitlement Without and With Values Figure 3-4Without a value Type of Entitlement Valueless entitlement Description The entitlement accepts no parameter values. For example, a resource might be bound to an entitlement called Health Benefits that simply makes the recipient eligible for health care benefits. This type of entitlement has a fixed behavior and thereby requires no further information from the requester. When you bind to a valueless entitlement, no further configuration is required. Free-form valued entitlement The entitlement that requires a parameter value specified as a free-form string at request time. For example, a resource might be bound to an entitlement called Clothing that allows the requester to specify a value that represents their favorite color. You can assign a value at design time when you re defining the resource, or allow the user to assign a value at request time.. 58

59 Resource Model Type of Entitlement Single-valued entitlement Description The entitlement that requires a single parameter value. For example, a resource might be bound to an entitlement called Parking Permission that allows the requester to select a parking location. The allowable values are provided by an entitlement list, which can include a static list of values defined by an administrator or a dynamic list of values generated from an LDAP query. You can assign a value at design time when you re defining the resource, or allow the user to assign a value at request time. Multi-valued entitlement The entitlement that accepts one or more parameter values. For example, a resource might be bound to an entitlement called Building Pass that allows the requester to select one or more buildings. The allowable values are provided by an entitlement list, which can include a static list of values defined by an administrator or a dynamic list of values generated from an LDAP query. You can assign a value at design time when you re defining the resource, or allow the user to assign a value at request time. A resource definition can have no more then one entitlement bound to it. Figure 3-5With a value 59

60 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture A resource definition can have one or more same-entitlement references bound to it. This capability provides support for entitlements where the entitlement parameters represent provisionable accounts or permissions on the connected system. Entitlement and decision support parameters can be specified at design time (static) or at request time (dynamic). SLIDE: Request Form The request form for a resource displays two different types of fields: Entitlement parameter fields, which map to entitlement parameters for which the user can provide values at request time. Decision support fields, which allow the requester to provide additional information that may help the approver make a decision about whether to approve or deny the request. The Request Form tab shows both types of fields, and provides a user interface for creating and editing decision support fields. In addition to the fields shown on the Request Form tab, the request form always includes the following required fields: User Reason All of the fields on the request form are shown on the approval form as read-only values. 60

61 Resource Model SLIDE: Resource Approvals Field Required Description Select this box if the resource requires approval when requested. Deselect this box if the resource does not require approval when requested. Custom Approval Standard Approval When you select Custom Approval, you need to select a custom Resource Assignment Approval Definition. This is the name of the provisioning request definition executed when the resource is requested. When you select Standard Approval, the resource uses the standard resource assignment approval definition specified in the Resource Subsystem configuration settings. 61

62 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture Field Approval Type Description Select Serial if you want the role to be approved by all of the users in the Approvers list. The approvers are processed sequentially in the order they appear in the list. Select Quorum if you want the role to be approved by a percentage of the users in the Approvers list. The approval is complete when the percentage of users specified is reached. For example, if you want one of four users in the list to approve the condition, you would specify Quorum and a percentage of 25. Alternatively, you can specify 100% if all four approvers must approve in parallel. The value must be an integer between 1 and 100. TIP: The Info button displays text that explains the approval types. Approvers Select User if the role approval task should be assigned to one or more users. Select Group if the role approval task should be assigned to a group. Select Role if the role approval task should be assigned to a role. To locate a specific user, group, or role, use the Object Selector or History buttons. 62

63 Resource Model Objective 3 Assigning Resources Resources can be assigned to users only. They cannot be assigned to groups or containers. However, if a role is assigned to a group or container, the users in the group or container may automatically be granted access to the resources associated with the role. SLIDE: Resource Assignment Request SLIDE: Request Status 63

64 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture SLIDE: User Assigned Resource 64

65 Resource Model Objective 4 Role Mapping Administrator The Novell Identity Manager Role Mapping Administrator lets you map managed systems roles, composite roles, and profiles (collectively referred to as authorizations) to Identity Manager roles. When a user is assigned a role through the Identity Manager Roles Based Provisioning Module, he or she receives all authorizations mapped to that role. A web-based administrative tool Automatically discovers authorizations/permissions from managed systems Displays all Enterprise Roles and the retrieved authorizations in a single screen Simplifies and speeds up the Role Mapping process with an intuitive drag & drop interface Creates Role Mappings in a Resource aware manner Intended users (at this time) is administrators, it is not an end user or manager tool. Changes made can affect the whole corporation SLIDE: Role Mapping Administrator UI The primary work area in the Role Mapping Administrator is called the Main Window. You use the Main Window to perform all of the tasks required to map authorizations to Identity Manager roles and to manage (create, edit, delete) Identity Manager roles. Identity Vault Panel The Identity Vault panel contains two lists: the Identity Vault Roles list and the Mappings list. The Identity Vault Roles list displays the roles that you are authorized to manage. The Mappings list displays any authorizations that are mapped to it, the name of the resource to which an authorization is mapped, and the mapping description. You can reload and edit the mapping. After you select a role, the Mappings list displays any authorizations that are mapped to it. 65

66 NIQ21-Understanding Roles Based Provisioning 4.01 Roles, Security and Resource Model / Lecture The Identity Vault panel also contains options to refresh roles from the Identity Vault, filter the roles that you see in the Identity Vault Roles list, and manage (create, edit, and delete) roles. Authorizations Panel The Authorizations panel displays the authorizations that are available for mapping to Identity Manager roles. To map an authorization to a role, you select the role in the Identity Vault Roles list, select the authorization in the Authorizations list, then drag the authorization to the Mappings list. Depending on how your Identity Manager environment is configured, you might have more than one system. The Authorizations list displays only the authorizations from the managed system that is currently selected in the list box at the top of the panel. To view authorizations from another system, you must select that system from the list. The Authorizations panel also contain options to refresh authorizations from the Role Mapping Administrator database, reload the Role Mapping Administrator database with authorizations from the available managed systems, and filter the authorizations that you see in the Authorizations list. SLIDE: Who can access RMA? A user who has both the Role Administrator/Manager and Resource Administrator/Manager roles can create, edit, and delete mappings This revision does not provide more granular access rights be careful who you give the application to! RBPM Roles are used to grant access to RMA Table 3-1 Role Administrator Role Manager Resource Administrator Create, Edit Delete Mappings View Mappings Resource Manager View Mappings View Mappings Driver targeted for RMA support out-of-the-box Active Directory edirectory Groupwise LDAP Lotus Notes SAP User 66

67 Resource Model SAP Portal SharePoint SLIDE: RMA Support Entitlement Types SLIDE: Differences between RMA and RBPM 67