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 that group or container might automatically be granted access to the resources associated with the role.
A Resource Administrator can configure the approval process for resources. The approval process for a resource might be handled by one of the following:
a provisioning request definition
an external system, by setting the status code on the resource request
If a role assignment initiates a request for a resource, it is possible that the request will not be granted, even though the role is provisioned. The most likely reason for this would be that the necessary approvals were not provided.
When a user requests a resource, the request starts a workflow. The workflow coordinates the approvals needed to fulfill the request. Some requests require approval from a single individual; others require approval from several individuals. In some instances, a request can be fulfilled without any approvals.
The following business rules govern the behavior of resources within the identity applications:
Resources can only be assigned to a user. The resource can be granted to users in a container or group based on implicit role assignment. But the resource assignment will only be associated with a user.
Resources can be assigned in any of the following ways:
Directly by a user through UI mechanisms
Through a provisioning request
Through a role request assignment
Through a Rest or SOAP interface
The same resource can be granted to a user multiple times (if this capability has been enabled in the resource definition).
A resource definition can have no more than one entitlement bound to it.
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).
Your workflow designer and system administrator are responsible for setting up the identity applications for you and the others in your organization. The flow of control for a resource-based workflow, as well as the appearance of forms, can vary depending on how the workflow designer defined the workflow's approval definition in the Designer for Identity Manager. In addition, your job requirements and level of authority determine what you can see and do.
The following example shows the process flow for a resource assignment request. In this example, a user requests a resource that grants access to an SAP profile:
In the Dashboard, a user requests access to SAP.
The Identity Vault creates a User Request object.
The Role and Resource Service Driver processes the new request.
The Role and Resource Service Driver starts a workflow, and changes the request status.
The identity applications perform the approval process. Upon completion of the approval process, the workflow activity changes the request status.
The Role and Resource Service driver picks up the change in the status and begins to provision the resource if all of the necessary approvals have been provided.
The User Object attributes are updated to include the resource binding and approval information.
An entitlement request is made for the SAP Profile.
The SAP Driver processes the entitlement and creates the user’s profile in SAP.