Before to proceed you must be familiar with the following technologies:

• RESTful API
• JSON (JavaScript Object Notation)
• SCIM specifications (RFC7643, RFC7644)

You must also have an understanding of the IBM Security Verify Governance solution.

The SCIM Framework realized provides limitations on original SCIM features that include filtering, paging, patch operations and bulk.
In particular, SCIM query filter expressions with or logic operator or parenthesis or brackets are not supported.
At this stage supported operators are the following:

• and logic operator
• eq equals
• co contains
• sw starts with
• ew ends with

Moreover, in filter string each attribute must be preceded by the urn (e.g. urn:ietf:params:scim:schemas:core:2.0:User:name.givenName co \"James\").
Additionally, in SCIM search request the paging mechanism adopted is different from the SCIM specification. The paging mechanism actuated is page based, where the startPage field of SCIM search request indicates the page target and the count field specifies the number of element in that page.
Additionally, in the SCIM search request attributes selection by means attributes and excludedAttributes attributes is not implemented yet.

PATCH operations are not implemented yet, are instead available replace operations.

BULK operations are not implemented yet.

Some SCIM standard attributes are not mapped in IBM Security Verify Governance data model. You can find this information looking at the Resource Schema.

In addition to SCIM standards, it was added a new Attribute Data Types called RESOURCE . This data type includes some information as the resourceSchema to describe the URN of that resource, and extensionSchema to describe an eventually extension URN.
The following is an example obtained calling Resource Schema API:

				{
					"name": "rolesToAdd",
					"type": "RESOURCE",
					"mutability": "READ_WRITE",
					"returned": "DEFAULT",
					"uniqueness": "NONE",
					"multiValued": true,
					"description": "List of entitlements to add.",
					"required": false,
					"caseExact": true,
					"resourceSchema": "urn:ietf:params:scim:schemas:core:2.0:Entitlement",
					"extensionSchema": "urn:ibm:params:scim:schemas:extension:bean:arm:2.0:Entitlement"
				}
						
				

This means that rolesToAdd is a resource described by "urn:ietf:params:scim:schemas:core:2.0:Entitlement" schema with "urn:ibm:params:scim:schemas:extension:bean:arm:2.0:Entitlement" extension.

When calling the SCIM API, you'll need to use an API Token generated calling Login API method.
You must set the token in "Authorization" header: e.g. Authorization : Bearer WwgdmVyc2lvbj0iMS4wIiBlbmNv

In order to use Single Sign On you have to call the following link after configuring the virtual appliance to use OAuth authorization.

https://{host}:{port}/ideas/oauth/login

If the login is successful a token is returned that must be used to call the REST APIs.
Download ppt.

Every API is described by the following sections:

• URL: endpoint to call the API
• Method: HTTP Method (GET, POST, DELETE, PUT)
• Attributes: represent the query param
• Parameters: represent the path param
• Headers: represent the HTTP header fields
• Request body: represent the JSON object to send in POST or PUT operation. This object is defined through the URN written in Description coloumn. You can obtain the object definition calling Resource Schema API passing the URN.

REST API for Access Request implments only User Entitlement assignment workflow. In order to operate this workflow, the following step must be executed:

Generate Request

1. Login
2. Find GEN type workflow with processName equals to Access Request
3. Find users by workflow
4. Find entitlement for the selected user (to update or remove entitlements)
5. Find role to add for selected user (to add entitlements)
6. Generate request with the entitlements to add and/or to remove for the selected user as beneficiary

Authorize (or Execute) Generated Request

1. Login as an approver account
2. Find AUTH type workflow with processName equals to Access Request
3. Find requests to work
4. Find detail for the selected request
5. Authorize (or eventually Execute) the selected request

Redirect Generated Request during AUTH activity

1. Login as an approver account
2. Find the AUTH Workflow with processName equals to Access Request
3. Find request to work
4. Find Redirect User to obtain a list of user available to get the request (Redirection Approver)
5. Redirect the request in 2 to a user selected in 3.
6. Login as a Redirection Approver
7. Find the Redirect Workflow
8. Find request to work
9. Approve or reject the request
10. Redirect the request in 2 to a user selected in 3.

Possibly a Redirection Approver can come back a redirected request to its owner.

In order to operate the Create Account Request, the following step must be executed:

Generate Request

1. Login
2. Find GEN type workflow with processName equals to Insert Account
3. Find users by workflow
4. Find assignable account
5. Get Account Configuration Attribute
6. Generate User Account Management Request

Authorize (or Execute) Generated Request

1. Login as an approver account
2. Find AUTH type workflow with processName equals to Insert Account
3. Find requests to work
4. Find detail for the selected request
5. Authorize the selected request

In order to operate the Modify Account Request, the following step must be executed:

Generate Request

1. Login
2. Find GEN type workflow with processName equals to Modify Account
3. Find users account
4. Get Account Configuration Attribute specifiying also the account id at step 3 in order to get the current account attribute value
5. Generate User Account Management Request specifying into toUpdate field the ID of the account to update and the account attribute list

Authorize (or Execute) Generated Request

1. Login as an approver account
2. Find AUTH type workflow with processName equals to Modify Account
3. Find requests to work
4. Find detail for the selected request
5. Authorize the selected request

In order to operate the Modify User Request, the following step must be executed: Configure User Erc in Access Governance Core -> Settings -> Core Configurations -> User Virtual Attributes. Select and configure Swim_UserErc. Configure Modify User Workflow. Hint: remove the approver step in order to not require an approve operation.

Generate Request

1. Login
2. Find GEN type workflow with processName equals to Modify User
3. Get User Attribute
4. Generate User Modify Request specifying the attributes to modify

Authorize (or Execute) Generated Request

1. Login as an approver account
2. Find AUTH type workflow with processName equals to Modify User
3. Find requests to work
4. Find detail for the selected request
5. Authorize the selected request

In order to operate the forgot password procedure, the following step must be executed:

1. Get Forgot Configurations to get the reset password modality(at this stage only two modality are present: immediate or get a temporary password by email)
2. Get Forgot Password Challenges to get a list of challenges to reply
3. Submit Forgot Password Challenges to submit the challenge answers. If successful the rest method returns a token, otherwise go to 1 to get a new list of challenges to reply.
4. Reset Password: requires token got in 2. If the forgot password modality is set to 'immediate' provide also the new password.

If reset password modality is set to generate a temporary password by email, the following step must be executed in addition:

1. Login with the username and the temporary password sent by email
2. Call Change Password rest api to set the password providing the current temporary password and the new one.