B Service Account Management

This appendix describes how to change and manage the service account in Oracle Identity Manager. It contains the following topics:

• "Overview"

Overview

Service accounts are general administrator accounts (for example, admin1, admin2, admin3, etc.) that are used for maintenance purposes. Usually these accounts are used to allow one system (rather than a user) to interact with another system. The model for managing and provisioning service accounts is slightly different from normal provisioning.

Service accounts are requested, provisioned, and managed in the same manner as regular accounts. Service accounts use the same resource objects, provisioning processes, and process/object forms as regular accounts. What differs is how the service account lifecycle is managed, and what can be done to it.

A service account is distinguished from a regular account by an internal flag. When a user is provisioned with a service account, Oracle Identity Manager manages a mapping from the user's identity to the service account. This user is considered the owner of the Service Account.

This section contains the following topics:

• "Service Account Change"

• "Service Account Alert"

• "Service Account Moved"

• "APIs"

• "Service Account Management Behavior"

Service Account Change

A user (administrator) can change an existing "regular" account to be a service account or change an existing service account to be a regular account. If any of these changes occur, then the Service Account Change task is inserted within the provisioning process (becoming active in the Tasks tab of the Process Definition). Any adapter associated with this provisioning process executes. If there is no adapter, then a pre-defined response code is attached.

The relevant APIs for this functionality are:

• tcUserOperations.changeFromServiceAccount

• tcUserOperations.changeToServiceAccount

Service Account Alert

When any lifecycle event occurs for the user to whom the service account is linked, the Service Account Alert task is inserted into the provisioning process of that service account instance. A user (administrator) can use this task to initiate the appropriate actions in response to the event that occurred for the user.

Qualifying lifecycle events for a user are the user being disabled or the user being deleted. In these cases, the only action that happens to the service account instance is the service account alert task being inserted.

This behavior is not followed for events directly on the service account (like explicitly disabling a service account).

Service Account Moved

A user (administrator) can transfer ownership of a service account from one user to another. This translates into the provisioning instance showing up in the resource profile of the new owner, and no longer in the resource profile of the old user. The Service Account Moved task is inserted into the provisioning process of the resource instance after the account is moved. Any adapter associated with this provisioning process executes. If there is no adapter, then a pre-defined response code is attached.

The API method for moving a Service Account is tcUserOperationsIntf.moveServiceAccount.

APIs

The following methods set the flag(s):

• tcRequestOperations.addRequestObject

• tcRequestOperations.setRequestObjectAsServiceAccountFlag

• tcUserOperations.changeFromServiceAccount

• tcUserOperations.changeToServiceAccount

• tcUserOperations.provisionObject

• tcUserOperations.moveServiceAccount

• tcObjectOperations.getServiceAccountList

Service Account Management Behavior

Here are some data points about Service Account Management:

• Service Accounts are requested, provisioned, and managed the same as Regular Accounts. A Service Account is no different from a regular account, in that it uses the same resource object, provisioning processes and process/object forms. It is distinguishable from a Regular Account only by a flag. This flag gets set by the user making the request for the resource, or by the administrator direct provisioning the resource (hence, it is exposed/handled in the APIs).

• During its lifecycle, a Service Account can be changed to a Regular Account, and a Regular Account can be changed to a Service Account. When any of these changes occurs then Service Account Changed task functionality is triggered.

• When the user gets "deleted", the resource is not revoked (the provisioning process for the Service Account should not get cancelled), causing the undo tasks to fire. Instead, the Service Account Alert task functionality is triggered.

• When the user gets "disabled", the resource should not be disabled (tasks of effect "Disable" should not be inserted into the provisioning process for the Service Account instance). Instead, the Service Account Alert task functionality is triggered.

• Explicitly disabling/enabling/revoking a Service Account instance (directly or via request) is managed and behave the same way as Regular Accounts.

• Oracle Identity Manager API can be used to transfer (move) a provisioned service account resource (provisioning process, process form entry, etc) from one user to another. When this happens, the Service Account Move task functionality is triggered.