Resource Introduction

Resources grant access to systems and entitlements when membership in a policy is given or access to a Self-Service resource request is granted. Resources define what action will be taken when a policy membership or a resource request is granted to a user, or revoked. The resource defines what systems are provisioned, what additional entitlements are given to the account, and what workflows to execute with additional data for the workflow transaction.

A resource has these functions:

• Defines the type of resource - Account or Entitlement. In an Account type, Resource workflows are used to provision/deprovision the user in the target system. In an Entitlement type, Resource workflows are used to add entitlements only.
• Defines the workflow to run based on changetype=add or changetype=modify or changetype=delete (there is no modify operation for entitlement). When incoming data has a changetype=modify, the end result of the Policy engine is to modify the account on the target system and/or add or remove entitlements; all these are done by workflows.
• Defines the type of entitlement (Group, Role, or Attribute) that is granted when a user is added to a policy; different systems support different entitlement types.
• Defines General Properties of the resource such as Approval Type, which determines whether approval is required and on what level. Also, defines options whether this resource can be requested from Self-Service, and whether multiple accounts can be requested if Resource Type is Account.
• Defines Self-Service Properties specific to the Self-Service UI. These are primarily used in the Self-Service request and in approval, such as User can request multiple permissions, Approvers can change the permission before approving the request, Enable sponsorship of resource and Sponsor must be specified when resource is requested.
• Defines permissions used during the self-service request process. The value of the permission will be mapped to the attribute Resource-Permission (multivalued when more than one permission is there) and passed to the Resource workflow.
• Defines custom attributes so that additional information can be displayed for Self-Service requesters and approvers. Displaying the requested permissions alone may not suffice. For example, a free flowing edit box might be required to enter additional information while requesting or approving. This could be a credit card number or a system/account name in the case of Administrative Provisioning. These attributes will be used in the Approvals tab and Request Access tab and will be included in the data passed to the workflow. When used in these tabs, the label of this attribute is taken from the PRODUCT_ATTRIBUTE_LOCALE table.
• Defines dependent resources that depend on this resource for its execution. Before allocation, some resources need certain other resources to be allocated first in order to use the same name across the resources. For example, an entitlement resource in a system may need the account resource in the system to be created ahead of it, to use the same account name. The dependency defined will be honored during the execution by Self-Service, Policy, and Approval engines. Dependent resources can be configured to honor dependency during add/modify/delete executions. During add/modify, the parent resource will be granted/modified ahead of the dependent resource; and during delete, the dependent resource is removed ahead of the parent removal.
• Defines resource owners of the resource. Some resources need to be approved by resource owner(s) prior to allocation. We can add one or more users as resource owners of a resource. A Resource Owner based approver list can be created for a resource for approval. It is a dynamic list and during execution, the owners who have the approval bit are designated as the approvers of the resource in context.