Before you proceed you must be familiar with the following topics:

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

You must also have an understanding of Identity Governance and Intelligence.

The SCIM Framework 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.
Currently, the following operators are supported:

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

In filter strings, each attribute must be preceded by the urn (e.g. urn:ietf:params:scim:schemas:core:2.0:User:name.givenName co \"James\").
In SCIM search requests, the applied paging mechanism is different from the SCIM specification. The applied paging mechanism 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.
In SCIM search requests, the selection of attributes by means of attributes and excludedAttributes attributes is not implemented yet.

PATCH operations are not implemented yet, but REPLACE operations are instead available.

BULK operations are not implemented yet.

Some SCIM standard attributes are not mapped in the IGI data model. You can find this information by looking at the Resource Schema.

In addition to SCIM standards, a new Attribute Data Type called RESOURCE was added . This data type includes some information, like the resourceSchema to describe the URN of that resource, and extensionSchema to describe an eventually extension URN.
The following is an example obtained by 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 need to use an API Token generated calling the 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. You must use it 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: represents the query param
• Parameters: represents the path param
• Headers: represents the HTTP header fields
• Request body: represents 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.

The REST API for Access Requests implements only the 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 equal 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 equal to Access Request
3. Find requests to work on
4. Find details for the selected request
5. Authorize (or eventually Execute) the selected requests

Redirect Generated Request during AUTH activity

1. Login as an approver account
2. Find the AUTH Workflow with processName equal to Access Request
3. Find request to work
4. Find Redirect User to obtain a list of users 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 return 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 equal 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 equal to Insert Account
3. Find requests to work on
4. Find detail for the selected request
5. Authorize the selected request

In order to operate the Modify Account Request, follow these steps:

Generate Request

1. Login
2. Find GEN type workflow with processName equals to Modify Account
3. Find the user account
4. Get Account Configuration Attribute specifiying also the account id in step 3 in order to get the current account attribute value
5. Generate the 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 equal to Modify Account
3. Find requests to work on
4. Find the details for the selected request
5. Authorize the selected request

In order to operate the Modify User Request, follow these steps: 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 make the approve operation not-mandatory.

Generate Request

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

Authorize (or Execute) Generated Request

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

In order to operate the forgot password procedure, follow these steps:

1. Get Forgot Configurations to get the reset password modality(at this stage only two modalities are present: immediate or get a temporary password by email)
2. Get Forgot Password Challenges to get a list of challenges to reply to
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 to.
4. Reset Password: requires the token obtained 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 extra step must be executed:

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.