LukeParke/developer.sailpoint.com
1
0
Fork 0
mirror of https://github.com/LukeHagar/developer.sailpoint.com.git synced 2025-12-07 20:37:46 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add more redirects, update docs with Identity Security Cloud

Browse Source
This commit is contained in:
Tyler Mairose
2024-02-28 22:27:50 -05:00
parent 200cb92542
commit dcb0bcbcd2
94 changed files with 764 additions and 342 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
docs/api/authentication.md
View File

@@ -15,9 +15,9 @@ import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem';
## Overview
With SailPoint's IdentityNow (IDN) APIs, you can extend your IDN platform far beyond its current capabilities.
With SailPoint's Identity Security Cloud (ISC) APIs, you can extend your ISC platform far beyond its current capabilities.
To be able to do so, you must first authenticate to the IDN APIs.
To be able to do so, you must first authenticate to the ISC APIs.
Authentication is the act of validating a user's identity, generally by passing some kind of credentials.
A fast, simple way to authenticate to the APIs is to generate a [personal access token](#generate-a-personal-access-token) and pass that token.
@@ -36,35 +36,35 @@ This diagram shows the flow of this authentication/authorization process:
sequenceDiagram
autonumber
participant H as HTTP Client
participant I as IdentityNow
participant I as Identity Security Cloud
H->>I: Access Token Request
I->>H: Access Token Response
loop Until token expires
H->>I: API Request + Access Token
I->>H: IdentityNow API Response
I->>H: Identity Security Cloud API Response
end
```
</div>
The flow involves these four key steps:
1. **Access Token Request**: The HTTP client (a script, application, Postman, cURL, etc.) makes a request to IDN to get a JWT `access_token`.
2. **Access Token Response**: If the request is valid, IDN responds to the HTTP client with a JWT `access_token`.
3. **API Request**: The HTTP client makes a request to an IDN endpoint with the header, `Authorization: Bearer {access_token}`.
4. **API Response**: If both the request itself and the JWT `access_token` in its header are valid, IDN responds to the client.
1. **Access Token Request**: The HTTP client (a script, application, Postman, cURL, etc.) makes a request to ISC to get a JWT `access_token`.
2. **Access Token Response**: If the request is valid, ISC responds to the HTTP client with a JWT `access_token`.
3. **API Request**: The HTTP client makes a request to an ISC endpoint with the header, `Authorization: Bearer {access_token}`.
4. **API Response**: If both the request itself and the JWT `access_token` in its header are valid, ISC responds to the client.
If you encounter unexpected errors, refer to the [Troubleshooting](#troubleshooting) section of this document.
The idea is that once you have authenticated to the IDN APIs and you have received an `access_token`, you can use that `access_token` to provide authorization for your API requests.
The idea is that once you have authenticated to the ISC APIs and you have received an `access_token`, you can use that `access_token` to provide authorization for your API requests.
This document includes all the information you need to know to engage in this authentication/authorization process, as well as a guide on how to get started.
## Get started
Read this guide to learn how to authenticate to SailPoint's IDN APIs.
Read this guide to learn how to authenticate to SailPoint's ISC APIs.
To authenticate to the IDN APIs, you must be able to connect to your tenant to send the access token request.
To authenticate to the ISC APIs, you must be able to connect to your tenant to send the access token request.
To do so, you need to do the following:
1. [Find your tenant's OAuth details](#find-your-tenant's-oauth-details)
2. [Generate personal access token](#generate-personal-access-token)
@@ -76,13 +76,13 @@ To do so, you need to do the following:
Your tenant's OAuth details refer to the details you need to know to connect it to the APIs.
You need to know your tenant's name, its `authorizeEndpoint` URL, and its `tokenEndpoint` URL.
Your IDN instance is likely using the domain name supplied by SailPoint (`{tenant}.api.identitynow.com`), in which case, the tenant name is in the URL.
Your ISC instance is likely using the domain name supplied by SailPoint (`{tenant}.api.identitynow.com`), in which case, the tenant name is in the URL.
This is assumed to be the case in this guide.
However, if your IDN instance is using a vanity URL, you must enter this URL into your browser to get your OAuth info:
However, if your ISC instance is using a vanity URL, you must enter this URL into your browser to get your OAuth info:
`https://{tenant}.api.identitynow.com/oauth/info`
If you have admin access but don't know your tenant name, you can learn it by following these steps:
1. Log into your IDN instance.
1. Log into your ISC instance.
2. Select the 'Dashboard' dropdown.
3. Select 'Overview'.
4. Find the tenant name ('Org Name') in the dashboard's `Org Details` section.
@@ -109,10 +109,10 @@ A personal access token (PAT) is a method of authenticating to an API as a user
PATs are primarily used in scripts or programs that lack an easy way to implement an OAuth2 flow but need to call API endpoints that require user context.
PATs are also convenient for use in tools like [Postman](https://www.postman.com/) when you are exploring and testing the APIs.
Any IDN user can generate a PAT.
Any ISC user can generate a PAT.
To do so, follow these steps:
1. Select **Preferences** from the drop-down menu under your username, then **Personal Access Tokens** on the left.
You can also go directly to the page by using this URL (replace `{tenant}` with your IdentityNow tenant): `https://{tenant}.identitynow.com/ui/d/user-preferences/personal-access-tokens`
You can also go directly to the page by using this URL (replace `{tenant}` with your Identity Security Cloud tenant): `https://{tenant}.identitynow.com/ui/d/user-preferences/personal-access-tokens`
2. Click **New Token** and enter a meaningful description to help differentiate the token from others.
@@ -145,7 +145,7 @@ You must choose the one that best serves your purposes.
This document covers these three common flows:
1. [**Client Credentials**](https://oauth.net/2/grant-types/client-credentials/) - Clients use this grant type to obtain a JWT `access_token` without user involvement such as scripts, programs or system to system integration.
2. [**Authorization Code**](https://oauth.net/2/grant-types/authorization-code/) - Clients use this grant type to exchange an authorization code for an `access_token`. Authorization codes are mainly used by web applications because there is a login into IDN with a subsequent redirect back to the web application/client.
2. [**Authorization Code**](https://oauth.net/2/grant-types/authorization-code/) - Clients use this grant type to exchange an authorization code for an `access_token`. Authorization codes are mainly used by web applications because there is a login into ISC with a subsequent redirect back to the web application/client.
3. [**Refresh Token**](https://oauth.net/2/grant-types/refresh-token/) - Clients use this grant type to exchange a refresh token for a new `access_token` when the existing `access_token` has expired. This allows clients to continue using the APIs without having to re-authenticate as frequently. This grant type is commonly used together with `Authorization Code` to prevent a user from having to log in several times per day.
One way to determine which authorization flow you need to use is to look at the specification for the endpoint you want to use.
@@ -161,9 +161,9 @@ The guide will detail the three different authorization grant flows you can use
Clients use the 'Client Credentials' grant type to obtain access tokens without user involvement. This is the simplest authentication flow.
API endpoints that require [user level permissions](https://documentation.sailpoint.com/saas/help/common/users/user_level_matrix.html) require the use of Personal access tokens (PATs). Correspondingly, the endpoints a personal access token (PAT) can call depends on the permissions of the user who generated it and the configuration of IDN.
API endpoints that require [user level permissions](https://documentation.sailpoint.com/saas/help/common/users/user_level_matrix.html) require the use of Personal access tokens (PATs). Correspondingly, the endpoints a personal access token (PAT) can call depends on the permissions of the user who generated it and the configuration of ISC.
Note: If an API Key is used then IDN API calls are made outside of the context of a user and some API calls will not work.
Note: If an API Key is used then ISC API calls are made outside of the context of a user and some API calls will not work.
An OAuth 2.0 client using the client credentials grant flow must have `CLIENT_CREDENTIALS` as one of its grantTypes (PATs are implicitly granted the `CLIENT_CREDENTIALS` grant type):
@@ -184,7 +184,7 @@ An OAuth 2.0 client using the client credentials grant flow must have `CLIENT_CR
This is the overall authorization flow:
1. The client first submits an OAuth 2.0 token request to IDN in this form:
1. The client first submits an OAuth 2.0 token request to ISC in this form:
```text
POST https://{tenant}.api.identitynow.com/oauth/token
@@ -221,7 +221,7 @@ curl --location 'https://{tenant}.api.identitynow.com/oauth/token' \
--form 'client_secret="{clientSecret}"'
```
2. IDN validates the token request and responds.
2. ISC validates the token request and responds.
If the request is successful, the response contains a JWT access token.
For more information about the JWT access token in the response, refer to [#OAuth-token-response](#oauth-token-response).
@@ -234,7 +234,7 @@ To learn more about the OAuth client credentials grant flow, refer [here](https:
Further Reading: [https://oauth.net/2/grant-types/authorization-code/](https://oauth.net/2/grant-types/authorization-code/)
Clients use this grant type to exchange an authorization code for an `access_token`.
This is mainly used for web apps because there is a login into IDN with a subsequent redirect back to the web app/client.
This is mainly used for web apps because there is a login into ISC with a subsequent redirect back to the web app/client.
The OAuth 2.0 client you are using must have `AUTHORIZATION_CODE` as one of its grant types.
The redirect URLs must also match the list in the client as well:
@@ -270,7 +270,7 @@ sequenceDiagram
autonumber
participant U as User
participant W as Web App
participant I as IdentityNow
participant I as Identity Security Cloud
U->>W: Click login link
W->>I: Authorization request to https://{tenant}.login.sailpoint.com/oauth/authorize
@@ -287,19 +287,19 @@ This is the overall authorization flow:
1. The user clicks the login link on a web app.
2. The web app sends an authorization request to IDN in this form:
2. The web app sends an authorization request to ISC in this form:
```Text
GET https://{tenant}.login.sailpoint.com/oauth/authorize?client_id={client-id}&client_secret={client-secret}&response_type=code&redirect_uri={redirect-url}
```
3. IDN redirects the user to a login prompt to authenticate to IdentityNow.
3. ISC redirects the user to a login prompt to authenticate to Identity Security Cloud.
4. The user authenticates to IDN.
4. The user authenticates to ISC.
5. Once authentication is successful, IDN issues an authorization code back to the web app.
5. Once authentication is successful, ISC issues an authorization code back to the web app.
6. The web app submits an OAuth 2.0 token request to IDN in this form:
6. The web app submits an OAuth 2.0 token request to ISC in this form:
```text
POST https://{tenant}.api.identitynow.com/oauth/token?grant_type=authorization_code&client_id={client-id}&client_secret={client-secret}&code={code}&redirect_uri={redirect-url}
@@ -311,7 +311,7 @@ The token endpoint URL is `{tenant}.api.identitynow.com`, and the authorize URL
:::
7. IDN validates the token request and submits a response. If the request is successful, the response contains a JWT `access_token`.
7. ISC validates the token request and submits a response. If the request is successful, the response contains a JWT `access_token`.
For more information about the JWT access token in the response, refer to [#OAuth-token-response](#oauth-token-response).
These are the query parameters in the OAuth 2.0 token request for the authorization code grant:
@@ -363,13 +363,13 @@ This is the overall authorization flow:
1. The client application receives an `access_token` and a `refresh_token` from one of the other OAuth grant flows, like `AUTHORIZATION_CODE`.
2. The client application detects that the `access_token` is about to expire, based on the `expires_in` attribute contained within the JWT token.
3. The client submits an OAuth 2.0 token request to IDN in this form:
3. The client submits an OAuth 2.0 token request to ISC in this form:
```text
POST https://{tenant}.api.identitynow.com/oauth/token?grant_type=refresh_token&client_id={client_id}&client_secret={client_secret}&refresh_token={refresh_token}
```
4. IDN validates the token request and submits a response. If the request is successful, the response contains a new `access_token` and `refresh_token`.
4. ISC validates the token request and submits a response. If the request is successful, the response contains a new `access_token` and `refresh_token`.
These are the query parameters in the OAuth 2.0 token request for the refresh token grant flow:
@@ -417,7 +417,7 @@ A successful request using any of the grant flows to `https://{tenant}.api.ident
}
```
You can use the JWT `access_token` to authorize REST API calls through the IDN API gateway.
You can use the JWT `access_token` to authorize REST API calls through the ISC API gateway.
To use the `access_token`, simply include it in the `Authorization` header as a `Bearer` token.
This is an example V3 API request that has the access token in the header:
@@ -440,7 +440,7 @@ However, the `refresh_token` will only be present if the API client has the `REF
- The `user_id` and `identity_id` define the identity context of the person who authenticated.
However, these values aren't set for the client credentials grant type because it doesn't have a user context.
With the JWT `access_token`, you can now successfully send authenticated IDN API requests. To learn more about authorization and the scopes you can apply to further control access to the APIs, refer to [Authorization](/docs/api/authorization).
With the JWT `access_token`, you can now successfully send authenticated ISC API requests. To learn more about authorization and the scopes you can apply to further control access to the APIs, refer to [Authorization](/docs/api/authorization).
## More Information
@@ -522,25 +522,25 @@ This section describes some different use cases and which grant flow you would w
For daily work or short, quick administrative actions, you can just use a PAT. This makes the process easier because you don't really need to worry about grant types - you can easily generate a PAT in the user interface (UI).
Follow these steps to do so:
1. Log in to IDN.
1. Log in to ISC.
2. Go to 'Preferences', then 'Personal Access Tokens', and [generate a PAT](#generate-a-personal-access-token).
3. The PAT's `client_id` and `client_secret` provide the necessary authentication to send API requests, without any grant flow.
#### Postman
[Postman](https://www.postman.com/) is a popular HTTP client you can use to design, build, test, and iterate your APIs. Postman users and teams can create public workspaces they can use to make it easy to access their API collections and environments and get started. SailPoint maintains a [public workspace for the IdentityNow API collections](https://www.postman.com/sailpoint/workspace/identitynow). You can use this workspace to access all the IDN API collections and stay up to date.
[Postman](https://www.postman.com/) is a popular HTTP client you can use to design, build, test, and iterate your APIs. Postman users and teams can create public workspaces they can use to make it easy to access their API collections and environments and get started. SailPoint maintains a [public workspace for the Identity Security Cloud API collections](https://www.postman.com/sailpoint/workspace/identitynow). You can use this workspace to access all the ISC API collections and stay up to date.
If you're using Postman, you have some different ways to set up your authorization.
You can just leverage the accessToken as mentioned above, or you can configure Postman to use OAuth 2.0 directly.
For more information about how to do so, refer [here](https://learning.postman.com/docs/sending-requests/authorization/).
#### Web applications
If you are making a web application, the best grant flow to use is the [Authorization Code grant flow](#request-access-token-with-authorization-grant-flow). This will allow users to be directed to IDN to login and then redirected back to the web application through a URL redirect. This also works well with Single Sign-on (SSO), strong authentication, and pass-through authentication mechanisms.
If you are making a web application, the best grant flow to use is the [Authorization Code grant flow](#request-access-token-with-authorization-grant-flow). This will allow users to be directed to ISC to login and then redirected back to the web application through a URL redirect. This also works well with Single Sign-on (SSO), strong authentication, and pass-through authentication mechanisms.
SailPoint doesn't recommend using a password grant flow for web applications because doing so would involve entering IDN credentials in the web application.
SailPoint doesn't recommend using a password grant flow for web applications because doing so would involve entering ISC credentials in the web application.
This flow also doesn't allow you to work with SSO, strong authentication, or pass-through authentication.
#### Scripts, programs or system to system integration
If you are writing scripts, programs or system integrations that leverage the IDN APIs, the OAuth 2.0 grant you should use typically depends on what you're doing and the user context you need to operate under.
If you are writing scripts, programs or system integrations that leverage the ISC APIs, the OAuth 2.0 grant you should use typically depends on what you're doing and the user context you need to operate under.
Because scripts, code, and programs lack an interactive web-interface, it is difficult, but not impossible, to implement a working authorization code grant flow. System to system integrations may require an elevated level of access and utilize a service account to make API calls beyond the privileges of the authenticated user.

2
docs/api/authorization.md
View File

@@ -23,7 +23,7 @@ Authorization and authentication are two related concepts that help secure APIs.
sequenceDiagram
autonumber
participant H as HTTP Client
participant I as IdentityNow
participant I as Identity Security Cloud
H->>I: Request to delete a source
I->>I: Authenticate access token

12
docs/api/getting-started.md
View File

@@ -13,7 +13,7 @@ tags: ['Getting Started']
## Overview
This guide is intended to help you quickly make your first API call to SailPoint IdentityNow and assumes an intermediate level of understanding of APIs. For beginners to APIs, we recommend you watch this presentation that covers the fundamentals of APIs with visual demonstrations of how to make an API call in SailPoint.
This guide is intended to help you quickly make your first API call to SailPoint Identity Security Cloud and assumes an intermediate level of understanding of APIs. For beginners to APIs, we recommend you watch this presentation that covers the fundamentals of APIs with visual demonstrations of how to make an API call in SailPoint.
<div class="text--center">
<iframe width="560" height="315" src="https://www.youtube.com/embed/YFRz8AcdWXg?si=9AvO6gMT1oCqYXAj" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
@@ -21,13 +21,13 @@ This guide is intended to help you quickly make your first API call to SailPoint
## Find Your Tenant Name
To form the proper URL for an API request, you must know your tenant name. To find your tenant name, log into IdentityNow, navigate to Admin, select the Dashboard dropdown, and select Overview. The org name is displayed within the Org Details section of the dashboard. If you do not have admin access, you can still find your tenant name and the API base URL you will use for API calls. To do so, view your session details when you are logged into your IdentityNow instance. Change your URL to the following: `https://{your-IdentityNow-hostname}.com/ui/session`, where `{your-IdentityNow-hostname}` is your company's domain name for accessing IdentityNow. The session detail you want is the `baseUrl`, which has the form of `https://{tenant}.api.identitynow.com`.
To form the proper URL for an API request, you must know your tenant name. To find your tenant name, log into Identity Security Cloud, navigate to Admin, select the Dashboard dropdown, and select Overview. The org name is displayed within the Org Details section of the dashboard. If you do not have admin access, you can still find your tenant name and the API base URL you will use for API calls. To do so, view your session details when you are logged into your Identity Security Cloud instance. Change your URL to the following: `https://{your-Identity Security Cloud-hostname}.com/ui/session`, where `{your-Identity Security Cloud-hostname}` is your company's domain name for accessing Identity Security Cloud. The session detail you want is the `baseUrl`, which has the form of `https://{tenant}.api.identitynow.com`.
## Make Your First API Call
To get started, create a [personal access token](./authentication.md#personal-access-tokens), which can then be used to generate access tokens to authenticate your API calls. To generate a personal access token from IdentityNow, after logging into your IdentityNow instance, do the following:
To get started, create a [personal access token](./authentication.md#personal-access-tokens), which can then be used to generate access tokens to authenticate your API calls. To generate a personal access token from Identity Security Cloud, after logging into your Identity Security Cloud instance, do the following:
1. Select **Preferences** from the drop-down menu under your username. Then select **Personal Access Tokens** on the left. You can also go straight to the page using this URL, replacing `{tenant}` with your IdentityNow tenant: `https://{tenant}.identitynow.com/ui/d/user-preferences/personal-access-tokens`.
1. Select **Preferences** from the drop-down menu under your username. Then select **Personal Access Tokens** on the left. You can also go straight to the page using this URL, replacing `{tenant}` with your Identity Security Cloud tenant: `https://{tenant}.identitynow.com/ui/d/user-preferences/personal-access-tokens`.
2. Select **New Token** and enter a meaningful description to differentiate the token from others.
@@ -47,13 +47,13 @@ The **New Token** button will be disabled when you reach the limit of 10 persona
4. Copy both values somewhere that will be secure and accessible to you when you need to use the the token.
5. To create an `access_token` that can be used to authenticate API requests, use the following cURL command, replacing `{tenant}` with your IdentityNow tenant. The response body will contain an `access_token`, which will look like a long string of random characters.
5. To create an `access_token` that can be used to authenticate API requests, use the following cURL command, replacing `{tenant}` with your Identity Security Cloud tenant. The response body will contain an `access_token`, which will look like a long string of random characters.
```bash
curl --location --request POST 'https://{tenant}.api.identitynow.com/oauth/token?grant_type=client_credentials&client_id={client_id}&client_secret={secret}'
```
6. To test your `access_token`, execute the following cURL command, replacing `{tenant}` with your IdentityNow tenant and `access_token` with the token you generated in the previous step. If this is successful, you should get a JSON representation of an identity in your tenant.
6. To test your `access_token`, execute the following cURL command, replacing `{tenant}` with your Identity Security Cloud tenant and `access_token` with the token you generated in the previous step. If this is successful, you should get a JSON representation of an identity in your tenant.
```bash
curl --request GET --url 'https://{tenant}.api.identitynow.com/v3/public-identities?limit=1' --header 'authorization: Bearer {access_token}'

8
docs/api/patch-requests.md
View File

@@ -12,7 +12,7 @@ tags: ['patch', 'guide']
## PATCH requests
You can use the IdentityNow APIs to update existing resources. Many of the APIs offer multiple ways to do so:
You can use the Identity Security Cloud APIs to update existing resources. Many of the APIs offer multiple ways to do so:
- You can send a **PUT** request to replace the existing resource with a new one. For example, if you wanted to update one of John Doe's source accounts, you could use the [Put Account](https://developer.sailpoint.com/docs/api/v3/put-account) endpoint to replace John Doe's existing source account with a new one. This is a viable way to update a resource, but it requires you to update the entire resource each time.
@@ -24,9 +24,9 @@ This guide will focus on the partial update method, PATCH requests. Read this gu
To use PATCH to update a resource, you first need to know the resource ID.
Not all resource IDs are available in the IdentityNow UI, so you may need to use the API to find the ID for the resource you want to update.
Not all resource IDs are available in the Identity Security Cloud UI, so you may need to use the API to find the ID for the resource you want to update.
For example, account IDs aren't avilable in the IdentityNow UI. If you want to use the [Patch Account](https://developer.sailpoint.com/docs/api/v3/update-account) endpoint to make a change to a specific account, you first need to find out the account's ID.
For example, account IDs aren't avilable in the Identity Security Cloud UI. If you want to use the [Patch Account](https://developer.sailpoint.com/docs/api/v3/update-account) endpoint to make a change to a specific account, you first need to find out the account's ID.
You can use the [List Accounts](https://developer.sailpoint.com/docs/api/v3/list-accounts) endpoint to view all the accounts in your tenant, along with their details, such as their identities. You can find your account and its ID in this list.
@@ -660,6 +660,6 @@ When the request is successful, the API will return the updated resource.
## Get started
Now you can use PATCH requests partially update resources. For more information about PATCH requests, refer to this [documentation](https://datatracker.ietf.org/doc/html/rfc6902). For more information about the IdentityNow PATCH endpoints and which paths can be changed for each one, refer to their API specifications.
Now you can use PATCH requests partially update resources. For more information about PATCH requests, refer to this [documentation](https://datatracker.ietf.org/doc/html/rfc6902). For more information about the Identity Security Cloud PATCH endpoints and which paths can be changed for each one, refer to their API specifications.
Use this guide to get started, and if you have questions, don't hesitate to reach out on the SailPoint Developer Community forum at https://developer.sailpoint.com/discuss!

8
docs/api/postman-collections.md
View File

@@ -13,11 +13,11 @@ tags: ['postman']
import GitHubPublicFileComponent from '@site/src/components/GitHubLink';
[Postman](https://www.postman.com/) is a platform you can use to design, build, test, and iterate your APIs. Postman users and teams can create public workspaces they can use to make it easy to access their API collections and environments and get started. SailPoint maintains a [public workspace for the IdentityNow API collections](https://www.postman.com/sailpoint/workspace/identitynow). You can use this workspace to access all the IDN API collections and stay up to date.
[Postman](https://www.postman.com/) is a platform you can use to design, build, test, and iterate your APIs. Postman users and teams can create public workspaces they can use to make it easy to access their API collections and environments and get started. SailPoint maintains a [public workspace for the Identity Security Cloud API collections](https://www.postman.com/sailpoint/workspace/identitynow). You can use this workspace to access all the ISC API collections and stay up to date.
## Run in Postman
Each IDN API version is broken out into a separate collection within the workspace. The following table lists the available IDN API collections. To import a collection into your workspace, select the 'Run in Postman' button for your desired version. Doing so forks the collection into your workspace.
Each ISC API version is broken out into a separate collection within the workspace. The following table lists the available ISC API collections. To import a collection into your workspace, select the 'Run in Postman' button for your desired version. Doing so forks the collection into your workspace.
@@ -34,7 +34,7 @@ When you fork the collection, when you check the 'Watch original collection' che
## Update your collections
SailPoint is often making improvements to the IDN API collections. To keep your workspace in sync with updates to one of SailPoint's public collections, you can right click on the forked collection and select "pull changes". sometimes this process will fail because of the size of our collection and limitations of the Postman tool. In that case, in order to update, you will need to visit the [sailpoint workspace](https://www.postman.com/sailpoint/workspace/identitynow) and create a fork of the most recently published version or click the links above to fork the most recent version.
SailPoint is often making improvements to the ISC API collections. To keep your workspace in sync with updates to one of SailPoint's public collections, you can right click on the forked collection and select "pull changes". sometimes this process will fail because of the size of our collection and limitations of the Postman tool. In that case, in order to update, you will need to visit the [sailpoint workspace](https://www.postman.com/sailpoint/workspace/identitynow) and create a fork of the most recently published version or click the links above to fork the most recent version.
## Configure your environment
@@ -47,7 +47,7 @@ To send API requests in Postman, you must authenticate to the APIs. To authentic
| Environment Variable | Required | Description |
| ----------- | ----------- | ----------- |
| tenant | Yes | Your IDN tenant, typically your company's name |
| tenant | Yes | Your ISC tenant, typically your company's name |
| clientId | Yes | The client ID for the API client or personal access token |
| clientSecret | Yes | The client secret for the API client or personal access token |
| domain | No | This optional field is only necessary for those who have a domain in their API URL that isn't "identitynow". |

4
docs/api/standard-collection-parameters.md
View File

@@ -10,7 +10,7 @@ description: ISC API pagination, filtering, and sorting.
tags: ['Standard Collection Parameters']
---
Many endpoints in the IdentityNow API support a generic syntax for paginating, filtering and sorting the results. A collection endpoint has the following characteristics:
Many endpoints in the Identity Security Cloud API support a generic syntax for paginating, filtering and sorting the results. A collection endpoint has the following characteristics:
- The HTTP verb is always GET.
- The last component in the URL is a plural noun (ex. `/v3/public-identities`).
@@ -34,7 +34,7 @@ Examples:
## Paginating Search Queries
The [search API](https://developer.sailpoint.com/docs/api/v3/search) in IdentityNow leverages [Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/elasticsearch-intro.html) functionality, which returns a maximum of 10,000 records by default. However, you can page more than 10,000 records by using the "searchAfter" property.
The [search API](https://developer.sailpoint.com/docs/api/v3/search) in Identity Security Cloud leverages [Elasticsearch](https://www.elastic.co/guide/en/elasticsearch/reference/current/elasticsearch-intro.html) functionality, which returns a maximum of 10,000 records by default. However, you can page more than 10,000 records by using the "searchAfter" property.
The `searchAfter` capability provides the ability to page on sorted field values, instead of offset paging. For example, if you sort by ID and page 100 records at a time, you can take the 1st page of 100 records, pass the last ID from that record set into your next search, and the next search will return the next 100 records after that ID. You continue that pattern of using the last value passed into `searchAfter` until the end of the result set. This allows you to page past the 10,000 record limit until you reach the final record.

18
docs/connectivity/saas-connectivity/common-cli-commands.md
View File

@@ -18,21 +18,21 @@ Below is a list of commands and their usages:
- Create a customizer on your local system `sail conn customizers init "my-customizer-project"`
- Test your connector or customizer locally: `npm run debug`
- **Deployment**
- Create an empty connector in your IDN Org (used to get id so you can upload): `sail conn create "my-project"`
- Create an empty customizer in your IDN Org (used to get id so you can upload): `sail conn customizers create "my-customizer-project"`
- Create an empty connector in your ISC Org (used to get id so you can upload): `sail conn create "my-project"`
- Create an empty customizer in your ISC Org (used to get id so you can upload): `sail conn customizers create "my-customizer-project"`
- Build a project: `npm run pack-zip`
- Upload your connector to your IDN Org: `sail conn upload -c [connectorID | connectorAlias] -f dist/[connector filename].zip`
- Upload your customizer to your IDN Org: `sail conn customizers upload -c [customizerID] -f dist/[customizer filename].zip`
- Upload your connector to your ISC Org: `sail conn upload -c [connectorID | connectorAlias] -f dist/[connector filename].zip`
- Upload your customizer to your ISC Org: `sail conn customizers upload -c [customizerID] -f dist/[customizer filename].zip`
- **Exploring**
- List connectors in your IDN Org: `sail conn list`
- List customizers in your IDN Org: `sail conn customizers list`
- List source instances in your IDN Org: `sail conn instances list`
- List connectors in your ISC Org: `sail conn list`
- List customizers in your ISC Org: `sail conn customizers list`
- List source instances in your ISC Org: `sail conn instances list`
- List your connector tags: `sail conn tags list -c [connectorID | connectorAlias]`
- **Testing and Debugging**
- Test your connector on the IDN Org: `sail connectors invoke [action] -c [connectorID | connectorAlias] -p config.json`
- Test your connector on the ISC Org: `sail connectors invoke [action] -c [connectorID | connectorAlias] -p config.json`
- Get a list of actions: `sail conn invoke -h`
- Run read-only integration tests against your connector: `sail conn validate -p config.json -c [connectorID | connectorAlias] -r`
- Tail IDN Org connector logs: `sail conn logs tail`
- Tail ISC Org connector logs: `sail conn logs tail`
- **Delete**
- Delete a connector: `sail conn delete -c [connectorID | connectorAlias]`
- **Linking**

12
docs/connectivity/saas-connectivity/connector-commands/account-create.md
View File

@@ -57,13 +57,13 @@ tags: ['Connectivity', 'Connector Command']
## Description
The account create command triggers whenever IDN is told to provision entitlements for an identity on the target source, but no account for the identity on the target source exists yet. For example, if you create an access profile that grants a group on the target source and then add that access profile to a role, any identity matching that role’s membership criteria will be granted to the group. IDN determines which identities do not have accounts on the target source and triggers the account create command for each identity. If an identity already has an account, then it invokes the account update command.
The account create command triggers whenever ISC is told to provision entitlements for an identity on the target source, but no account for the identity on the target source exists yet. For example, if you create an access profile that grants a group on the target source and then add that access profile to a role, any identity matching that role’s membership criteria will be granted to the group. ISC determines which identities do not have accounts on the target source and triggers the account create command for each identity. If an identity already has an account, then it invokes the account update command.
## The Provisioning Plan
The account create command accepts a provisioning plan from IDN and creates the corresponding account(s) in the target source. When you configure your source in IDN, you must set up ‘Create Profile’ to tell IDN how to provision new accounts for your source.
The account create command accepts a provisioning plan from ISC and creates the corresponding account(s) in the target source. When you configure your source in ISC, you must set up ‘Create Profile’ to tell ISC how to provision new accounts for your source.
You can create the provisioning plan through the `accountCreateTemplate` in the `connector-spec.json` file, and you can also modify its behavior in IDN using the create profile screen:
You can create the provisioning plan through the `accountCreateTemplate` in the `connector-spec.json` file, and you can also modify its behavior in ISC using the create profile screen:
![Account Create](./img/account_create_idn.png)
@@ -177,7 +177,7 @@ public static createWithStdAccountCreateInput(record: StdAccountCreateInput): Ai
## The return object
When the account is returned to IDN, any values you set are updated in IDN. So if an account ID is auto-generated on the source system, you must send the account ID back to IDN so IDN is aware of it for future account update activities. This is useful for the compound key type.
When the account is returned to ISC, any values you set are updated in ISC. So if an account ID is auto-generated on the source system, you must send the account ID back to ISC so ISC is aware of it for future account update activities. This is useful for the compound key type.
## Password Handling
@@ -224,9 +224,9 @@ async createAccount(input: StdAccountCreateInput): Promise<AirtableAccount> {
}
```
## Testing in IdentityNow
## Testing in Identity Security Cloud
One way to test whether the account create code works in IDN is to set up an access profile and role that grants members an entitlement from the connector’s target source. Start by creating an access profile that grants one or more entitlements from the target source.
One way to test whether the account create code works in ISC is to set up an access profile and role that grants members an entitlement from the connector’s target source. Start by creating an access profile that grants one or more entitlements from the target source.
![Testing 1](./img/testing1.png)

4
docs/connectivity/saas-connectivity/connector-commands/account-delete.md
View File

@@ -36,9 +36,9 @@ tags: ['Connectivity', 'Connector Command']
## Description
The account delete command sends one attribute from IDN, the identity to delete. This can be passed to your connector to delete the account from the source system.
The account delete command sends one attribute from ISC, the identity to delete. This can be passed to your connector to delete the account from the source system.
Enable account delete in IDN through a BeforeProvisioning rule. The connector honors whichever operation the provisioning plan sends. For more information, see the [documentation](https://community.sailpoint.com/t5/IdentityNow-Articles/IdentityNow-Rule-Guide/ta-p/76665) and an [example implementation](https://community.sailpoint.com/t5/IdentityNow-Wiki/IdentityNow-Rule-Guide-Before-Provisioning-Rule/ta-p/77415).
Enable account delete in ISC through a BeforeProvisioning rule. The connector honors whichever operation the provisioning plan sends. For more information, see the [documentation](https://community.sailpoint.com/t5/Identity Security Cloud-Articles/Identity Security Cloud-Rule-Guide/ta-p/76665) and an [example implementation](https://community.sailpoint.com/t5/Identity Security Cloud-Wiki/Identity Security Cloud-Rule-Guide-Before-Provisioning-Rule/ta-p/77415).
The following snippet shows an example of account delete command implementation:

2
docs/connectivity/saas-connectivity/connector-commands/account-disable.md
View File

@@ -54,7 +54,7 @@ You typically invoke the `account disable` command during the joiner, mover, lea
Disabling accounts is generally preferred if the source supports account disabling so the account data remains for later reactivation or inspection. If the source does not support account disabling, or deleting accounts is preferred when an identity leaves the organization, the connector can perform the necessary steps to delete an account with the account disable function.
> 🚧 It is important to note that although SaaS Connectivity supports the account delete command, IDN never sends the account delete command, only the account disable command. The connector’s developer determines the appropriate action for account disable on the source.
> 🚧 It is important to note that although SaaS Connectivity supports the account delete command, ISC never sends the account delete command, only the account disable command. The connector’s developer determines the appropriate action for account disable on the source.
Account disable is similar to implementing the account update command. If you have implemented your source call to modify any of the values on your source, then you can use the same method to implement the command. The following code implements disable:

12
docs/connectivity/saas-connectivity/connector-commands/account-discover.md
View File

@@ -51,7 +51,7 @@ tags: ['Connectivity', 'Connector Command']
## Description
The account discover schema command tells IDN to dynamically create the account schema for the source rather than use the account schema provided by the connector in connector-spec.json. It is often ideal to statically define the account schema because it is generally more performant and easier to develop and reason about the code. However, some sources have schemas that can be different for each customer deployment. It can also be difficult to determine which account attributes to statically expose, which requires the schema to be dynamically generated. SalesForce is an example of a source that can have thousands of account attributes, which makes it impractical to statically define a set of attributes that satisfies all connector users. Although the SalesForce connector defines a standard set of account attributes out of the box, it also allows schema discovery for users looking for more attributes.
The account discover schema command tells ISC to dynamically create the account schema for the source rather than use the account schema provided by the connector in connector-spec.json. It is often ideal to statically define the account schema because it is generally more performant and easier to develop and reason about the code. However, some sources have schemas that can be different for each customer deployment. It can also be difficult to determine which account attributes to statically expose, which requires the schema to be dynamically generated. SalesForce is an example of a source that can have thousands of account attributes, which makes it impractical to statically define a set of attributes that satisfies all connector users. Although the SalesForce connector defines a standard set of account attributes out of the box, it also allows schema discovery for users looking for more attributes.
## Implementation
@@ -229,7 +229,7 @@ export const connector = async () => {
}
```
Next, implement the `discoverSchema()` function in your client code. The following function calls the necessary endpoints to get the full schema of the user account you want to represent in IDN. After you receive a response from your call, you must build your account schema object that will return to IDN. The response has a structure like the accountSchema property in the connector-spec.json file. The following is an example from [airtable.ts](https://github.com/sailpoint-oss/airtable-example-connector/blob/main/src/airtable.ts).
Next, implement the `discoverSchema()` function in your client code. The following function calls the necessary endpoints to get the full schema of the user account you want to represent in ISC. After you receive a response from your call, you must build your account schema object that will return to ISC. The response has a structure like the accountSchema property in the connector-spec.json file. The following is an example from [airtable.ts](https://github.com/sailpoint-oss/airtable-example-connector/blob/main/src/airtable.ts).
```javascript
async getAccountSchema(): Promise<StdAccountDiscoverSchemaOutput> {
@@ -276,7 +276,7 @@ async getAccountSchema(): Promise<StdAccountDiscoverSchemaOutput> {
}
```
This code produces the following payload that will be sent back to IDN.
This code produces the following payload that will be sent back to ISC.
```javascript
{
@@ -343,9 +343,9 @@ This code produces the following payload that will be sent back to IDN.
There are many properties in this payload, so you may want to remove some, but it can be hard to determine which properties to keep in a dynamic way. If you can programmatically determine which properties to remove, you can alter the `discoverSchema()` function to remove them.
## Test in IdentityNow
## Test in Identity Security Cloud
To test the account discover schema command in IDN, ensure that you upload your latest connector code and create a new source in IDN. After you configure and test your source connection, go to the ‘Account Schema’ page. You will see an empty schema.
To test the account discover schema command in ISC, ensure that you upload your latest connector code and create a new source in ISC. After you configure and test your source connection, go to the ‘Account Schema’ page. You will see an empty schema.
![Discover Schema 1](./img/discover_schema_idn1.png)
@@ -353,7 +353,7 @@ To discover the schema for this source, click the ‘Options’ dropdown in the
![Discover Schema 2](./img/discover_schema_idn2.png)
IDN then asks you to assign attributes to ‘Account ID’ and 'Account Name.'
ISC then asks you to assign attributes to ‘Account ID’ and 'Account Name.'
![Discover Schema 3](./img/discover_schema_idn3.png)

14
docs/connectivity/saas-connectivity/connector-commands/account-list.md
View File

@@ -4,7 +4,7 @@ title: Account List
pagination_label: Account List
sidebar_label: Account List
keywords: ['connectivity', 'connectors', 'account list']
description: Aggregate all accounts from the source into IdentityNow.
description: Aggregate all accounts from the source into Identity Security Cloud.
slug: /connectivity/saas-connectivity/commands/account-list
tags: ['Connectivity', 'Connector Command']
---
@@ -47,7 +47,7 @@ tags: ['Connectivity', 'Connector Command']
## Description
The account list command aggregates all accounts from the target source into IdentityNow. IDN calls this command during a manual or scheduled account aggregation.
The account list command aggregates all accounts from the target source into Identity Security Cloud. ISC calls this command during a manual or scheduled account aggregation.
![Account List](./img/account_list_idn.png)
@@ -73,13 +73,13 @@ async getAllAccounts(): Promise<AirtableAccount[]> {
:::caution Important
IDN will throw a connection timeout error if your connector doesn't respond within 3 minutes, and there are memory limitations involved with aggregating data. To prevent large memory utilization or timeout errors, you should set up your connectors to send data to IDN as it's retrieved from your source system. For more details and an example, refer to [Connector Timeouts](../in-depth/connector-timeouts.md).
ISC will throw a connection timeout error if your connector doesn't respond within 3 minutes, and there are memory limitations involved with aggregating data. To prevent large memory utilization or timeout errors, you should set up your connectors to send data to ISC as it's retrieved from your source system. For more details and an example, refer to [Connector Timeouts](../in-depth/connector-timeouts.md).
:::
:::caution Important
IDN supports [delta aggregation](#delta-aggregation-state). If your source has a large number of accounts that will be syncronized with IDN, then it is highly recommended to utilize [delta aggregation](#delta-aggregation-state) for the source.
ISC supports [delta aggregation](#delta-aggregation-state). If your source has a large number of accounts that will be syncronized with ISC, then it is highly recommended to utilize [delta aggregation](#delta-aggregation-state) for the source.
:::
@@ -105,7 +105,7 @@ export const connector = async () => {
...
```
IDN expects each user in the target source to be converted into a format IDN understands. The specific attributes the web service returns depend on what your source provides.
ISC expects each user in the target source to be converted into a format ISC understands. The specific attributes the web service returns depend on what your source provides.
```javascript
public toStdAccountListOutput(): StdAccountListOutput {
@@ -130,7 +130,7 @@ private buildStandardObject(): StdAccountListOutput | StdAccountCreateOutput | S
}
```
The result of the account list command is not an array of objects but several individual objects. This is the format IDN expects, so if you see something like the following result while testing, it is normal:
The result of the account list command is not an array of objects but several individual objects. This is the format ISC expects, so if you see something like the following result while testing, it is normal:
```javascript
{
@@ -193,7 +193,7 @@ If your source can keep track of changes to the data in some way, then delta agg
}
```
2. In the ```stdAccountList``` command, when you are done sending accounts, you need to also send the state to IDN so it knows where to start the next time it sends a list request:
2. In the ```stdAccountList``` command, when you are done sending accounts, you need to also send the state to ISC so it knows where to start the next time it sends a list request:
```javascript
const state = {"data": Date.now().toString()}

6
docs/connectivity/saas-connectivity/connector-commands/account-read.md
View File

@@ -4,7 +4,7 @@ title: Account Read
pagination_label: Account Read
sidebar_label: Account Read
keywords: ['connectivity', 'connectors', 'account read']
description: Aggregate a single account from the source into IdentityNow.
description: Aggregate a single account from the source into Identity Security Cloud.
slug: /connectivity/saas-connectivity/commands/account-read
tags: ['Connectivity', 'Connector Command']
---
@@ -50,7 +50,7 @@ tags: ['Connectivity', 'Connector Command']
## Description
The account read command aggregates a single account from the target source into IdentityNow. IDN can call this command during a “one-off” account refresh, which you can trigger by aggregating an individual account in IDN.
The account read command aggregates a single account from the target source into Identity Security Cloud. ISC can call this command during a “one-off” account refresh, which you can trigger by aggregating an individual account in ISC.
![Account Read](./img/account_read_idn.png)
@@ -84,7 +84,7 @@ async getAccount(identity: SimpleKeyType | CompoundKeyType): Promise<AirtableAcc
}
```
One special case of this command is the `NotFound` type. On line 20, if an account is not found, the `ConnectorError` is thrown with the `ConnectorErrorType.NotFound` type. This tells IDN the account does not exist, and IDN then triggers the account create logic to generate the account.
One special case of this command is the `NotFound` type. On line 20, if an account is not found, the `ConnectorError` is thrown with the `ConnectorErrorType.NotFound` type. This tells ISC the account does not exist, and ISC then triggers the account create logic to generate the account.
The following code snippet from [index.ts](https://github.com/sailpoint-oss/airtable-example-connector/blob/main/src/index.ts) shows how to register the account read command on the connector object:

2
docs/connectivity/saas-connectivity/connector-commands/account-unlock.md
View File

@@ -50,7 +50,7 @@ tags: ['Connectivity', 'Connector Command']
## Description
The account lock and account unlock commands provide ways to temporarily prevent access to an account. IDN only supports the unlock command, so accounts must be locked on the source level, but they can be unlocked through IDN, and IDN can store the account's status.
The account lock and account unlock commands provide ways to temporarily prevent access to an account. ISC only supports the unlock command, so accounts must be locked on the source level, but they can be unlocked through ISC, and ISC can store the account's status.
Implementing account unlock is similar to the other commands that update attributes on an account. The following code unlocks an account:

14
docs/connectivity/saas-connectivity/connector-commands/account-update.md
View File

@@ -59,11 +59,11 @@ tags: ['Connectivity', 'Connector Command']
## Description
The account update command triggers whenever IDN is told to modify an identity's attributes or entitlements on the target source. For example, granting an identity a new entitlement through a role, changing an identity’s lifecycle state, or modifying an identity attribute tied to an account attribute all trigger the account update command.
The account update command triggers whenever ISC is told to modify an identity's attributes or entitlements on the target source. For example, granting an identity a new entitlement through a role, changing an identity’s lifecycle state, or modifying an identity attribute tied to an account attribute all trigger the account update command.
## Input Schema
The payload from IDN contains the ID of the identity to modify, the configuration items the connector needs to call the source API, and one or more change operations to apply to the identity. Each operation has the following special considerations:
The payload from ISC contains the ID of the identity to modify, the configuration items the connector needs to call the source API, and one or more change operations to apply to the identity. Each operation has the following special considerations:
- **Set:** Set tells the connector to overwrite the current value of the attribute or entitlement with the new value provided in the payload. The entire entitlement array resets if there are multi-valued entitlements.
@@ -95,14 +95,14 @@ The following example payload tells the connector to perform the following updat
## Response Schema
After the connector applies the operations defined in the input payload, the connector must respond to IDN with the changes to the account so IDN can update the identity accordingly. If an account update operation results in no changes to the account, the connector responds with an empty object `{}`. If the update operation results in one or more changes to the account, the connector responds with the complete account as it exists in the source, just like an account read response. IDN can parse the response and apply the differences accordingly.
After the connector applies the operations defined in the input payload, the connector must respond to ISC with the changes to the account so ISC can update the identity accordingly. If an account update operation results in no changes to the account, the connector responds with an empty object `{}`. If the update operation results in one or more changes to the account, the connector responds with the complete account as it exists in the source, just like an account read response. ISC can parse the response and apply the differences accordingly.
## Testing in IdentityNow
## Testing in Identity Security Cloud
You can test the account update command the way you test the [Account Create](./account-create.md) command. Follow the steps in “Testing in IdentityNow” from “Account Create” to set up an access profile and role. Be sure to run the aggregation so the account(s) are created in the target source. Once the account(s) are created in the target source, modify the access profile to grant an additional entitlement. Return to the role and click the ‘Update’ button in the upper right corner. Doing so triggers the account update command because the accounts are already created in the target source. Once the update is complete, ensure the account(s) have the additional entitlement.
You can test the account update command the way you test the [Account Create](./account-create.md) command. Follow the steps in “Testing in Identity Security Cloud” from “Account Create” to set up an access profile and role. Be sure to run the aggregation so the account(s) are created in the target source. Once the account(s) are created in the target source, modify the access profile to grant an additional entitlement. Return to the role and click the ‘Update’ button in the upper right corner. Doing so triggers the account update command because the accounts are already created in the target source. Once the update is complete, ensure the account(s) have the additional entitlement.
Note: Testing the account update command for removing entitlements using this method does not work. You can remove the entitlement from the access profile and run an update, but IDN will not send an update command to the connector to remove the entitlement. We are looking for suggestions on how to test the removal of entitlements.
Note: Testing the account update command for removing entitlements using this method does not work. You can remove the entitlement from the access profile and run an update, but ISC will not send an update command to the connector to remove the entitlement. We are looking for suggestions on how to test the removal of entitlements.
## Handling an account that is not found
If an account can't be found in the source system, IDN can recreate the account by using the ```ConnectorErrorType.NotFound``` error type. For details and implementation, refer to [Error Handling](../in-depth/error-handling.md#not-found-error-type).
If an account can't be found in the source system, ISC can recreate the account by using the ```ConnectorErrorType.NotFound``` error type. For details and implementation, refer to [Error Handling](../in-depth/error-handling.md#not-found-error-type).

6
docs/connectivity/saas-connectivity/connector-commands/change-password.md
View File

@@ -34,7 +34,7 @@ tags: ['Connectivity', 'Connector Command']
## Description
The change password command is triggered in IDN when a user changes their password through IDN. When this occurs, if your source has change password enabled, then you can change the user password on the source system through IDN.
The change password command is triggered in ISC when a user changes their password through ISC. When this occurs, if your source has change password enabled, then you can change the user password on the source system through ISC.
## The Provisioning Plan
@@ -46,6 +46,6 @@ The change password command sends the password change event to your connector wh
})
```
## Testing in IdentityNow
## Testing in Identity Security Cloud
In order to test in IdentityNow, the source application must be configured so that it is able to accept password change requests through the Password Manager. Once this setup is complete, you can log in as a user whose identity exists in the configured application and change their password in the Password Manager.
In order to test in Identity Security Cloud, the source application must be configured so that it is able to accept password change requests through the Password Manager. Once this setup is complete, you can log in as a user whose identity exists in the configured application and change their password in the Password Manager.

8
docs/connectivity/saas-connectivity/connector-commands/entitlement-list.md
View File

@@ -42,7 +42,7 @@ tags: ['Connectivity', 'Connector Command']
## Description
The entitlement list command triggers during a manual or scheduled entitlement aggregation operation within IDN. This operation gathers a list of all entitlements available on the target source, usually multi-valued entitlements like groups or roles. This operation provides IDN administrators with a list of entitlements available on the source so they can create access profiles and roles accordingly, and it provides IDN with more details about the entitlements. The entitlement schema’s minimum requirements are name and ID, but you can add other values, such as created date, updated date, status, etc.
The entitlement list command triggers during a manual or scheduled entitlement aggregation operation within ISC. This operation gathers a list of all entitlements available on the target source, usually multi-valued entitlements like groups or roles. This operation provides ISC administrators with a list of entitlements available on the source so they can create access profiles and roles accordingly, and it provides ISC with more details about the entitlements. The entitlement schema’s minimum requirements are name and ID, but you can add other values, such as created date, updated date, status, etc.
![Discover Schema 4](./img/entitlement_list_idn.png)
@@ -106,13 +106,13 @@ private buildStandardObject(): StdEntitlementReadOutput | StdEntitlementListOutp
```
:::caution Important
IDN will throw a connection timeout error if your connector doesn't respond within 3 minutes, and there are memory limitations involved with aggregating data. To prevent large memory utilization or timeout errors, you should set up your connectors to send data to IDN as it's retrieved from your source system. For more details and an example, refer to [Connector Timeouts](../in-depth/connector-timeouts.md).
ISC will throw a connection timeout error if your connector doesn't respond within 3 minutes, and there are memory limitations involved with aggregating data. To prevent large memory utilization or timeout errors, you should set up your connectors to send data to ISC as it's retrieved from your source system. For more details and an example, refer to [Connector Timeouts](../in-depth/connector-timeouts.md).
:::
:::caution Important
IDN supports [delta aggregation](#delta-aggregation-state). If your source has a large number of entitlements that will be syncronized with IDN, then it is highly recommended to utilize [delta aggregation](#delta-aggregation-state) for the source.
ISC supports [delta aggregation](#delta-aggregation-state). If your source has a large number of entitlements that will be syncronized with ISC, then it is highly recommended to utilize [delta aggregation](#delta-aggregation-state) for the source.
:::
@@ -133,7 +133,7 @@ If your source can keep track of changes to the data in some way, then delta agg
}
```
2. In the ```stdEntitlementList``` command, when you are done sending entitlments, you need to also send the state to IDN so it knows where to start the next time it sends a list request:
2. In the ```stdEntitlementList``` command, when you are done sending entitlments, you need to also send the state to ISC so it knows where to start the next time it sends a list request:
```javascript
const state = {"data": Date.now().toString()}

4
docs/connectivity/saas-connectivity/connector-commands/entitlement-read.md
View File

@@ -11,7 +11,7 @@ tags: ['Connectivity', 'Connector Command']
:::note
At this time Entitlement Read is not triggered from IDN for any specific workflow and as such it is not necessary to implement this in order to have a fully functional connector.
At this time Entitlement Read is not triggered from ISC for any specific workflow and as such it is not necessary to implement this in order to have a fully functional connector.
:::
@@ -54,7 +54,7 @@ At this time Entitlement Read is not triggered from IDN for any specific workflo
## Response Schema
Entitlement read fetches a single entitlement’s attributes and returns the resulting object to IDN, similar to how entitlement list does. You can implement this in the main connector file, [index.ts](https://github.com/sailpoint-oss/airtable-example-connector/blob/main/src/index.ts):
Entitlement read fetches a single entitlement’s attributes and returns the resulting object to ISC, similar to how entitlement list does. You can implement this in the main connector file, [index.ts](https://github.com/sailpoint-oss/airtable-example-connector/blob/main/src/index.ts):
```javascript
...

4
docs/connectivity/saas-connectivity/connector-commands/source-data-discover.md
View File

@@ -44,9 +44,9 @@ tags: ['Connectivity', 'Connector Command']
## Description
Use the source data discover command to identify the types of data your source can return. Different sources can send different types of data to IdentityNow. For example, one source may be able to send a list of the different languages it supports, while another may be able to send values describing source details normally sent through accounts and entitlements. You can use the source data discover command to discover these possibilities.
Use the source data discover command to identify the types of data your source can return. Different sources can send different types of data to Identity Security Cloud. For example, one source may be able to send a list of the different languages it supports, while another may be able to send values describing source details normally sent through accounts and entitlements. You can use the source data discover command to discover these possibilities.
One typical use for the source data discover command is found in IdentityNow customer forms for dropdown menus: they use the command to identify the additional source types their sources can provide to IdentityNow and use that information to populate the dropdown menus.
One typical use for the source data discover command is found in Identity Security Cloud customer forms for dropdown menus: they use the command to identify the additional source types their sources can provide to Identity Security Cloud and use that information to populate the dropdown menus.
This is a simple example of the source data discover command. It has been implemented to list two types of queries that the Airtable source can supply.

2
docs/connectivity/saas-connectivity/connector-commands/source-data-read.md
View File

@@ -45,7 +45,7 @@ tags: ['Connectivity', 'Connector Command']
## Description
Use the source data read command to query a source in IdentityNow and return a set of data. This data is typically used to populate a dropdown menu for selection purposes. This functionality is typically useful for IdentityNow forms, but it can be used for any type of implementation that requires you to get other information from a source, information that is not normally retrieved from identites or entitlements.
Use the source data read command to query a source in Identity Security Cloud and return a set of data. This data is typically used to populate a dropdown menu for selection purposes. This functionality is typically useful for Identity Security Cloud forms, but it can be used for any type of implementation that requires you to get other information from a source, information that is not normally retrieved from identites or entitlements.
This is a simple example of the source data read command. It is implemented to retrieve the base ID name. The `sourceDataKey` is required, the ```source data read``` command should return it.

2
docs/connectivity/saas-connectivity/connector-commands/test-connection.md
View File

@@ -25,7 +25,7 @@ tags: ['Connectivity', 'Connector Command']
The test connection command ensures the connector can communicate with the target web service. It validates API credentials, host names, ports, and other configuration items. To implement this command, look for either a health endpoint or a simple GET endpoint. Some web services implement a health endpoint that returns status information about the service, which can be useful to test a connection. If no health endpoint exists, use a simple GET endpoint that takes few to no parameters to ensure the connector can make a successful call to the web service.
Use ‘Test Connection’ in the IDN UI after an admin has finished entering configuration information for a new instance of the connector.
Use ‘Test Connection’ in the ISC UI after an admin has finished entering configuration information for a new instance of the connector.
![Test Connection](./img/test_command_idn.png)

10
docs/connectivity/saas-connectivity/connector-customizers/index.md
View File

@@ -13,11 +13,11 @@ tags: ['Connectivity']
# Overview
SaaS Connectivity Customizers are cloud-based connector customizers that make customizing out of the box SaaS connectors possible. The customizers allow you to customize the out of the box connectors in a similar way to how you can use rules to customize VA (virtual appliance) based connectors. By using a customizer, you can change a connector's input before the connector ingests the data, or you can change the connector's output before to the output is sent to IdentityNow.
SaaS Connectivity Customizers are cloud-based connector customizers that make customizing out of the box SaaS connectors possible. The customizers allow you to customize the out of the box connectors in a similar way to how you can use rules to customize VA (virtual appliance) based connectors. By using a customizer, you can change a connector's input before the connector ingests the data, or you can change the connector's output before to the output is sent to Identity Security Cloud.
## How do they work?
SaaS Connectivity Customizers work by sitting in between IdentityNow and the connector. They intercept calls from IdentityNow to the connector and calls from the connector to IdentityNow. When the customizer intercepts a call, it can call custom code to mutate the data in any way necessary to change the connector behavior.
SaaS Connectivity Customizers work by sitting in between Identity Security Cloud and the connector. They intercept calls from Identity Security Cloud to the connector and calls from the connector to Identity Security Cloud. When the customizer intercepts a call, it can call custom code to mutate the data in any way necessary to change the connector behavior.
This chart shows an example of this interception process - the ```stdAccountRead``` command is implemented with the customizer in place:
@@ -26,14 +26,14 @@ This chart shows an example of this interception process - the ```stdAccountRead
```mermaid
sequenceDiagram
autonumber
participant IDN as IdentityNow
participant ISC as Identity Security Cloud
participant CUS as Customizer
participant CON as SaaS Connector
IDN->>CUS: StdAccountRead Request
ISC->>CUS: StdAccountRead Request
CUS->>CON: Mutated StdAccountRead Request
CON->>CUS: StdAccountRead Response
CUS->>IDN: Mutated StdAccountRead Response
CUS->>ISC: Mutated StdAccountRead Response
```

2
docs/connectivity/saas-connectivity/connector-customizers/link.md
View File

@@ -15,7 +15,7 @@ tags: ['Connectivity']
### Initial requirements
Before you can link a connector customizer to a source, you must have a SaaS source in IdentityNow, as well as a Customizer built and deployed. You can use the following commands to get a list of valid sources, as well as customizers:
Before you can link a connector customizer to a source, you must have a SaaS source in Identity Security Cloud, as well as a Customizer built and deployed. You can use the following commands to get a list of valid sources, as well as customizers:
Use this command to find sources:

8
docs/connectivity/saas-connectivity/connector-customizers/upload.md
View File

@@ -1,6 +1,6 @@
---
id: connectivity-customizers-uploading
title: Build and Upload into Identity Now
title: Build and Upload into Identity Security Cloud
pagination_label: Build and Upload
sidebar_label: Build and Upload
sidebar_position: 5
@@ -11,7 +11,7 @@ slug: /connectivity/saas-connectivity/customizers/upload
tags: ['Connectivity']
---
# Building and uploading to Identity Now
# Building and uploading to Identity Security Cloud
### Initial requirements
@@ -48,9 +48,9 @@ After the build is complete, you will see a message like this:
Connector zip file created under dist folder: my-connector-customizer-0.1.0.zip
```
### Upload to IdentityNow
### Upload to Identity Security Cloud
To upload the customizer to IdentityNow, use the upload command:
To upload the customizer to Identity Security Cloud, use the upload command:
```bash
sail conn customizers upload -c 7b968fab-0f40-49f0-b13b-8bf529fc0b82 -f .\dist\my-connector-customizer-0.1.0.zip

34
docs/connectivity/saas-connectivity/connector-spec/index.md
View File

@@ -6,14 +6,14 @@ sidebar_label: Connector Spec File
sidebar_position: 4
sidebar_class_name: connectorSpecFile
keywords: ['connectivity', 'connectors', 'spec', 'specification']
description: The connector spec file tells IDN how the connector should interact between IDN and the custom connector. It is the glue between IDN and the connector, so understanding the different sections are key to understanding how to build a custom connectors.
description: The connector spec file tells ISC how the connector should interact between ISC and the custom connector. It is the glue between ISC and the connector, so understanding the different sections are key to understanding how to build a custom connectors.
slug: /connectivity/saas-connectivity/connector-spec
tags: ['Connectivity']
---
## Summary
The connector spec file tells IDN how the connector should interact between IDN and the custom connector. It is the glue between IDN and the connector, so understanding the different sections are key to understanding how to build a custom connectors.
The connector spec file tells ISC how the connector should interact between ISC and the custom connector. It is the glue between ISC and the connector, so understanding the different sections are key to understanding how to build a custom connectors.
## Sample File
@@ -23,7 +23,7 @@ To see a sample spec file, see this link: [connector-spec.json](https://github.c
The following describes in detail the different fields in the connector spec:
- **name:** The name of the connector as it appears in IDN. Tags can be appended to this name.
- **name:** The name of the connector as it appears in ISC. Tags can be appended to this name.
- **keyType:** Either “simple” or “compound” This determines which type of key your connector expects to receive and send back for each of the commands. This must always be indicated in your connector spec - the connector returns the correct type for each command that returns a key type.
@@ -31,9 +31,9 @@ The following describes in detail the different fields in the connector spec:
- **commands:** The list of commands the connector supports. A full list of available commands can be found [here](../connector-commands/index.md).
- **[sourceConfigInitialValues](./connector-spec/initial-value):** Key value pair of source config item keys and the default value that should be associated with them.
- **sourceConfig** A list of configuration items you must provide when you create a source in IDN. The order of these items is preserved in the UI.
- **sourceConfig** A list of configuration items you must provide when you create a source in ISC. The order of these items is preserved in the UI.
- **type:** This is always “menu” - it indicates a new menu for the sidebar. You can have multiple sections defined for complex connector configurations
- **label:** This label indicates the text that will show up on the sidebar in IDN
- **label:** This label indicates the text that will show up on the sidebar in ISC
- **items:** The array of items in the menu
- **type:** This is always "section" - it indicates a new section on the page
- **sectionTitle:** The large text title that will display for the section.
@@ -42,7 +42,7 @@ The following describes in detail the different fields in the connector spec:
- **docLink:** The optional link that the docLinkLabel will direct to if clicked.
- **key:** The name of the configuration item as it is referenced in code.
- **label:** The name of the configuration item as it appears in the UI.
- **required** (Optional): Set to 'false' by default. Valid values are 'true' or 'false.' You must populate required configuration items in the IDN source configuration wizard before continuing.
- **required** (Optional): Set to 'false' by default. Valid values are 'true' or 'false.' You must populate required configuration items in the ISC source configuration wizard before continuing.
- **type:** The configuration items' types. The following types are valid:
- text
- number
@@ -57,27 +57,27 @@ The following describes in detail the different fields in the connector spec:
- [list](./connector-spec/list)
- [keyValue](./connector-spec/key-value)
- [cardList](./connector-spec/card)
- **accountSchema:** The schema for an account in IDN populated by data from the source.
- **displayAttribute:** Identifies the attribute (defined below) used to map to `Account Name` in the IdentityNow account schema. This should be a unique value even though it is not required because the connector will use this value to correlate accounts in IDN to accounts in the source system.
- **identityAttribute:** Identifies the attribute (defined below) used to map to `Account ID` in the IdentityNow account schema. This must be a globally unique identifier, such as email address, employee ID, etc.
- **accountSchema:** The schema for an account in ISC populated by data from the source.
- **displayAttribute:** Identifies the attribute (defined below) used to map to `Account Name` in the Identity Security Cloud account schema. This should be a unique value even though it is not required because the connector will use this value to correlate accounts in ISC to accounts in the source system.
- **identityAttribute:** Identifies the attribute (defined below) used to map to `Account ID` in the Identity Security Cloud account schema. This must be a globally unique identifier, such as email address, employee ID, etc.
- **groupAttribute:** Identifies the attribute used to map accounts to entitlements. For example, a web service can define `groups` that users are members of, and the `groups` grant entitlements to each user. In this case, **groupAttribute** is “groups,” and there is also an account attribute called “groups”.
- **attributes:** One or more attributes that map to a user’s attribute on the target source. Each attribute defines the following:
- **name:** The attribute’s name as it appears in IDN.
- **name:** The attribute’s name as it appears in ISC.
- **type:** The attribute’s type. Possible values are `string`, `boolean`, `long`, and `int`.
- **description:** A helpful description of the attribute. This is useful to source owners when they are trying to understand the account schema.
- **managed:** This indicates whether the entitlements are manageable through IDN or read-only.
- **entitlement:** This boolean indicates whether the attribute is an entitlement. Entitlements give identities privileges on the source system. Use this indication to determine which fields to synchronize with accounts in IDN for tasks such as separation of duties and role assignment. The boolean indicates whether the attribute is an entitlement.
- **managed:** This indicates whether the entitlements are manageable through ISC or read-only.
- **entitlement:** This boolean indicates whether the attribute is an entitlement. Entitlements give identities privileges on the source system. Use this indication to determine which fields to synchronize with accounts in ISC for tasks such as separation of duties and role assignment. The boolean indicates whether the attribute is an entitlement.
- **multi:** This indicates entitlements that are stored in an array format. This one field can store multiple entitlements for a single account.
- **entitlementSchemas:** A list of entitlement schemas in IDN populated by data from the source.
- **entitlementSchemas:** A list of entitlement schemas in ISC populated by data from the source.
- **type:** The entitlement’s type. Currently, only `group` is supported.
- **displayAttribute:** The entitlement attribute’s name. This can be the `name` or another human friendly identifier for a group.
- **identityAttribute:** The entitlement attribute’s unique ID. This can be the `id` or another unique key for a group.
- **attributes:** The entitlement’s list of attributes. This list of attributes is an example: `id`, `name`, and `description`.
- **name:** The name of the attribute as it appears in IDN.
- **name:** The name of the attribute as it appears in ISC.
- **type:** The attribute’s type. Possible values are `string`, `boolean`, `long`, and `int`.
- **description:** A helpful description the attribute. This is useful to source owners when they are trying to understand the account schema.
- **accountCreateTemplate:** A map of identity attributes IDN will pass to the connector to create an account in the target source.
- **key:** The unique identifier of the attribute. This is also the name that is presented in the Create Profile screen in IDN.
- **accountCreateTemplate:** A map of identity attributes ISC will pass to the connector to create an account in the target source.
- **key:** The unique identifier of the attribute. This is also the name that is presented in the Create Profile screen in ISC.
- **label:** A friendly name for presentation purposes.
- **type:** The attribute’s type. Possible values are `string`, `boolean`, `long`, and `int`.
- **initialValue (Optional):** Use this to specify identitAttribute mapping, generator or default values.
@@ -88,4 +88,4 @@ The following describes in detail the different fields in the connector spec:
- **maxSize:** Use this for the Create Unique Account ID generator type. This value specifies the maximum size of the username to be generated.
- **maxUniqueChecks:** Use this for the Create Unique Account ID generator type. This value specifies the maximum retries in case a unique ID is not found with the first random generated user.
- **template:** Use this for the Create Unique Account ID generator type. This value specifies the template used for generation. Example: `"$(firstname).$(lastname)$(uniqueCounter)"`.
- **required (Optional):** Determines whether the account create operation requires this attribute. It defaults to `false`. If it is `true` and IdentityNow encounters an identity missing this attribute, IDN does not send the account to the connector for account creation.
- **required (Optional):** Determines whether the account create operation requires this attribute. It defaults to `false`. If it is `true` and Identity Security Cloud encounters an identity missing this attribute, ISC does not send the account to the connector for account creation.

4
docs/connectivity/saas-connectivity/in-depth/cli-advanced.md
View File

@@ -6,12 +6,12 @@ sidebar_label: CLI - Advanced
sidebar_position: 1
sidebar_class_name: cliAdvanced
keywords: ['connectivity', 'connectors', 'cli']
description: Using the CLI to properly test and debug your connector in IdentityNow
description: Using the CLI to properly test and debug your connector in Identity Security Cloud
slug: /connectivity/saas-connectivity/in-depth/cli-advanced
tags: ['Connectivity']
---
You can use the CLI to invoke a number of calls in IdentityNow, including calls that aren't specifically defined by the CLI. This section includes examples that show how you can invoke those calls:
You can use the CLI to invoke a number of calls in Identity Security Cloud, including calls that aren't specifically defined by the CLI. This section includes examples that show how you can invoke those calls:
## Use provided CLI invoke calls

10
docs/connectivity/saas-connectivity/in-depth/connector-timeouts.md
View File

@@ -6,14 +6,14 @@ sidebar_label: Connector Timeouts
sidebar_position: 1.2
sidebar_class_name: connectorTimeouts
keywords: ['connectivity', 'connectors', 'timeout']
description: IdentityNow will throw an error if your connector does not send a response in 3 minutes. For connector commands that might take longer than 3 minutes, make sure to send data at regular intervals to prevent a timeout.
description: Identity Security Cloud will throw an error if your connector does not send a response in 3 minutes. For connector commands that might take longer than 3 minutes, make sure to send data at regular intervals to prevent a timeout.
slug: /connectivity/saas-connectivity/in-depth/connector-timeouts
tags: ['Connectivity']
---
An IdentityNow SaaS Connectivity connector will send a timeout error if it doesn't send a response within 3 minutes. If the connector is sending thousands of records, the record fetching process will likely exceed this timeout limit. If you are storing all those records in memory before sending them to IDN, you can run into memory utilization issues. To prevent these issues, you should paginate through your source data and send the data back in regular intervals.
An Identity Security Cloud SaaS Connectivity connector will send a timeout error if it doesn't send a response within 3 minutes. If the connector is sending thousands of records, the record fetching process will likely exceed this timeout limit. If you are storing all those records in memory before sending them to ISC, you can run into memory utilization issues. To prevent these issues, you should paginate through your source data and send the data back in regular intervals.
In the case of a long running API call to the source system, you can also optionally send `res.keepAlive()` to keep the connection to IdentityNow open without having to send any data to IdentityNow. If `res.keepAlive()` or `res.send()` is not called within 3 minutes, a connector timeout will occur.
In the case of a long running API call to the source system, you can also optionally send `res.keepAlive()` to keep the connection to Identity Security Cloud open without having to send any data to Identity Security Cloud. If `res.keepAlive()` or `res.send()` is not called within 3 minutes, a connector timeout will occur.
This is an example of how to set up this pagination:
@@ -25,8 +25,8 @@ async getAccounts(res: Response<StdAccountListOutput>): Promise<boolean> {
// each page will be called recursively until there are no more records to fetch, at which case the promise is fulfilled
).eachPage((records, fetchNextPage) => {
for (let record of records) {
// this is the part that sends the data to IdentityNow. Since eachPage is called with just 10 records,
// if there are 100 records total, we would send data back to IDN in 10 sets of 10 records.
// this is the part that sends the data to Identity Security Cloud. Since eachPage is called with just 10 records,
// if there are 100 records total, we would send data back to ISC in 10 sets of 10 records.
res.send({
identity: record.id,
attributes: {

6
docs/connectivity/saas-connectivity/in-depth/debugging.md
View File

@@ -39,7 +39,7 @@ export const connector = async () => {
};
```
`console.log()` statements work anywhere, and they work when you deploy your connector to IDN. However, these statements can create clutter in your code. You will often have to clean up debug statements once you are done.
`console.log()` statements work anywhere, and they work when you deploy your connector to ISC. However, these statements can create clutter in your code. You will often have to clean up debug statements once you are done.
If your IDE supports debugging JavaScript, then your IDE’s built-in debugger can be a powerful and easy way to debug your code.
@@ -87,6 +87,6 @@ With these configurations set, you can run the debugger by selecting the options
![debugging 2](./img/debugging2.png)
## Debug in IdentityNow
## Debug in Identity Security Cloud
You can use the `sail conn logs` command to gain insight into how your connector is performing while running in IDN. See the section on logging for more information.
You can use the `sail conn logs` command to gain insight into how your connector is performing while running in ISC. See the section on logging for more information.

4
docs/connectivity/saas-connectivity/in-depth/error-handling.md
View File

@@ -45,7 +45,7 @@ export class AirtableClient {
## Not Found Error Type
The connector SDK offers a special error type of "Not Found". This error signals to IDN that the specific account is not in the source system. If the account should be in the source system, IDN will then call the connector ```std:account:create``` command to create the account.
The connector SDK offers a special error type of "Not Found". This error signals to ISC that the specific account is not in the source system. If the account should be in the source system, ISC will then call the connector ```std:account:create``` command to create the account.
Here is an example:
@@ -54,7 +54,7 @@ Here is an example:
const account = await myClient.getAccount(input.identity)
if (!account) {
// account was not found, but identity now has the account and expects it to be there!
// Send an error message to IdentityNow so the account is automatically created
// Send an error message to Identity Security Cloud so the account is automatically created
if (!account) {
throw new ConnectorError("account is not found", ConnectorErrorType.NotFound)
}

2
docs/connectivity/saas-connectivity/in-depth/logging.md
View File

@@ -13,7 +13,7 @@ tags: ['Connectivity']
## Printing Logs with the CLI
Fetch logs from IDN by issuing the `sail conn logs` command:
Fetch logs from ISC by issuing the `sail conn logs` command:
```bash
$ sail conn logs

6
docs/connectivity/saas-connectivity/index.md
View File

@@ -15,12 +15,12 @@ SaaS Connectivity is a cloud based connector runtime that makes developing and d
## What Are Connectors
Connectors are the bridges between the SailPoint Identity Now (IDN) SaaS platform and the source systems that IDN needs to communicate with and aggregate data from. An example of a source system IDN may need to communicate with would be an Oracle HR system or GitHub. In these cases, IDN synchronizes data between systems to ensure account entitlements and state are correct through the organization.
Connectors are the bridges between the SailPoint Identity Security Cloud (ISC) SaaS platform and the source systems that ISC needs to communicate with and aggregate data from. An example of a source system ISC may need to communicate with would be an Oracle HR system or GitHub. In these cases, ISC synchronizes data between systems to ensure account entitlements and state are correct through the organization.
## Why We Are Introducing SaaS Connectivity
The primary driver for indroducing the SaaS Connectivity framework is to allow a way to connect to other cloud based sources in a truly SaaS architecture, without the need to rely on a VA. There are also other benefits that come with the SaaS Connectivity framework:
- Ability to develop, debug and test custom connectors locally without any dependencies on IdentityNow
- Ability to develop, debug and test custom connectors locally without any dependencies on Identity Security Cloud
- Features to customize the user interface when configuring the connector that are specific to the source
- Support for more modern languages and frameworks
@@ -30,7 +30,7 @@ VA connectors always communicate with external sources through the Virtual Appli
![Old Connectivity](./img/old_connectivity_diagram.png)
The new Cloud connectors work differently - they run on the IDN platform instead:
The new Cloud connectors work differently - they run on the ISC platform instead:
![New Connectivity](./img/new_connectivity_diagram.png)

2
docs/connectivity/saas-connectivity/limits.md
View File

@@ -15,7 +15,7 @@ Below is a list of limits set in SaaS Connectivity:
- **Max Run Time**
- The actual run time of a connector is not limited at this time, however a response in the form of `res.send()` must be recieved from a command at least every 3 minutes
- If you have a long running call, you can use `res.keepAlive()` to send a heartbeat to IdentityNow in between `res.send()` calls to let it know the connector is still running
- If you have a long running call, you can use `res.keepAlive()` to send a heartbeat to Identity Security Cloud in between `res.send()` calls to let it know the connector is still running
- **Response Size**
- The maximum size of a single `res.send()` call is 256 KiB. Not that some metadata is sent along with the call, so the max size of the payload sent will be slightly less than 256 KiB
- **Memory Limits**

8
docs/connectivity/saas-connectivity/prerequisites.md
View File

@@ -29,7 +29,7 @@ Although you can develop connectors in a text editor, use an Integrated Developm
### Postman
A convenient way to test your connector before deploying to IDN is to use Postman. You can get it from the [postman.com downloads page](https://www.postman.com/downloads/)
A convenient way to test your connector before deploying to ISC is to use Postman. You can get it from the [postman.com downloads page](https://www.postman.com/downloads/)
## Creating your first project
@@ -61,15 +61,15 @@ my-first-project
This directory contains three main files:
- **index.ts:** Use this file to register all the available commands the connector supports, provide the necessary configuration options to the client code implementing the API for the source, and pass data the client code obtains to IdentityNow. This file can either use a vendor supplied client Software Development Kit (SDK) to interact with the web service or reference custom client code within the project.
- **index.ts:** Use this file to register all the available commands the connector supports, provide the necessary configuration options to the client code implementing the API for the source, and pass data the client code obtains to Identity Security Cloud. This file can either use a vendor supplied client Software Development Kit (SDK) to interact with the web service or reference custom client code within the project.
- **my-client.ts:** Use this template to create custom client code to interact with a web service’s APIs. If the web service does not provide an SDK, you can modify this file to implement the necessary API calls to interact with the source web service.
- **connector-spec.ts** This file describes how the connector works to IDN. More information about the connector spec is available in the next section. At a high level, it has the information for the following:
- **connector-spec.ts** This file describes how the connector works to ISC. More information about the connector spec is available in the next section. At a high level, it has the information for the following:
- What commands the connector supports
- What config values the user must provide when creating the connector
- Defining the account schema
- Defining the entitlment schema
- Defining the account create template that maps fields from IDN to the connector
- Defining the account create template that maps fields from ISC to the connector
These files are templates that provide guidance to begin implementing the connector on the target web service. Although you can implement a connector's entire functionality within these three files (or even just one if the web service provides an SDK), you can implement your own code architecture, like breaking out common utility functions into a separate file or creating separate files for each operation.

24
docs/connectivity/saas-connectivity/test-build-deploy.md
View File

@@ -37,17 +37,17 @@ As you implement command handlers, you must test them. The connector SDK provide
## Create and Upload Connector Bundle
Follow these steps to use the CLI to package a connector bundle, create it in your IdentityNow org, and upload it to IdentityNow.
Follow these steps to use the CLI to package a connector bundle, create it in your Identity Security Cloud org, and upload it to Identity Security Cloud.
### Package Connector Files
You must compress the files in the connector project into a zip file before uploading them to IdentityNow.
You must compress the files in the connector project into a zip file before uploading them to Identity Security Cloud.
Use the CLI to run `npm run pack-zip` to build and package the connector bundle. Put the resulting zip file in the `dist` folder.
### Create Connector In Your Org
Before uploading the zip file, you must create an entry for the connector in your IdentityNow org. Run `sail conn create "my-project"` to create a connector entry.
Before uploading the zip file, you must create an entry for the connector in your Identity Security Cloud org. Run `sail conn create "my-project"` to create a connector entry.
The response to this command contains a connector ID you can use to manage this connector.
@@ -76,9 +76,9 @@ $ sail conn list
+--------------------------------------+----------------------------+
```
### Upload Connector Zip File to IdentityNow
### Upload Connector Zip File to Identity Security Cloud
Run `sail conn upload -c [connectorID | connectorAlias] -f dist/[connector filename].zip` to upload the zip file built from the previous step to IdentityNow.
Run `sail conn upload -c [connectorID | connectorAlias] -f dist/[connector filename].zip` to upload the zip file built from the previous step to Identity Security Cloud.
```bash
$ sail conn upload -c example-connector -f dist/example-connector-0.1.0.zip
@@ -103,15 +103,15 @@ $ sail conn tags list -c example-connector
:::caution Important
Make sure that you implement a form of version control or regular backup process for your connectors.
You cannot recover the source code from IDN because it gets sent to IDN as a compiled and minified JavaScript (JS) bundle that cannot be easily expanded into its original source code structure.
You cannot recover the source code from ISC because it gets sent to ISC as a compiled and minified JavaScript (JS) bundle that cannot be easily expanded into its original source code structure.
:::
## Test Your Connector in IdentityNow
## Test Your Connector in Identity Security Cloud
Follow these steps to test a connector bundle in both IdentityNow and the IdentityNow user interface (UI).
Follow these steps to test a connector bundle in both Identity Security Cloud and the Identity Security Cloud user interface (UI).
### Test Your Connector Bundle In IdentityNow
### Test Your Connector Bundle In Identity Security Cloud
The connector CLI provides ways to test invoking commands with any connector upload version. Before running a command, create a file, **config.json**, in the root project folder. Include any configuration items required to interact with the target web service in this file, such as API token, username, password, organization, version, etc. The following snippet is an example:
@@ -141,8 +141,8 @@ $ sail connectors invoke account-list -c example-connector -p config.json
>
> Ensure that you add config.json to your .gitignore file so you do not accidentally store secrets in your code repository.
## Test Your Connector from IdentityNow UI
## Test Your Connector from Identity Security Cloud UI
Go to your IdentityNow org’s source section. Create a source from the connector you just uploaded. This connector will display in the dropdown list: **example-connector (tag: latest)**
Go to your Identity Security Cloud org’s source section. Create a source from the connector you just uploaded. This connector will display in the dropdown list: **example-connector (tag: latest)**
After creating a source, you can to test connection, aggregate account, etc. from the IdentityNow UI.
After creating a source, you can to test connection, aggregate account, etc. from the Identity Security Cloud UI.

2
docs/extensibility/event-triggers/available/access-request-decision.md
View File

@@ -23,7 +23,7 @@ tags: ['Event Triggers', 'Available Event Triggers', 'Fire and Forget']
## Event Context
The SailPoint IdentityNow platform now includes event triggers within the access request approval workflow. The 'Access Request Decision' event trigger provides more proactive governance and ensures users can quickly obtain needed access.
The SailPoint Identity Security Cloud platform now includes event triggers within the access request approval workflow. The 'Access Request Decision' event trigger provides more proactive governance and ensures users can quickly obtain needed access.
![Flow](./img/access-request-postapproval-path.png)

4
docs/extensibility/event-triggers/available/access-request-dynamic-approval.md
View File

@@ -18,12 +18,12 @@ The Access Request Dynamic Approval event trigger provides a way to route a requ
When an access request is submitted, the Access Request Dynamic Approval trigger does the following:
- Sends data about the access request and expects a response including the ID of an existing identity or workgroup (i.e. governance group) to add to the approval workflow.
- Based on the ID received, an approval task is assigned to the identity or governance group in IdentityNow for a decision as an additional step after other configured approval requirements are met.
- Based on the ID received, an approval task is assigned to the identity or governance group in Identity Security Cloud for a decision as an additional step after other configured approval requirements are met.
- If the new approver is also the target identity for this request, the manager is assigned instead. If the identity has no manager, a random org admin is assigned.
- If the ID of the additional approver is wrong, then a random org admin is assigned.
- You can choose to **NOT** add an additional approver by providing an empty object as the response to the triggered REST request.
You can use this trigger to develop logic outside of IdentityNow’s out-of-the-box offerings to route an approval step to users such as the following:
You can use this trigger to develop logic outside of Identity Security Cloud’s out-of-the-box offerings to route an approval step to users such as the following:
- The recipient’s department head
- The recipient’s cost center

4
docs/extensibility/event-triggers/available/account-aggregation-completed.md
View File

@@ -19,9 +19,9 @@ The platform has introduced an event trigger within the Source Aggregation workf
After the initial collection of accounts in the source system during aggregation completes, some uses cases for this trigger include the following:
- Notify an administrator that IdentityNow was able to successfully connect to the source system and collect source accounts.
- Notify an administrator that Identity Security Cloud was able to successfully connect to the source system and collect source accounts.
- Notify an administrator when the aggregation is terminated manually during the account collection phase.
- Notify an administrator or system (e.g. PagerDuty) that IdentityNow failed to collect accounts during aggregation and indicate required remediation for the source system.
- Notify an administrator or system (e.g. PagerDuty) that Identity Security Cloud failed to collect accounts during aggregation and indicate required remediation for the source system.
:::info

2
docs/extensibility/event-triggers/available/native-change-account-created.md
View File

@@ -180,7 +180,7 @@ This is an example input from this trigger:
- `multiValueAttributeChanges` List of multivalued attributes that were aggregated with the account. Only `addedValues` will appear for account created events.
- it will include ALL account attributes if the config is `"allNonEntitlementAttributes": true`
- it will include the enumerated list of attributes contained in `"selectedNonEntitlementAttributes": []`
- `account` The details of the account as it appears in IdentityNow. This information can be used to query the account API for more information.
- `account` The details of the account as it appears in Identity Security Cloud. This information can be used to query the account API for more information.
## Additional Information and Links

2
docs/extensibility/event-triggers/available/native-change-account-deleted.md
View File

@@ -168,7 +168,7 @@ This is an example input from this trigger:
- `multiValueAttributeChanges` List of multivalued attributes that were aggregated with the account. Only `removedValues` will appear for account deleted events.
- it will include ALL account attributes if the config is `"allNonEntitlementAttributes": true`
- it will include the enumerated list of attributes contained in `"selectedNonEntitlementAttributes": []`
- `account` The details of the account as it appears in IdentityNow. This information can be used to query the account API for more information.
- `account` The details of the account as it appears in Identity Security Cloud. This information can be used to query the account API for more information.
## Additional Information and Links

2
docs/extensibility/event-triggers/available/native-change-account-updated.md
View File

@@ -135,7 +135,7 @@ This is an example input from this trigger:
- `multiValueAttributeChanges` List of multivalued attributes that were added and/or removed on the account.
- it will include ALL account attributes if the config is `"allNonEntitlementAttributes": true`
- it will include the enumerated list of attributes contained in `"selectedNonEntitlementAttributes": []`
- `account` The details of the account as it appears in IdentityNow. This information can be used to query the account API for more information.
- `account` The details of the account as it appears in Identity Security Cloud. This information can be used to query the account API for more information.
## Additional Information and Links

4
docs/extensibility/event-triggers/available/provisioning-completed.md
View File

@@ -83,7 +83,7 @@ To provision to a target application, the connector for the source must support
- `PROVISIONING` - Can write to accounts. Currently, the trigger does not include attribute synchronization.
- `PASSWORD` - Can update password for accounts.
For a list of supported connectors and features, see [Supported Connectors for IdentityNow](https://community.sailpoint.com/t5/Connectors/Supported-Sources-Connectors-for-IdentityNow/ta-p/80019).
For a list of supported connectors and features, see [Supported Connectors for Identity Security Cloud](https://community.sailpoint.com/t5/Connectors/Supported-Sources-Connectors-for-Identity Security Cloud/ta-p/80019).
For information about configuring sources for provisioning, see [How can I edit the Create Profile on a source?](https://community.sailpoint.com/t5/Connectors/How-can-I-edit-the-Create-Profile-on-a-source/ta-p/74429).
@@ -110,7 +110,7 @@ The following steps must be completed:
- Access profile using source entitlements. Role setup is optional.
- Application enabled for Access Request.
> **NOTE:** There is no indication to the approver in the IdentityNow UI that the approval is for a revoke action. This must be considered for all usage of these APIs.
> **NOTE:** There is no indication to the approver in the Identity Security Cloud UI that the approval is for a revoke action. This must be considered for all usage of these APIs.
![Flow](./img/provisioning-access-request-2.png)

2
docs/extensibility/event-triggers/available/va-cluster-status-change.md
View File

@@ -23,7 +23,7 @@ Additional notes about VA Cluster Status Changes:
- VA cluster health checks run every 30 minutes.
- This trigger will invoke on any VA cluster health status change (i.e. healthy -> unhealthy, unhealthy -> healthy).
- See [troubleshooting virtual appliances](https://community.sailpoint.com/t5/IdentityNow-Connectors/Virtual-Appliance-Troubleshooting-Guide/ta-p/78735) for more information.
- See [troubleshooting virtual appliances](https://community.sailpoint.com/t5/Identity Security Cloud-Connectors/Virtual-Appliance-Troubleshooting-Guide/ta-p/78735) for more information.
Healthy Cluster Source

4
docs/extensibility/event-triggers/early-access/identity-deleted.md
View File

@@ -29,11 +29,11 @@ Identity deleted event will occur when an identity meets all of the following re
- No assigned capabilities (ex. not an assigned cert reviewer)
- Not involved in any active certification as a target (its access is not being certified)
After accounts are aggregated and the identity refresh process finds an identity that meets the above criteria, the associated identity is deleted from IdentityNow. For more information, see [Configuring Correlation](https://community.sailpoint.com/t5/Connectors/Configuring-Correlation/ta-p/74045). The Identity deleted event contains any identity attributes as they are configured in the identity profile. For more information, see [Mapping Identity Profiles](https://community.sailpoint.com/t5/Admin-Help/Mapping-Identity-Profiles/ta-p/77877).
After accounts are aggregated and the identity refresh process finds an identity that meets the above criteria, the associated identity is deleted from Identity Security Cloud. For more information, see [Configuring Correlation](https://community.sailpoint.com/t5/Connectors/Configuring-Correlation/ta-p/74045). The Identity deleted event contains any identity attributes as they are configured in the identity profile. For more information, see [Mapping Identity Profiles](https://community.sailpoint.com/t5/Admin-Help/Mapping-Identity-Profiles/ta-p/77877).
:::info
IdentityNow will **hide** an identity from the identity list in the UI when the authoritative account is removed. This does not necessarily mean that the identity has been deleted. The identity will only be deleted when the above criteria are met. The deletion task run each night, so there will be a delay from when the criteria are met to when the identity will actually be deleted.
Identity Security Cloud will **hide** an identity from the identity list in the UI when the authoritative account is removed. This does not necessarily mean that the identity has been deleted. The identity will only be deleted when the above criteria are met. The deletion task run each night, so there will be a delay from when the criteria are met to when the identity will actually be deleted.
:::

2
docs/extensibility/event-triggers/early-access/source-account-created.md
View File

@@ -18,7 +18,7 @@ This is an early access event trigger. Please contact support to have it enabled
## Event Context
Source Account Created events occur after a new account is detected during an account aggregration and refresh from a source. This trigger cannot determine whether account creation happened on a source or in IdentityNow. It omits events related to IdentityNow accounts, such as the IdentityNow Admin.
Source Account Created events occur after a new account is detected during an account aggregration and refresh from a source. This trigger cannot determine whether account creation happened on a source or in Identity Security Cloud. It omits events related to Identity Security Cloud accounts, such as the Identity Security Cloud Admin.
Use this event trigger to watch for new accounts with highly privileged access, such as an account created in Active Directory Domain Admins.

2
docs/extensibility/event-triggers/early-access/source-account-deleted.md
View File

@@ -18,7 +18,7 @@ This is an early access event trigger. Please contact support to have it enabled
## Event Context
Source Account Deleted events occur whenever an account is deleted from its source during an account aggregation operation. The account may have been manually removed or deleted as the result of a provisioning event. The trigger cannot determine whether the account deletion happened on a source or in IdentityNow. It omits events related to IdentityNow accounts, such as the IdentityNow Admin.
Source Account Deleted events occur whenever an account is deleted from its source during an account aggregation operation. The account may have been manually removed or deleted as the result of a provisioning event. The trigger cannot determine whether the account deletion happened on a source or in Identity Security Cloud. It omits events related to Identity Security Cloud accounts, such as the Identity Security Cloud Admin.
Use this event trigger to watch for deletions of authoritative accounts, such as an account deleted on Workday.

2
docs/extensibility/event-triggers/early-access/source-account-updated.md
View File

@@ -18,7 +18,7 @@ This is an early access event trigger. Please contact support to have it enabled
## Event Context
Source Account Updated events occur whenever one or more account attributes change on a single account during an account aggregation operation. The trigger cannot determine whether the account update happened on a source or in IdentityNow. It omits events related to IdentityNow accounts, such as the IdentityNow Admin. The following actions are considered updates:
Source Account Updated events occur whenever one or more account attributes change on a single account during an account aggregation operation. The trigger cannot determine whether the account update happened on a source or in Identity Security Cloud. It omits events related to Identity Security Cloud accounts, such as the Identity Security Cloud Admin. The following actions are considered updates:
- Update account attributes
- Enable or disable an account

2
docs/extensibility/event-triggers/index.md
View File

@@ -13,7 +13,7 @@ tags: ['Event Triggers']
## What Are Triggers
The result of any action performed in a service is called an **event**. Services like IdentityNow constantly generate events like an update to a setting or the completion of an account aggregation. Most events a service generates are of little value to clients, so services create event triggers, also known as web hooks, that allow clients to subscribe to specific events they are interested in. Similar to news letters or RSS feeds, each subscription tells the service what event a client is interested in and where to send the client the notification.
The result of any action performed in a service is called an **event**. Services like Identity Security Cloud constantly generate events like an update to a setting or the completion of an account aggregation. Most events a service generates are of little value to clients, so services create event triggers, also known as web hooks, that allow clients to subscribe to specific events they are interested in. Similar to news letters or RSS feeds, each subscription tells the service what event a client is interested in and where to send the client the notification.
## How Are Triggers Different from APIs

2
docs/extensibility/event-triggers/preparing-a-subscriber-service.md
View File

@@ -15,7 +15,7 @@ Before you can subscribe to an event trigger, you must prepare a service that ca
## Webhook Testing Service
There are many webhook testing websites that generate a unique URL you can use to subscribe to an event trigger and explore the data sent by the trigger. One site is https://webhook.site. This site generates a unique URL whenever you open it, which you can copy and paste into the subscription configuration in IdentityNow. Any events that the trigger generates will be sent to this website for you to analyze.
There are many webhook testing websites that generate a unique URL you can use to subscribe to an event trigger and explore the data sent by the trigger. One site is https://webhook.site. This site generates a unique URL whenever you open it, which you can copy and paste into the subscription configuration in Identity Security Cloud. Any events that the trigger generates will be sent to this website for you to analyze.
![Webhook.site](./img/webhook-site.png)

6
docs/extensibility/event-triggers/subscribing-to-a-trigger.md
View File

@@ -6,20 +6,20 @@ sidebar_label: Subscribing to a Trigger
sidebar_position: 3
sidebar_class_name: subscribingToTrigger
keywords: ['event', 'trigger', 'subscribing']
description: Usually, you will subscribe to event triggers using the user interface in IDN. Refer to subscribing to event triggers to learn how to subscribe to an event trigger through the IDN UI.
description: Usually, you will subscribe to event triggers using the user interface in ISC. Refer to subscribing to event triggers to learn how to subscribe to an event trigger through the ISC UI.
slug: /extensibility/event-triggers/subscribing-to-trigger
tags: ['Event Triggers']
---
## View the Available Triggers
SailPoint is continuously developing new event triggers to satisfy different use cases. Some of these triggers are considered **early access** and are only available in an IDN tenant upon request. To see a list of available event triggers in your tenant, go to the **Event Triggers** tab in the **Admin** section of IdentityNow. The first page is a list of your tenant's available event triggers. You can select each trigger to learn more about its type, what causes it to fire, and what the payload will look like.
SailPoint is continuously developing new event triggers to satisfy different use cases. Some of these triggers are considered **early access** and are only available in an ISC tenant upon request. To see a list of available event triggers in your tenant, go to the **Event Triggers** tab in the **Admin** section of Identity Security Cloud. The first page is a list of your tenant's available event triggers. You can select each trigger to learn more about its type, what causes it to fire, and what the payload will look like.
![Available triggers](./img/available-triggers.png)
## Subscribe to a Trigger from the UI
Usually, you will subscribe to event triggers using the user interface in IDN. Refer to [subscribing to event triggers](https://documentation.sailpoint.com/saas/help/common/event_triggers.html#subscribing-to-event-triggers) to learn how to subscribe to an event trigger through the IDN UI.
Usually, you will subscribe to event triggers using the user interface in ISC. Refer to [subscribing to event triggers](https://documentation.sailpoint.com/saas/help/common/event_triggers.html#subscribing-to-event-triggers) to learn how to subscribe to an event trigger through the ISC UI.
## Subscribe to a Trigger from the API

4
docs/extensibility/rules/cloud-rules/account_profile_attribute_generator.md
View File

@@ -16,7 +16,7 @@ This rule generates complex account attribute values during provisioning, e.g. w
## Execution
- **Cloud Execution** - This rule executes in the IdentityNow cloud, and it has read-only access to IdentityNow data models, but it does not have access to on-premise sources or connectors.
- **Cloud Execution** - This rule executes in the Identity Security Cloud cloud, and it has read-only access to Identity Security Cloud data models, but it does not have access to on-premise sources or connectors.
- **Logging** - Logging statements are currently only visible to SailPoint personnel.
![Rule Execution](../img/cloud_execution.png)
@@ -26,7 +26,7 @@ This rule generates complex account attribute values during provisioning, e.g. w
| Argument | Type | Purpose |
| --- | --- | --- |
| log | org.apache.log4j.Logger | Logger to log statements. _Note: This executes in the cloud, and logging is currently not exposed to anyone other than SailPoint._ |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the IdentityNow data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the Identity Security Cloud data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| identity | sailpoint.object.Identity | Reference to identity object representing the identity being calculated. |
| application | sailpoint.object.Application | Read-only reference to application object that represents the source to which provisioning is being done. |
| field | sailpoint.object.Field | Field object used to get information about the attribute being generated. |

4
docs/extensibility/rules/cloud-rules/account_profile_attribute_generator_from_template.md
View File

@@ -41,7 +41,7 @@ In the following example, the template is `${firstname}.${lastname}${uniqueCount
## Execution
- **Cloud Execution** - This rule executes in the IdentityNow cloud, and it has read-only access to IdentityNow data models, but it does not have access to on-premise sources or connectors.
- **Cloud Execution** - This rule executes in the Identity Security Cloud cloud, and it has read-only access to Identity Security Cloud data models, but it does not have access to on-premise sources or connectors.
- **Logging** - Logging statements are currently only visible to SailPoint personnel.
![Rule Execution](../img/cloud_execution.png)
@@ -51,7 +51,7 @@ In the following example, the template is `${firstname}.${lastname}${uniqueCount
| Argument | Type | Purpose |
| --- | --- | --- |
| log | org.apache.log4j.Logger | Logger to log statements. _Note: This executes in the cloud, and logging is currently not exposed to anyone other than SailPoint._ |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the IdentityNow data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the Identity Security Cloud data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| identity | sailpoint.object.Identity | Reference to identity object representing the identity being calculated. |
| field | sailpoint.object.Field | Field object used to get information about the attribute being generated. |

4
docs/extensibility/rules/cloud-rules/before_provisioning_rule.md
View File

@@ -22,7 +22,7 @@ These are some examples of when to use this rule:
## Execution
- **Cloud Execution** - This rule executes in the IdentityNow cloud, and it has read-only access to IdentityNow data models, but it does not have access to on-premise sources or connectors.
- **Cloud Execution** - This rule executes in the Identity Security Cloud cloud, and it has read-only access to Identity Security Cloud data models, but it does not have access to on-premise sources or connectors.
- **Logging** - Logging statements are currently only visible to SailPoint personnel.
![Rule Execution](../img/cloud_execution.png)
@@ -32,7 +32,7 @@ These are some examples of when to use this rule:
| Argument | Type | Purpose |
| --- | --- | --- |
| log | org.apache.log4j.Logger | Logger to log statements. _Note: This executes in the cloud, and logging is currently not exposed to anyone other than SailPoint._ |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the IdentityNow data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the Identity Security Cloud data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| plan | sailpoint.object.ProvisioningPlan | A set of provisioning instructions which are sent to the source connectors. |
| application | sailpoint.object.Application | Read-only reference to application object that represents the source to which provisioning is being done. |

2
docs/extensibility/rules/cloud-rules/build_map_rule.md
View File

@@ -22,7 +22,7 @@ This rule runs in the cloud, but it's really a connector rule because it execute
## Execution
- **Cloud Execution** - This rule executes in the IdentityNow cloud, and has read-only access to the records from the Delimited File being imported. However, it doesn't have access to on-premise sources or connectors.
- **Cloud Execution** - This rule executes in the Identity Security Cloud cloud, and has read-only access to the records from the Delimited File being imported. However, it doesn't have access to on-premise sources or connectors.
- **Logging** - Logging statements are currently only visible to SailPoint personnel.
![Rule Execution](../img/cloud_execution.png)

4
docs/extensibility/rules/cloud-rules/correlation_rule.md
View File

@@ -16,7 +16,7 @@ This rule associates or correlates an account to an identity, based on complex l
## Execution
- **Cloud Execution** - This rule executes in the IdentityNow cloud, and it has read-only access to IdentityNow data models, but it does not have access to on-premise sources or connectors.
- **Cloud Execution** - This rule executes in the Identity Security Cloud cloud, and it has read-only access to Identity Security Cloud data models, but it does not have access to on-premise sources or connectors.
- **Logging** - Logging statements are currently only visible to SailPoint personnel.
![Rule Execution](../img/cloud_execution.png)
@@ -26,7 +26,7 @@ This rule associates or correlates an account to an identity, based on complex l
| Argument | Type | Purpose |
| --- | --- | --- |
| log | org.apache.log4j.Logger | Logger to log statements. _Note: This executes in the cloud, and logging is currently not exposed to anyone other than SailPoint._ |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the IdentityNow data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the Identity Security Cloud data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| account | sailpoint.object.ResourceObject | Read-only representation of account data that has been aggregated. Use this as a basis to determine correlation linkages with a specific identity. |
| application | sailpoint.object.Application | Read-only reference to application object that represents the source to which account correlation is being done. |

4
docs/extensibility/rules/cloud-rules/generic_rule.md
View File

@@ -45,7 +45,7 @@ return result[index];
## Execution
- **Cloud Execution** - This rule executes in the IdentityNow cloud, and it has read-only access to IdentityNow data models, but it does not have access to on-premise sources or connectors.
- **Cloud Execution** - This rule executes in the Identity Security Cloud cloud, and it has read-only access to Identity Security Cloud data models, but it does not have access to on-premise sources or connectors.
- **Logging** - Logging statements are currently only visible to SailPoint personnel.
![Rule Execution](../img/cloud_execution.png)
@@ -55,7 +55,7 @@ return result[index];
| Argument | Type | Purpose |
| --- | --- | --- |
| log | org.apache.log4j.Logger | Logger to log statements. _Note: This executes in the cloud, and logging is currently not exposed to anyone other than SailPoint._ |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the IdentityNow data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the Identity Security Cloud data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
## Output

6
docs/extensibility/rules/cloud-rules/identity_attribute_rule.md
View File

@@ -16,11 +16,11 @@ tags: ['Rules']
This rule calculates and returns an identity attribute for a specific identity. This rule is known as a "complex" rule on the identity profile.
An important consideration with IdentityAttribute rules is whether generation logic that includes uniqueness checks is acceptable. While not explicitly disallowed, this type of logic is firmly against SailPoint's [best practices](https://community.sailpoint.com/t5/IdentityNow-Articles/Best-Practices-Generating-Usernames-in-IdentityNow/ta-p/153749). When calculating and promoting identity attributes via a transform or a rule, the logic contained within the attribute is always re-run and new values might end up being generated where such behavior is not desired. Additionally, the attribute calculation process is multi-threaded, so the uniqueness logic contained on a single attribute is not always guaranteed to be accurate. For this reason, SailPoint strongly discourages the use of logic that conducts uniqueness checks within an IdentityAttribute rule. The recommendation is to execute this check during account generation for the target system where the value is needed.
An important consideration with IdentityAttribute rules is whether generation logic that includes uniqueness checks is acceptable. While not explicitly disallowed, this type of logic is firmly against SailPoint's [best practices](https://community.sailpoint.com/t5/Identity Security Cloud-Articles/Best-Practices-Generating-Usernames-in-Identity Security Cloud/ta-p/153749). When calculating and promoting identity attributes via a transform or a rule, the logic contained within the attribute is always re-run and new values might end up being generated where such behavior is not desired. Additionally, the attribute calculation process is multi-threaded, so the uniqueness logic contained on a single attribute is not always guaranteed to be accurate. For this reason, SailPoint strongly discourages the use of logic that conducts uniqueness checks within an IdentityAttribute rule. The recommendation is to execute this check during account generation for the target system where the value is needed.
## Execution
- **Cloud Execution** - This rule executes in the IdentityNow cloud, and it has read-only access to IdentityNow data models, but it does not have access to on-premise sources or connectors.
- **Cloud Execution** - This rule executes in the Identity Security Cloud cloud, and it has read-only access to Identity Security Cloud data models, but it does not have access to on-premise sources or connectors.
- **Logging** - Logging statements are currently only visible to SailPoint personnel.
- **Usage** - To use this rule once installed, first select "Complex Data Source" option under the Source dropdown, then select the rule name under the Transform drop down.
@@ -31,7 +31,7 @@ An important consideration with IdentityAttribute rules is whether generation lo
| Argument | Type | Purpose |
| --- | --- | --- |
| log | org.apache.log4j.Logger | Logger to log statements. _Note: This executes in the cloud, and logging is currently not exposed to anyone other than SailPoint._ |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the IdentityNow data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the Identity Security Cloud data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| identity | sailpoint.object.Identity | Reference to identity object representing the identity being calculated. |
| oldValue | java.lang.Object | Attribute value for the identity attribute before the rule runs. |

2
docs/extensibility/rules/cloud-rules/index.md
View File

@@ -93,7 +93,7 @@ Once you have submitted your rule and you are in the review process, remember th
- **Timing:** SailPoint will examine your rule as soon as possible. Most rules are reviewed within 24 hours of submission. However, if your rule is complex, poorly documented, hard to read, or if it presents new issues, it may require greater scrutiny and consideration. If your rule is repeatedly rejected for the same guideline violation, your rule's review may take longer to complete.
- **Status Updates:** Your rule's current status will be reflected in your [SailPoint Expert Services request](https://www.sailpoint.com/services/professional/#contact-form), so you can monitor its progress there.
- **Expedite Requests:** If you have a critical timing issue, you can request an expedited review. Respect your fellow implementers by seeking expedited review only when you truly need it. If you are found to be abusing this system, SailPoint may reject further requests going forward.
- **Rejections:** SailPoint's goal is to apply these guidelines fairly and consistently, but mistaken rejections can happen. If your rule has been rejected and you have questions or you would like to provide additional information, communicate directly with the rule review team. This may help get your rule into IdentityNow, and it can help SailPoint improve the process or identify a need for clarity in its policies. If you still disagree with the outcome, let SailPoint know and someone can look into it.
- **Rejections:** SailPoint's goal is to apply these guidelines fairly and consistently, but mistaken rejections can happen. If your rule has been rejected and you have questions or you would like to provide additional information, communicate directly with the rule review team. This may help get your rule into Identity Security Cloud, and it can help SailPoint improve the process or identify a need for clarity in its policies. If you still disagree with the outcome, let SailPoint know and someone can look into it.
- **Changes:** Rule changes or modifications to meet guidelines are not the reviewer's responsibility. They are the responsibility of the person(s) submitting the rule. Reviewers may give advice, examples, etc. to help, but doing so does not guarantee a solution. You should test the rules with the changes before resubmission.
```

4
docs/extensibility/rules/cloud-rules/manager_correlation_rule.md
View File

@@ -24,7 +24,7 @@ The manager correlation rule runs before configured manager account correlation.
## Execution
- **Cloud Execution** - This rule executes in the IdentityNow cloud, and it has read-only access to IdentityNow data models, but it does not have access to on-premise sources or connectors.
- **Cloud Execution** - This rule executes in the Identity Security Cloud cloud, and it has read-only access to Identity Security Cloud data models, but it does not have access to on-premise sources or connectors.
- **Logging** - Logging statements are currently only visible to SailPoint personnel.
![Rule Execution](../img/cloud_execution.png)
@@ -34,7 +34,7 @@ The manager correlation rule runs before configured manager account correlation.
| Argument | Type | Purpose |
| --- | --- | --- |
| log | org.apache.log4j.Logger | Logger to log statements. _Note: This executes in the cloud, and logging is currently not exposed to anyone other than SailPoint._ |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the IdentityNow data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| idn | sailpoint.server.IdnRuleUtil | Provides a read-only starting point for using the SailPoint API. From this passed reference, the rule can interrogate the Identity Security Cloud data model including identities or account information via helper methods as described in [IdnRuleUtil](../idn_rule_utility.md). |
| link | sailpoint.object.Link | Read-only representation of account data that has been aggregated. Use this as a basis to determine manager linkages to a specific manager identity. |
| managerAttributeValue | java.lang.Object | Attribute value stored in the manager attribute. |

2
docs/extensibility/rules/connector-rules/before_after_operation_rule.md
View File

@@ -44,7 +44,7 @@ The following operations can be performed on a source:
## Architecture Best Practices
For supportability, it is recommended that you write these operation rules with only the most basic logic necessary to trigger a PowerShell script and shift the bulk of the downstream events and/or modifications to the PowerShell script itself. This script would reside on the client's servers and can therefore be easily maintained or modified by the client as needed. It also allows the client to implement changes to the PowerShell scripted functionality without requiring code review by SailPoint because the code runs outside of the IdentityNow platform.
For supportability, it is recommended that you write these operation rules with only the most basic logic necessary to trigger a PowerShell script and shift the bulk of the downstream events and/or modifications to the PowerShell script itself. This script would reside on the client's servers and can therefore be easily maintained or modified by the client as needed. It also allows the client to implement changes to the PowerShell scripted functionality without requiring code review by SailPoint because the code runs outside of the Identity Security Cloud platform.
## Rule Template

2
docs/extensibility/rules/connector-rules/index.md
View File

@@ -11,7 +11,7 @@ slug: /extensibility/rules/connector-rules
tags: ['Rules']
---
**Connector-Executed Rules** or **Connector Rules** are rules that are executed in the IdentityNow virtual appliance, and they are usually extensions of the connector itself. The rules are commonly used to perform complex connector-related functions, so they are specific to only certain connectors. Because these rules execute in the virtual appliance, they do not have access to query the IdentityNow data model or fetch information from IdentityNow. They rely instead on contextual information sent from IdentityNow. Connector-executed rules may also have managed connections provided in their contexts to support querying end systems or sources. Though these managed connections may be used, making additional connections or call-outs is not allowed.
**Connector-Executed Rules** or **Connector Rules** are rules that are executed in the Identity Security Cloud virtual appliance, and they are usually extensions of the connector itself. The rules are commonly used to perform complex connector-related functions, so they are specific to only certain connectors. Because these rules execute in the virtual appliance, they do not have access to query the Identity Security Cloud data model or fetch information from Identity Security Cloud. They rely instead on contextual information sent from Identity Security Cloud. Connector-executed rules may also have managed connections provided in their contexts to support querying end systems or sources. Though these managed connections may be used, making additional connections or call-outs is not allowed.
Unlike cloud rules, connector rules do not have a rule review process and are directly editable with the [Connector Rule REST APIs](https://developer.sailpoint.com/docs/api/beta/connector-rule-management). For more details, see [Configuration Process](#configuration-process).

10
docs/extensibility/rules/guides/your_first_rule.md
View File

@@ -25,7 +25,7 @@ In this guide you'll learn the end to end process of writing a cloud rule to gen
This rule generates complex account attribute values during provisioning, e.g. when creating an account. You would typically use this rule when you are creating an account to generate attributes like usernames.
This rule executes in the IdentityNow (IDN) cloud, and it has read-only access to IDN data models, but it doesn't have access to on-premise sources or connectors.
This rule executes in the Identity Security Cloud (ISC) cloud, and it has read-only access to ISC data models, but it doesn't have access to on-premise sources or connectors.
Refer to [Attribute Generator Rule](../cloud-rules/account_profile_attribute_generator.md) to learn more about the inputs available to you during the rule execution.
@@ -209,7 +209,7 @@ Add a description and the necessary imports for your rule. This rule will need `
### Logic if the Proposed Username Exceeds the Max Length
If the full name exceeds the `MAX_USERNAME_LENGTH` the rule will check whether the length of the first name is greater than the MAX_USERNAME_LENGTH minus 2 (in the case below 10) characters of the first name - this allows for the period `.` and the first character of the last name to take up the remaining two characters. If the first name is less than the `MAX_USERNAME_LENGTH` the rule will use the full first name for the username with the period `.` and the first character of the last name appended. After the username is determined, a call to `isUnique( username )` is made. This uses the IDNRuleUtil class to check Active Directory if the username exists. You will add in that function shortly.
If the full name exceeds the `MAX_USERNAME_LENGTH` the rule will check whether the length of the first name is greater than the MAX_USERNAME_LENGTH minus 2 (in the case below 10) characters of the first name - this allows for the period `.` and the first character of the last name to take up the remaining two characters. If the first name is less than the `MAX_USERNAME_LENGTH` the rule will use the full first name for the username with the period `.` and the first character of the last name appended. After the username is determined, a call to `isUnique( username )` is made. This uses the ISCRuleUtil class to check Active Directory if the username exists. You will add in that function shortly.
```java
if(fullName.length() > MAX_USERNAME_LENGTH) {
@@ -280,7 +280,7 @@ else{
### Add Function `isUnique()` To Check Active Directory for Username
The `isUnique()` function takes the username as a string and uses the `accountExistsByDisplayName()` function from the IDNRuleUtil class to search Active Directory and return a true or false result, depending on whether the username is taken. The function takes an application name and username to test against. The variables `idn` and `application` are included as inputs to the attribute generator rule and are already initialized. Refer to [inputs](../cloud-rules/account_profile_attribute_generator.md#input) to see all inputs available to attribute generator rules.
The `isUnique()` function takes the username as a string and uses the `accountExistsByDisplayName()` function from the ISCRuleUtil class to search Active Directory and return a true or false result, depending on whether the username is taken. The function takes an application name and username to test against. The variables `idn` and `application` are included as inputs to the attribute generator rule and are already initialized. Refer to [inputs](../cloud-rules/account_profile_attribute_generator.md#input) to see all inputs available to attribute generator rules.
```java
public boolean isUnique ( String username ) throws GeneralException {
@@ -428,7 +428,7 @@ return generateUsername( identity.getFirstname(), identity.getLastname() );
Before you send the rule to the professional services team to upload your rule to your tenant for use, you can send it through the rule validator to check for any errors.
Refer to [Rule Validator](https://community.sailpoint.com/t5/Professional-Services/IdentityNow-Rule-Validator/ta-p/166116) for installation.
Refer to [Rule Validator](https://community.sailpoint.com/t5/Professional-Services/Identity Security Cloud-Rule-Validator/ta-p/166116) for installation.
Run the rule validator against your newly written rule.
@@ -488,7 +488,7 @@ To submit your Cloud Rule for review, approval, and inclusion in the SailPoint p
## Add Rule To Account Creation
Log into your IDN tenant and navigate to **Admin** -> **Connections** -> **Sources** -> **{Source Name}** -> **Accounts** -> **Create Account**. Scroll to the attribute you wish to use the rule for generating the username. Check the generator radio button and pick your new rule from the drop down.
Log into your ISC tenant and navigate to **Admin** -> **Connections** -> **Sources** -> **{Source Name}** -> **Accounts** -> **Create Account**. Scroll to the attribute you wish to use the rule for generating the username. Check the generator radio button and pick your new rule from the drop down.
![Account Create](./img/account-create.png)

22
docs/extensibility/rules/idn_rule_utility.md
View File

@@ -1,31 +1,31 @@
---
id: rule-utility
title: Using IDNRuleUtil as a Wrapper for Common Rule Operations
pagination_label: IdentityNow Rule Utility
sidebar_label: IdentityNow Rule Utility
title: Using ISCRuleUtil as a Wrapper for Common Rule Operations
pagination_label: Identity Security Cloud Rule Utility
sidebar_label: Identity Security Cloud Rule Utility
sidebar_position: 4
sidebar_class_name: ruleUtility
keywords: ['rule', 'utility']
description: Using IDNRuleUtil as a Wrapper for Common Rule Operations
description: Using ISCRuleUtil as a Wrapper for Common Rule Operations
slug: /extensibility/rules/rule-utility
tags: ['Rules']
---
## Overview
Use this guide to learn how to configure searchable account attributes within IdentityNow and then leverage them within the IDNRuleUtil wrapper class when searching accounts for attributes such as uniqueness checks. There are also methods in the IDNRuleUtil wrapper class you can use without the additional searchable attributes.
Use this guide to learn how to configure searchable account attributes within Identity Security Cloud and then leverage them within the ISCRuleUtil wrapper class when searching accounts for attributes such as uniqueness checks. There are also methods in the ISCRuleUtil wrapper class you can use without the additional searchable attributes.
Search attributes allow you to search across accounts and sources to determine whether a specific attribute value is being used in your IdentityNow environment.
Search attributes allow you to search across accounts and sources to determine whether a specific attribute value is being used in your Identity Security Cloud environment.
There are three critical components involves with working with searchable attributes:
- [Configuration of search attributes within IdentityNow](#configuration-of-search-attributes-within-identitynow)
- [Configuration of search attributes within Identity Security Cloud](#configuration-of-search-attributes-within-identitynow)
- Seed data for accounts already aggregated into the system.
- Ensure attribute promotion happens for new/changed accounts that are aggregated.
- [Create rules that can be used to query the newly created attribute values](#create-rules-that-can-be-used-to-query-the-newly-created-attribute-values)
- [Implement rules within the Create Profile section of each source an account is being provisioned for](#implement-rules-within-the-create-profile-section-of-each-source-for-which-an-account-is-being-provisioned)
## Configuration of Search Attributes within IdentityNow
## Configuration of Search Attributes within Identity Security Cloud
When you are planning to implement search attributes, it is important that you consider the way new accounts' values will be generated and which attributes should be used as references.
@@ -41,7 +41,7 @@ You need the following information to create search attributes:
The following example shows how to create a new attribute with the [Search Attributes API](/docs/api/beta/create-search-attribute-config):
Your company has two sources. The first is Active Directory, and the second is Workday. When the system aggregates new accounts, the company wants to query IdentityNow to see whether an email address already exists. If the email address is not in use, you can assign it to the new account. If it is in use, you can iterate on the email address value (add a 1 for example). You can then query IdentityNow once more to see whether your incremented email address is in use. You can repeat this procedure until you have determined that an email address is unique.
Your company has two sources. The first is Active Directory, and the second is Workday. When the system aggregates new accounts, the company wants to query Identity Security Cloud to see whether an email address already exists. If the email address is not in use, you can assign it to the new account. If it is in use, you can iterate on the email address value (add a 1 for example). You can then query Identity Security Cloud once more to see whether your incremented email address is in use. You can repeat this procedure until you have determined that an email address is unique.
The following information is necessary to create your search attribute:
@@ -62,7 +62,7 @@ The following information is necessary to create your search attribute:
- Display name for the new attribute configuration:
- `Promoted Email Address`
### Create the New Search Attribute in IdentityNow
### Create the New Search Attribute in Identity Security Cloud
To call the APIs for search attributes, you need a personal access token and the name of your tenant to provide with the request. To retrieve a personal access token, see [Personal Access Tokens](../../api/authentication.md#personal-access-tokens). To get the name of your tenant, see [Finding Your Organization Tenant Name](../../api/getting-started.md#find-your-tenant-name)
@@ -91,7 +91,7 @@ Aggregation only processes new and/or changed accounts for many sources. If an a
If this source has already been aggregated before the account search configuration was created, a non-optimized aggregation must now be performed to seed the new attribute data for all existing accounts.
At this point, the configuration exists to promote attributes on any new/changed account that comes into IdentityNow. These attributes and their associated values are stored for use in custom rules. Each account that exists on either of these sources will now have a new attribute called “promotedEmailAddress”. _The value of this attribute will be the value of `mail` if it is the Active Directory Source or `emailAddress` if it is the Workday source._
At this point, the configuration exists to promote attributes on any new/changed account that comes into Identity Security Cloud. These attributes and their associated values are stored for use in custom rules. Each account that exists on either of these sources will now have a new attribute called “promotedEmailAddress”. _The value of this attribute will be the value of `mail` if it is the Active Directory Source or `emailAddress` if it is the Workday source._
## Create Rules that Can Be Used to Query the Newly Created Attribute values

26
docs/extensibility/rules/index.md
View File

@@ -17,40 +17,40 @@ In SailPoint solutions, rules serve as a flexible configuration framework implem
## Java Beanshell
Rules in IdentityNow are written in Java Beanshell, a lightweight scripting language that allows you to define custom logic and behavior within the rules. Java Beanshell provides a familiar syntax similar to Java, making it easier for implementers to create and maintain rule configurations.
Rules in Identity Security Cloud are written in Java Beanshell, a lightweight scripting language that allows you to define custom logic and behavior within the rules. Java Beanshell provides a familiar syntax similar to Java, making it easier for implementers to create and maintain rule configurations.
For more information about Java Beanshell, you can refer to the [Java Beanshell Documentation](https://github.com/beanshell/beanshell/wiki).
## Rule Execution
IdentityNow (IDN) is a multi-tenant cloud solution, and its architecture varies differently from other SailPoint products like IdentityIQ (IIQ). Therefore, the way rules execute within IDN reflects the architectural design considerations the platform was built on. These considerations determine the rule's limitations.
Identity Security Cloud (ISC) is a multi-tenant cloud solution, and its architecture varies differently from other SailPoint products like IdentityIQ (IIQ). Therefore, the way rules execute within ISC reflects the architectural design considerations the platform was built on. These considerations determine the rule's limitations.
There are two primary places where you can execute rules:
- **Cloud Execution** - These rules are executed in the IDN multi-tenant cloud.
- **Connector Execution** - These rules are executed on the on-premise IDN virtual appliance.
- **Cloud Execution** - These rules are executed in the ISC multi-tenant cloud.
- **Connector Execution** - These rules are executed on the on-premise ISC virtual appliance.
![Rule Execution](./img/rule_execution.png)
**Cloud-Executed Rules** or **Cloud Rules** typically only perform a specific function, such as calculating attribute values. Many of these rules may be able to query the IDN data-model in a read-only fashion, but they do not have the ability to commit transactions, save objects, etc.
**Cloud-Executed Rules** or **Cloud Rules** typically only perform a specific function, such as calculating attribute values. Many of these rules may be able to query the ISC data-model in a read-only fashion, but they do not have the ability to commit transactions, save objects, etc.
Because these rules execute in a multi-tenant cloud environment, they have a restricted context, and they are closely scrutinized to ensure that they execute in an efficient and secure manner.
For more details, see [Cloud Rules](./cloud-rules/index.md).
**Connector-Executed Rules** or **Connector Rules** are rules executed in the IDN virtual appliance, and they are often an extension connector itself. The rules are commonly used for performing complex connector-related functions, so they are specific to only certain connectors. Because these rules execute in the virtual appliance, they do not have access to query the IDN data model or fetch information from IDN. They rely instead on contextual information sent from IDN. Connector-executed rules may also have managed connections supplied in their contexts to support querying end systems or sources. Though you may use these managed connections, you cannot make making additional connections or call-outs.
**Connector-Executed Rules** or **Connector Rules** are rules executed in the ISC virtual appliance, and they are often an extension connector itself. The rules are commonly used for performing complex connector-related functions, so they are specific to only certain connectors. Because these rules execute in the virtual appliance, they do not have access to query the ISC data model or fetch information from ISC. They rely instead on contextual information sent from ISC. Connector-executed rules may also have managed connections supplied in their contexts to support querying end systems or sources. Though you may use these managed connections, you cannot make making additional connections or call-outs.
For more details, see the [Connector Rules](./connector-rules/index.md).
## Support Considerations
Though IDN shares some common functionality with other SailPoint products like IIQ, the same rules are not necessarily supported, nor do they necessarily execute the same way or with the same context and variables. SailPoint recommends that you become familiar with which rules execute with which products, as well as the nuances in their execution contexts.
Though ISC shares some common functionality with other SailPoint products like IIQ, the same rules are not necessarily supported, nor do they necessarily execute the same way or with the same context and variables. SailPoint recommends that you become familiar with which rules execute with which products, as well as the nuances in their execution contexts.
From a SailPoint support perspective, rules are considered configurations. SailPoint supports the underlying platform but not the rule configurations themselves. Any problems with the way rules are implemented or run over time are the responsibilities the customer or implementer must manage. SailPoint's IDN Expert Services need hours to cover any rule configuration work (e.g., creating rules, best practices reviews, application to your IDN environment, and promotion between sandbox & prod environments). Contact your Customer Success Manager with any questions. While rules allow some advanced flexibility, you must consider these support implications when you are deciding whether to implement rules. Consider rule usage a last resort, and use IdentityNow features instead whenever you can.
From a SailPoint support perspective, rules are considered configurations. SailPoint supports the underlying platform but not the rule configurations themselves. Any problems with the way rules are implemented or run over time are the responsibilities the customer or implementer must manage. SailPoint's ISC Expert Services need hours to cover any rule configuration work (e.g., creating rules, best practices reviews, application to your ISC environment, and promotion between sandbox & prod environments). Contact your Customer Success Manager with any questions. While rules allow some advanced flexibility, you must consider these support implications when you are deciding whether to implement rules. Consider rule usage a last resort, and use Identity Security Cloud features instead whenever you can.
## Best Practices for Rule deployments
SailPoint IDN deployments often require the deployment of rules to the client’s IDN tenants. Because IDN is a multi-tenant solution, rules that are poorly written can have negative performance implications on other tenants in the same cloud. As such, SailPoint requires all rules to be reviewed prior to deployment. The time to complete these reviews requires an expert services contract to leverage billable hours.
SailPoint ISC deployments often require the deployment of rules to the client’s ISC tenants. Because ISC is a multi-tenant solution, rules that are poorly written can have negative performance implications on other tenants in the same cloud. As such, SailPoint requires all rules to be reviewed prior to deployment. The time to complete these reviews requires an expert services contract to leverage billable hours.
This article covers common topics around this process including best practices, rule review expectations, and more.
@@ -76,7 +76,7 @@ In the case of rejection, we recommend submitting a new ticket to avoid a scenar
## Promote Rules from Sandbox to Production
A rule that has been approved in a sandbox tenant through the SailPoint rule review process, like an IdentityAttribute, Correlation or ManagerCorrelation rule or any other rule type, for example, can be migrated to the production IDN tenant.
A rule that has been approved in a sandbox tenant through the SailPoint rule review process, like an IdentityAttribute, Correlation or ManagerCorrelation rule or any other rule type, for example, can be migrated to the production ISC tenant.
This applies to all rule types, as the signature has been approved/verified during the SailPoint rule review process, the sp-config API allows you to import ANY ‘approved’ tenant rules. (this includes cloud rules!)
@@ -198,7 +198,7 @@ Log4j
Logger.getLogger​
```
Note that the earlier code fragments are not allowed within [connector-executed rules](./connector-rules/index.md#supported-connector-rules) because they are not valid at the connector level. They will, for a short time, still be allowed for pre-existing [cloud-executed rules](./cloud-rules/index.md) as a review exception. However, any new rules using these constructs will be returned to the submitter, and the submitter will be asked to rewrite the rule, using the [IDN Rule Utility](./idn_rule_utility.md) helper methods instead:
Note that the earlier code fragments are not allowed within [connector-executed rules](./connector-rules/index.md#supported-connector-rules) because they are not valid at the connector level. They will, for a short time, still be allowed for pre-existing [cloud-executed rules](./cloud-rules/index.md) as a review exception. However, any new rules using these constructs will be returned to the submitter, and the submitter will be asked to rewrite the rule, using the [ISC Rule Utility](./idn_rule_utility.md) helper methods instead:
- context
- .getObjectById()
@@ -209,11 +209,11 @@ Note that the earlier code fragments are not allowed within [connector-executed
## Other Rules
While IDN shares some common functionality with other SailPoint products like IIQ, the same rules are not necessarily supported, nor do they necessarily execute the same way. SailPoint recommends that you become familiar with which rules execute with which products, as well as the nuances in their execution contexts. IDN considers any other rules not mentioned in the Cloud-Executed Rules or Connector-Executed Rules sections to be unsupported.
While ISC shares some common functionality with other SailPoint products like IIQ, the same rules are not necessarily supported, nor do they necessarily execute the same way. SailPoint recommends that you become familiar with which rules execute with which products, as well as the nuances in their execution contexts. ISC considers any other rules not mentioned in the Cloud-Executed Rules or Connector-Executed Rules sections to be unsupported.
## Deprecated Rules
The following rules have been deprecated in IDN. SailPoint recommends using supported product functionality instead of these rules:
The following rules have been deprecated in ISC. SailPoint recommends using supported product functionality instead of these rules:
- **Certification Exclusion Rules** - Use configurable certification campaign filters instead.
- **Identity Selector Rules** - Use role standard assignment criteria instead.

2
docs/extensibility/transforms/guides/lifecycle-state-transforms.md
View File

@@ -15,7 +15,7 @@ tags: ['Transforms', 'Guides', 'Lifecycle']
In this guide, you will walk through a lifecycle state transform that requires you to nest multiple transforms together to achieve your desired result.
A lifecycle state is a status an identity can be in, such as `active`, `inactive` and `terminated`, for example. You can then use this lifecycle state in IdentityNow to determine an identity's access.
A lifecycle state is a status an identity can be in, such as `active`, `inactive` and `terminated`, for example. You can then use this lifecycle state in Identity Security Cloud to determine an identity's access.
## Determine lifecycle state from end date attribute

2
docs/extensibility/transforms/guides/provisioning-policy-transform.md
View File

@@ -13,7 +13,7 @@ tags: ['Transforms', 'Guides', 'Provisioning', 'Policies']
## Overview
In this guide, you will learn how to use [IdentityNow's Transforms](/docs/api/v3/transforms) in a provisioning policy for a source. This can be useful if you need to hide the attribute in your identity attribute list but still need the attribute during provisioning.
In this guide, you will learn how to use [Identity Security Cloud's Transforms](/docs/api/v3/transforms) in a provisioning policy for a source. This can be useful if you need to hide the attribute in your identity attribute list but still need the attribute during provisioning.
## Create provisioning policy

2
docs/extensibility/transforms/guides/temporary-password.md
View File

@@ -580,7 +580,7 @@ curl --location --request POST 'https://{tenant}.api.identitynow.com/v3/transfor
Once you have created the transform successfully, you can apply the new transform and preview what the password will look like for each user.
Log in to your IdentityNow tenant and go to **Admin** > **Identities** > **Identity Profiles**. Select the name of the profile you created earlier, Transform Example. Select the **Mappings** tab, scroll to the bottom and select **Add New Attribute**. Name the attribute `Temporary Password`. To save the new mappings, you must fill out the id, email, first name and last name mappings.
Log in to your Identity Security Cloud tenant and go to **Admin** > **Identities** > **Identity Profiles**. Select the name of the profile you created earlier, Transform Example. Select the **Mappings** tab, scroll to the bottom and select **Add New Attribute**. Name the attribute `Temporary Password`. To save the new mappings, you must fill out the id, email, first name and last name mappings.
![Attribute Mapping](./img/temporary_password_attribute_mapping.png)

8
docs/extensibility/transforms/guides/your-first-transform.md
View File

@@ -13,15 +13,15 @@ tags: ['Transforms', 'Guides', 'First']
## Overview
In this guide, you will learn how to use [IdentityNow's Transform REST APIs](/docs/api/v3/transforms) to do the following:
In this guide, you will learn how to use [Identity Security Cloud's Transform REST APIs](/docs/api/v3/transforms) to do the following:
- [List Transforms in Your IdentityNow Tenant](#list-transforms-in-your-identitynow-tenant)
- [List Transforms in Your Identity Security Cloud Tenant](#list-transforms-in-your-identitynow-tenant)
- [Create a Transform](#create-a-transform)
- [Get Transform by ID](#get-transform-by-id)
- [Update a Transform](#update-a-transform)
- [Delete a Transform](#delete-a-transform)
## List Transforms in your IdentityNow Tenant
## List Transforms in your Identity Security Cloud Tenant
To call the APIs for transforms, you need a personal access token and your tenant's name to provide with the request. For more information about how to get a personal access token, see [Personal Access Tokens](../../../api/authentication.md#personal-access-tokens). For more information about how to get the name of your tenant, see [Finding Your Organization Tenant Name](../../../api/getting-started.md#finding-your-orgtenant-name).
@@ -118,7 +118,7 @@ curl --location --request POST 'https://{tenant}.api.identitynow.com/v3/transfor
}
```
Once you have created the transform, you can find it in IdentityNow by going to **Admin** > **Identities** > **Identity Profiles** > (An Identity Profile) > **Mappings** (tab).
Once you have created the transform, you can find it in Identity Security Cloud by going to **Admin** > **Identities** > **Identity Profiles** > (An Identity Profile) > **Mappings** (tab).
![Mappings Tab](./img/mappings_tab.png)

26
docs/extensibility/transforms/index.md
View File

@@ -26,17 +26,17 @@ flowchart LR
</div>
Because there is no code to write, an administrator can configure these by using a JSON object structure and uploading them into IdentityNow using [IdentityNow's Transform REST APIs](/docs/api/v3/transforms).
Because there is no code to write, an administrator can configure these by using a JSON object structure and uploading them into Identity Security Cloud using [Identity Security Cloud's Transform REST APIs](/docs/api/v3/transforms).
:::info
Sometimes transforms are referred to as Seaspray, the codename for transforms. IdentityNow Transforms and Seaspray are essentially the same.
Sometimes transforms are referred to as Seaspray, the codename for transforms. Identity Security Cloud Transforms and Seaspray are essentially the same.
:::
## How Transforms Work
Transforms typically have an input(s) and output(s). The way the transformation occurs mainly depends on the type of transform. Refer to [Operations in IdentityNow Transforms](./operations/index.md) for more information.
Transforms typically have an input(s) and output(s). The way the transformation occurs mainly depends on the type of transform. Refer to [Operations in Identity Security Cloud Transforms](./operations/index.md) for more information.
For example, a [Lower transform](./operations/lower.md) transforms any input text strings into lowercase versions as output. So if the input were `Foo`, the lowercase output of the transform would be `foo`:
@@ -76,7 +76,7 @@ flowchart LR
### Complex Nested Transforms
For more complex use cases, a single transform may not be enough. It is possible to link several transforms together. IdentityNow calls these 'nested' transforms because they are transform objects within other transform objects.
For more complex use cases, a single transform may not be enough. It is possible to link several transforms together. Identity Security Cloud calls these 'nested' transforms because they are transform objects within other transform objects.
An example of a nested transform would be using the previous [Concat transform](./operations/concatenation.md) and passing its output as an input to another [Lower transform](./operations/lower.md). If the inputs `Foo` and `Bar` were passed into the transforms, the ultimate output would be `foobar`, concatenated and in lowercase.
@@ -127,7 +127,7 @@ Transforms are JSON objects. Prior to this, the transforms have been shown as fl
There are three main components of a transform object:
1. `name` - This specifies the name of the transform. It refers to a transform in the IdentityNow API or User Interface (UI). Only provide a name on the root-level transform. Nested transforms do not have names.
1. `name` - This specifies the name of the transform. It refers to a transform in the Identity Security Cloud API or User Interface (UI). Only provide a name on the root-level transform. Nested transforms do not have names.
2. `type` - This specifies the transform type, which ultimately determines the transform's behavior.
@@ -135,7 +135,7 @@ There are three main components of a transform object:
:::caution
When uploading a transform to IdentityNow it cannot exceed 400KB.
When uploading a transform to Identity Security Cloud it cannot exceed 400KB.
:::
@@ -172,7 +172,7 @@ The following variables are available to the Apache Velocity template engine whe
## Implicit vs Explicit Input
A special configuration attribute available to all transforms is input. If the input attribute is not specified, this is referred to as implicit input, and the system determines the input based on what is configured. If the input attribute is specified, then this is referred to as explicit input, and the system's input is ignored in favor of whatever the transform explicitly specifies. A good way to understand this concept is to walk through an example. Imagine that IdentityNow has the following:
A special configuration attribute available to all transforms is input. If the input attribute is not specified, this is referred to as implicit input, and the system determines the input based on what is configured. If the input attribute is specified, then this is referred to as explicit input, and the system's input is ignored in favor of whatever the transform explicitly specifies. A good way to understand this concept is to walk through an example. Imagine that Identity Security Cloud has the following:
- An account on Source 1 with department set to `Services`.
- An account on Source 2 with department set to `Engineering`.
@@ -240,13 +240,13 @@ These transforms are configured separately from the transforms applied via the i
:::
#### Configuration
These can be configured in IdentityNow by going to **Admin** > **Sources** > (A Source) > **Accounts** (tab) > **Create Account**.
These can be configured in Identity Security Cloud by going to **Admin** > **Sources** > (A Source) > **Accounts** (tab) > **Create Account**.
The available options on this page are constructed as transforms behind the scenes. For example, the identity attribute mapping choice is saved as an [identity attribute transform](./operations/identity-attribute.md) definition within the saved create profile.
These can also be configured with IdentityNow REST APIs. You can define any kind of transform you want for any field in the create profile policy, to calculate account attributes in ways beyond what the UI offers. See [Transforms in Provisioning Policies](./guides/provisioning-policy-transform.md).
These can also be configured with Identity Security Cloud REST APIs. You can define any kind of transform you want for any field in the create profile policy, to calculate account attributes in ways beyond what the UI offers. See [Transforms in Provisioning Policies](./guides/provisioning-policy-transform.md).
For more information on the IdentityNow REST API endpoints used to managed transform objects in APIs, refer to [IdentityNow Transform REST APIs](/docs/api/v3/transforms).
For more information on the Identity Security Cloud REST API endpoints used to managed transform objects in APIs, refer to [Identity Security Cloud Transform REST APIs](/docs/api/v3/transforms).
:::tip
@@ -290,9 +290,9 @@ To test a transform for account data, you must provision a new account on that s
Sometimes it can be difficult to decide when to implement a transform and when to implement a rule. Both transforms and rules can calculate values for identity or account attributes.
Despite their functional similarity, transforms and rules have very different implementations. Transforms are JSON-based configurations, editable with IdentityNow's transform REST APIs. Rules are implemented with code (typically [BeanShell](https://github.com/beanshell/beanshell), a Java-like syntax), so they must follow the [IdentityNow Rule Guidelines](https://community.sailpoint.com/docs/DOC-12122), and they require SailPoint to be reviewed and installed into the tenant. Rules, however, can do things that transforms cannot in some cases.
Despite their functional similarity, transforms and rules have very different implementations. Transforms are JSON-based configurations, editable with Identity Security Cloud's transform REST APIs. Rules are implemented with code (typically [BeanShell](https://github.com/beanshell/beanshell), a Java-like syntax), so they must follow the [Identity Security Cloud Rule Guidelines](https://community.sailpoint.com/docs/DOC-12122), and they require SailPoint to be reviewed and installed into the tenant. Rules, however, can do things that transforms cannot in some cases.
Because transforms have easier and more accessible implementations, they are generally recommended. With transforms, any IdentityNow administrator can view, create, edit, and delete transforms directly with REST API without SailPoint involvement.
Because transforms have easier and more accessible implementations, they are generally recommended. With transforms, any Identity Security Cloud administrator can view, create, edit, and delete transforms directly with REST API without SailPoint involvement.
If something cannot be done with a transform, then consider using a rule. When you are transitioning from a transform to a rule, you must take special consideration when you decide where the rule executes.
@@ -300,6 +300,6 @@ If something cannot be done with a transform, then consider using a rule. When y
- If you are calculating account attributes (during provisioning), you can use [Attribute Generator rules](https://community.sailpoint.com/docs/DOC-12645) instead of account transforms.
- All rules you build must follow the [IdentityNow Rule Guidelines](https://community.sailpoint.com/docs/DOC-12122).
- All rules you build must follow the [Identity Security Cloud Rule Guidelines](https://community.sailpoint.com/docs/DOC-12122).
If you use a rule, make note of it for administrative purposes. The best practice is to check in these types of artifacts into some sort of version control (e.g., GitHub, et. Al.) for records.

4
docs/extensibility/transforms/operations/account-attribute.md
View File

@@ -16,8 +16,8 @@ Use the account attribute transform to look up an account for a particular sourc
:::note Other Considerations
- If there are multiple accounts, then IdentityNow by default takes the value from the oldest account (based on the account created date). You can configure this behavior by specifying `accountSortAttribute` and `accountSortDescending` attributes.
- If there are multiple accounts and the oldest account has a null attribute value, by default IdentityNow moves to the next account that can have a value (if there are any). You can override this behavior with the `accountReturnFirstLink` property.
- If there are multiple accounts, then Identity Security Cloud by default takes the value from the oldest account (based on the account created date). You can configure this behavior by specifying `accountSortAttribute` and `accountSortDescending` attributes.
- If there are multiple accounts and the oldest account has a null attribute value, by default Identity Security Cloud moves to the next account that can have a value (if there are any). You can override this behavior with the `accountReturnFirstLink` property.
- You can filter the multiple accounts returned based on the data they contain so that you can target specific accounts. This is often used to target accounts that are "active" instead of those that are not.
:::

8
docs/extensibility/transforms/operations/replace.md
View File

@@ -22,7 +22,7 @@ The replace transform takes a `regex` attribute as an argument to identify which
{
"attributes": {
"regex": "IIQ",
"replacement": "IdentityNow"
"replacement": "Identity Security Cloud"
},
"type": "replace",
"name": "Replace Transform"
@@ -44,11 +44,11 @@ The replace transform takes a `regex` attribute as an argument to identify which
## Examples
This transform makes a simple word replacement, exchanging "IIQ" for "IdentityNow".
This transform makes a simple word replacement, exchanging "IIQ" for "Identity Security Cloud".
```bash
Input: "Working with IIQ is fun"
Output: "Working with IdentityNow is fun"
Output: "Working with Identity Security Cloud is fun"
```
**Transform Request Body**:
@@ -57,7 +57,7 @@ Output: "Working with IdentityNow is fun"
{
"attributes": {
"regex": "IIQ",
"replacement": "IdentityNow"
"replacement": "Identity Security Cloud"
},
"type": "replace",
"name": "Replace Transform"

2
docs/extensibility/transforms/operations/static.md
View File

@@ -17,7 +17,7 @@ Use the static transform to return a fixed string value, or more commonly, to ev
:::note Other Considerations
- When you are using static transforms within the create profile for a source, you can enter the value directly in the input field if the user selects Static as the attribute type.
- Because IdentityNow supports the ability to order attributes in a create profile, you can use the Velocity template of an attribute higher in the list to generate a static value for an attribute that is lower in the list. For example, if you wanted to generate an email address based on a display name, you would need to do the follwing:
- Because Identity Security Cloud supports the ability to order attributes in a create profile, you can use the Velocity template of an attribute higher in the list to generate a static value for an attribute that is lower in the list. For example, if you wanted to generate an email address based on a display name, you would need to do the follwing:
- Move the "displayName" attribute higher in the list so that it is created before the email address.
- In the "mail" attribute, select Static for the attribute type. In the Static Value field, enter `$displayName@yourdomain.com`.

6
docs/extensibility/transforms/operations/username-generator.md
View File

@@ -25,7 +25,7 @@ Use the username generator transform to specify logic to use when it derives a u
The username generator transform is intended for use as a configuration within the account create profile for a source. Thus, this transform's structure is more extensive than a typical Seaspray implementation -- it must be assigned to a create profile attribute (designated by `name`) and provide certain uniqueness check attributes such as `cloudMaxSize`, `cloudMaxUniqueChecks`, and `cloudRequired`.
The `cloudMaxSize` attribute denotes the maximum length of generated data allowable as a result of the generator logic. The transform truncates any characters over the `cloudMaxSize`. The `cloudMaxUniqueChecks` attribute determines the maximum number of iterations the generator must attempt before failing to generate a value. The `cloudRequired` attribute is an internal flag required for the IdentityNow platform - leave it as `true`.
The `cloudMaxSize` attribute denotes the maximum length of generated data allowable as a result of the generator logic. The transform truncates any characters over the `cloudMaxSize`. The `cloudMaxUniqueChecks` attribute determines the maximum number of iterations the generator must attempt before failing to generate a value. The `cloudRequired` attribute is an internal flag required for the Identity Security Cloud platform - leave it as `true`.
Provide the username generator transform itself in the create profile attribute entry's `transform` parameter.
@@ -101,9 +101,9 @@ Provide the username generator transform itself in the create profile attribute
> **Note** that you can leverage `$uniqueCounter` here to automatically increment a counter if the generated value is not available and you want to try appending numeric values (i.e., 1, 2, 3, etc.) instead of progressing beyond the current pattern.
- **Optional Attributes**
- **sourceCheck** - This boolean value (true/false) indicates whether the generator must check only the IdentityNow database's representation of accounts for uniqueness, or whether it must query the target system directly. If no value is provided, the attribute defaults to `false`.
- **sourceCheck** - This boolean value (true/false) indicates whether the generator must check only the Identity Security Cloud database's representation of accounts for uniqueness, or whether it must query the target system directly. If no value is provided, the attribute defaults to `false`.
- `true` indicates the generator must check the target system directly. The generator only respects this setting if the system supports the `getObject` functionality. For systems that lack the ability to query for single account objects, the generator ignores this setting and defaults to `false`. The generator only checks the attribute identified in the account schema as the `accountID`.
- `false` indicates the generator must check only the IdentityNow database of accounts. The generator only checks the `accountID`.
- `false` indicates the generator must check only the Identity Security Cloud database of accounts. The generator only checks the `accountID`.
## Examples

4
docs/guides/disable-access-profile-requests.md
View File

@@ -12,14 +12,14 @@ tags: ['AccessProfileRequestManagement']
---
## Overview
In IdentityNow, [access profiles](https://documentation.sailpoint.com/saas/help/access/access-profiles.html) are groups of [entitlements](https://documentation.sailpoint.com/saas/help/access/entitlements.html), which represent access rights on [sources](https://documentation.sailpoint.com/saas/help/sources/index.html). By default, all access profiles are marked as requestable. This means that an organization's users can submit [access requests](https://documentation.sailpoint.com/saas/help/requests/index.html) for the access profiles in the IdentityNow [Request Center](https://documentation.sailpoint.com/saas/user-help/requests/request_center.html), where all access profiles are listed.
In Identity Security Cloud, [access profiles](https://documentation.sailpoint.com/saas/help/access/access-profiles.html) are groups of [entitlements](https://documentation.sailpoint.com/saas/help/access/entitlements.html), which represent access rights on [sources](https://documentation.sailpoint.com/saas/help/sources/index.html). By default, all access profiles are marked as requestable. This means that an organization's users can submit [access requests](https://documentation.sailpoint.com/saas/help/requests/index.html) for the access profiles in the Identity Security Cloud [Request Center](https://documentation.sailpoint.com/saas/user-help/requests/request_center.html), where all access profiles are listed.
You can disable requests for access profiles to prevent users from gaining inappropriate or undesired access. In the UI, you can edit the [individual access profile](https://documentation.sailpoint.com/saas/help/requests/config_ap_roles.html#configuring-access-profiles-for-requests) to disable requests for the access profile. You can also use the [PATCH Access Profile endpoint](https://developer.sailpoint.com/docs/api/v3/patch-access-profile) to mark the individual access profile as non-requestable.
You may have many access profiles that you want to disable requests for, and you don't want one to get overlooked and then inappropriately accessed. There are three different processes you can use to ensure that you have disabled requests for all access profiles that aren't currently associated with [applications](https://documentation.sailpoint.com/saas/help/common/app-config.html) configured for access requests. Read this guide to learn how to perform these processes.
## Disable requests for individual access profiles with the UI
Follow these steps to use the IdentityNow UI to individually disable requests for all access profiles that aren't currently associated with applications:
Follow these steps to use the Identity Security Cloud UI to individually disable requests for all access profiles that aren't currently associated with applications:
1. Identify the access profiles that are associated with applications configured for access requests. Create a list of these associated access profiles.
- Go to **Admin > Applications** and open each application you use for access requests. These applications have both 'Visible in the Request Center' and 'Allow Access Requests' marked on the 'Configuration' tab.

12
docs/guides/ip-address-allow-list.md
View File

@@ -21,11 +21,11 @@ In order to create an IP Address Allow list, you need to know what region your t
### Finding your tenant using the admin console
Go to the admin console in IdentityNow and find the 'Org Details' section. You will find your tenant's host region there:
Go to the admin console in Identity Security Cloud and find the 'Org Details' section. You will find your tenant's host region there:
![img](./img/idn-console.PNG)
### Finding your tenant programatically using the IP address returned by IdentityNow
### Finding your tenant programatically using the IP address returned by Identity Security Cloud
If you can't access the admin console or you want to dynamically find the region through code, follow these steps to find it:
@@ -33,13 +33,13 @@ If you can't access the admin console or you want to dynamically find the region
![img](./img/postman1.PNG)
2. After a succesful call to IdentityNow, hover over the globe icon in the response window in postman to get the IP address:
2. After a succesful call to Identity Security Cloud, hover over the globe icon in the response window in postman to get the IP address:
![img](./img/postman2.PNG)
3. Download the [IP Address ranges from AWS](https://ip-ranges.amazonaws.com/ip-ranges.json)
4. Compare the IP address found when calling IdentityNow to the list provided by AWS to determine where your tenant is hosted. You can run a simple Python script to easily find what region the IP address belongs to:
4. Compare the IP address found when calling Identity Security Cloud to the list provided by AWS to determine where your tenant is hosted. You can run a simple Python script to easily find what region the IP address belongs to:
```python
from ipaddress import ip_network, ip_address
@@ -70,7 +70,7 @@ The URL used to find your range of allow list URLs can be constructed using the
https://files.accessiq.sailpoint.com/network/REGION/FILENAME
```
Where REGION is the region of your IdentityNow Tenant and FILENAME is one of the three following:
Where REGION is the region of your Identity Security Cloud Tenant and FILENAME is one of the three following:
```
source_ips.yaml
@@ -94,7 +94,7 @@ which will result in a file similar to the following:
- "52.206.146.115/32"
```
These IP Address ranges can now be used as an allow list to permit any call from your IdentityNow tenant to access your internal network.
These IP Address ranges can now be used as an allow list to permit any call from your Identity Security Cloud tenant to access your internal network.
## Limitations

6
docs/guides/service-accounts.md
View File

@@ -13,13 +13,13 @@ tags: ['Service Account', 'Authentication']
## Service Accounts
Service accounts are identities in IdentityNow (IDN) that aren't real people. Their purpose is to provide credentials for automation services that can be managed and controlled separately from real identities. As a developer of integrations with IDN, there are two main advantages of creating service accounts: you can scope access to the least privilege necessary to do the job, and you can ensure that your integration's access doesn't end when you leave your organization. If you use your user account to generate credentials for integrations, they are tied to your level of access (i.e. admin) and can be revoked when you leave the organization - this could cause downtime in your integrations.
Service accounts are identities in Identity Security Cloud (ISC) that aren't real people. Their purpose is to provide credentials for automation services that can be managed and controlled separately from real identities. As a developer of integrations with ISC, there are two main advantages of creating service accounts: you can scope access to the least privilege necessary to do the job, and you can ensure that your integration's access doesn't end when you leave your organization. If you use your user account to generate credentials for integrations, they are tied to your level of access (i.e. admin) and can be revoked when you leave the organization - this could cause downtime in your integrations.
Read this guide to learn how to create service accounts and implement them.
### Implementing service accounts
Any authoritative source can be used to create and manage service accounts, with Active Directory (AD) being a likely choice. Using AD to create service accounts is advantageous because doing so provisions your service accounts with unique email addresses that can be used to log in to IDN as the service account. However, if you don't want to create service accounts by using AD, you can use a flat file source to create and manage your accounts.
Any authoritative source can be used to create and manage service accounts, with Active Directory (AD) being a likely choice. Using AD to create service accounts is advantageous because doing so provisions your service accounts with unique email addresses that can be used to log in to ISC as the service account. However, if you don't want to create service accounts by using AD, you can use a flat file source to create and manage your accounts.
### Create a delimited file source
@@ -39,7 +39,7 @@ Then open the CSV and add a new service account:
- Set the `id` to a unique value that won't be duplicated anywhere in this file (ex. `SA-001`).
- Set the `name` to quickly describe the account's purpose (ex. `audit01`).
- Set the `e-mail` to a valid email address that you have access to. This is important - you will receive the IDN invite as an email to set the password and login as the service account. This can be your email address or any other email address you have access to (ex `admin@company.com`). You can also reuse this email address as many times as you want.
- Set the `e-mail` to a valid email address that you have access to. This is important - you will receive the ISC invite as an email to set the password and login as the service account. This can be your email address or any other email address you have access to (ex `admin@company.com`). You can also reuse this email address as many times as you want.
- Set the `purpose` to a brief description of what this account is used for. This can help you identify accounts later on when you need to manage and delete old accounts (ex. `Automate monthly audit report`).
Save the CSV and upload it to your source from the 'Import Accounts' tab.

2
docs/iiq.md
View File

@@ -6,7 +6,7 @@ sidebar_label: Identity IQ
sidebar_position: 1
sidebar_class_name: docs
keywords: ['docs']
description: Building extensibility in IdentityNow
description: Building extensibility in Identity Security Cloud
slug: /iiq
tags: ['docs']
---

4
docs/index.md
View File

@@ -13,9 +13,9 @@ tags: ['docs']
## Overview
:::caution What about IdentityNow?
:::caution What about Identity Security Cloud?
Looking for IdentityNow? You're in the right place! IdentityNow has an updated brand in Identity Security Cloud.
Looking for Identity Security Cloud? You're in the right place! Identity Security Cloud has an updated brand in Identity Security Cloud.
:::

0
docs/iiq/plugin-developer-guide/index.md → docs/plugin-developer-guide.md
View File

2
docs/reporting/access-intelligence-center/index.md
View File

@@ -25,7 +25,7 @@ The AIC Audit dashboard focuses on more tangible audit events, such as access re
With Reader permission, users can view any public sheets available and make selections to further filter the data. With Authoring permission, users can view public sheets, create new public or private sheets, and bookmark certain filters for future use.
## IdentityNow Documentation
## Identity Security Cloud Documentation
For information on how to use AIC in your environment, see the documentation [here](https://documentation.sailpoint.com/saas/help/ai/access_insights/access_intelligence.html)
## Technical Documentation and Videos

4
docs/reporting/secure-data-share/index.md
View File

@@ -14,9 +14,9 @@ hide_table_of_contents: true
import MermaidViewer from '@site/src/components/MermaidViewer';
Secure Data Sharing (SDS) makes SailPoint's Identity data available directly to customer via their Snowflake account. DataSet comprises of structured Identity and audit data. Includes relationship tables that connects Identity with other domain entities like entitlements, roles, access profiles, accounts and Apps. This dataset has an additional Audit events table that is a flattened representation of all the events happening in IdentityNow for your organization.
Secure Data Sharing (SDS) makes SailPoint's Identity data available directly to customer via their Snowflake account. DataSet comprises of structured Identity and audit data. Includes relationship tables that connects Identity with other domain entities like entitlements, roles, access profiles, accounts and Apps. This dataset has an additional Audit events table that is a flattened representation of all the events happening in Identity Security Cloud for your organization.
## IdentityNow Documentation
## Identity Security Cloud Documentation
For information on how to use SDS in your environment, see the documentation [here](https://documentation.sailpoint.com/saas/help/secure_data_share/secure_data_share.html).
## Technical Documentation

2
docs/tools/cli/Templates/search.md
View File

@@ -106,4 +106,4 @@ For example, the variable in this template is configured so you can choose how m
}
```
Everything inside this searchQuery object matches the standard format of an [IdentityNow search query](https://documentation.sailpoint.com/saas/help/search/building-query.html). A limited number of examples are provided [here](https://developer.sailpoint.com/docs/api/v3/search-post), but the searchQuery object is mapped to the full search object. This means that you can add any search query values missing from this object.
Everything inside this searchQuery object matches the standard format of an [Identity Security Cloud search query](https://documentation.sailpoint.com/saas/help/search/building-query.html). A limited number of examples are provided [here](https://developer.sailpoint.com/docs/api/v3/search-post), but the searchQuery object is mapped to the full search object. This means that you can add any search query values missing from this object.

2
docs/tools/cli/Templates/spconfig.md
View File

@@ -11,7 +11,7 @@ slug: /tools/cli/templates/spconfig
tags: ['CLI']
---
Use SPConfig templates to perform complex import and export operations with IdentityNow (IDN) configurations.
Use SPConfig templates to perform complex import and export operations with Identity Security Cloud (ISC) configurations.
This is an example of a template file with one SPConfig template populated:

12
docs/tools/cli/connectors.md
View File

@@ -15,7 +15,7 @@ tags: ['CLI']
Learn how to use the CLI to create, manage, and test SaaS connectors in this guide.
You can use SaaS connectors to serve as bridges between your IdentityNow (IDN) tenant and other source systems without the use of a Virtual Appliance (VA). For more information about the SaaS connectors, refer to the [SaaS Connectivity](/docs/connectivity/saas-connectivity) guide.
You can use SaaS connectors to serve as bridges between your Identity Security Cloud (ISC) tenant and other source systems without the use of a Virtual Appliance (VA). For more information about the SaaS connectors, refer to the [SaaS Connectivity](/docs/connectivity/saas-connectivity) guide.
The `connectors` command is a CLI interface for the SaaS Connectivity platform. The CLI is the best way to create, manage, and test SaaS connectors within your tenant.
@@ -46,7 +46,7 @@ This command creates a folder named `connectorProjectName` in your working direc
### Create connector
To create a connector entry in your IDN tenant, run this command:
To create a connector entry in your ISC tenant, run this command:
```shell
sail conn create [connectorAlias]
@@ -56,7 +56,7 @@ This command registers your connector and gives it a unique ID. For more informa
### Upload connector
To upload a connector to your IDN tenant, run `npm run pack-zip` in the project directory to package the connector into a zip file. Then run this command:
To upload a connector to your ISC tenant, run `npm run pack-zip` in the project directory to package the connector into a zip file. Then run this command:
```shell
sail conn upload -c [connectorID | connectorAlias] -f connector.zip
@@ -80,7 +80,7 @@ The entitlement commands require an additional flag (`-t [entitlementType]`), li
sail conn invoke entitlement-list -t [entitlementType] -c [connectorID | connectorAlias] -p [config.json] -v [version]
```
For more information about invoking commands, refer to the [Test your connector in IdentityNow](/docs/connectivity/saas-connectivity/test-build-deploy#test-your-connector-in-identitynow) section of the SaaS Connectivity documentation.
For more information about invoking commands, refer to the [Test your connector in Identity Security Cloud](/docs/connectivity/saas-connectivity/test-build-deploy#test-your-connector-in-identitynow) section of the SaaS Connectivity documentation.
### List connectors
@@ -120,7 +120,7 @@ sail conn delete -c [connectorID]
### Manage tags
You can use tags to create multiple instances of your connector that can be used in IDN. The `latest` tag is created by default and is the primary instance, typically used for production purposes. Tags are similar to branches in a version control system, like git or CVS. You can create a tag for actively developing the connector, or for any other purpose you want.
You can use tags to create multiple instances of your connector that can be used in ISC. The `latest` tag is created by default and is the primary instance, typically used for production purposes. Tags are similar to branches in a version control system, like git or CVS. You can create a tag for actively developing the connector, or for any other purpose you want.
A common pattern is to create a `development` tag on a connector from a specific version, like the latest version.
@@ -134,7 +134,7 @@ As the connector is developed and the version number increases, update the `deve
sail conn tags update -c [connectorID | connectorAlias] -n [tagName] -v [version]
```
You can test the connector in IDN by selecting the connector instance with the `development` tag. The CLI will use the version you point to with the update command.
You can test the connector in ISC by selecting the connector instance with the `development` tag. The CLI will use the version you point to with the update command.
To see a connector's tags and the versions they point to, run this command:

16
docs/tools/cli/index.md
View File

@@ -13,9 +13,9 @@ tags: ['CLI']
## Start using the CLI
The SailPoint CLI is a terminal-based tool you can use to to interact with your IdentityNow (IDN) tenant. The CLI provides a text-based environment you can use to run operations known as "commands" to interact with your tenant however you want.
The SailPoint CLI is a terminal-based tool you can use to to interact with your Identity Security Cloud (ISC) tenant. The CLI provides a text-based environment you can use to run operations known as "commands" to interact with your tenant however you want.
You can use the CLI to perform many functions you would have otherwise used Postman or custom scripts to perform before. For example, you can use the CLI to call the SailPoint APIs to do whatever you want in your IDN tenant, and you can do all this directly on the command line, with minimal setup.
You can use the CLI to perform many functions you would have otherwise used Postman or custom scripts to perform before. For example, you can use the CLI to call the SailPoint APIs to do whatever you want in your ISC tenant, and you can do all this directly on the command line, with minimal setup.
Learn how to use the SailPoint command line interface (CLI) in this guide.
@@ -106,9 +106,9 @@ sudo yum localinstall /path/to/rpm/package/sail_x.x.x_linux_amd64.rpm
## Configuration
To configure the CLI to connect and authenticate to your IDN tenant, you must do the following:
To configure the CLI to connect and authenticate to your ISC tenant, you must do the following:
- Find your tenant name. To learn how to find it, refer to [Getting Started](/docs/api/getting-started#find-your-tenant-name). The CLI will use this tenant name to connect to your IDN instance.
- Find your tenant name. To learn how to find it, refer to [Getting Started](/docs/api/getting-started#find-your-tenant-name). The CLI will use this tenant name to connect to your ISC instance.
- OAuth
- PAT | Create a personal access token (PAT). Make sure to note the "Client ID" and "Client Secret." The CLI needs this information to authenticate successfully. To learn how to create a PAT, refer to [Personal Access Tokens](/docs/api/authentication#personal-access-tokens).
@@ -119,8 +119,8 @@ sail env {environment}
with `{environment}` being the name of the environment you wish to configure.
You will be prompted for the following information:
- The Tenant URL - The web URL used to access your IdentityNow tenant (ex. https://tenant.identitynow.com), this is used during the OAuth process.
- The API URL - The API URL used to access your IdentityNow tenant (ex. https://tenant.api.identitynow.com), this is used for the api calls made by certain commands.
- The Tenant URL - The web URL used to access your Identity Security Cloud tenant (ex. https://tenant.identitynow.com), this is used during the OAuth process.
- The API URL - The API URL used to access your Identity Security Cloud tenant (ex. https://tenant.api.identitynow.com), this is used for the api calls made by certain commands.
### OAuth Authentication
@@ -174,9 +174,9 @@ Run the `sail` command for an overview of available commands and flags. You can
These commands are available:
- `connectors`: This command is a CLI interface for the SaaS Connectivity platform. The CLI is the best way to create and manage SaaS connectors within your tenant. For more information about the `connectors` command, refer to the CLI [Connectors guide](/docs/tools/cli/connectors).
- `search`: Run this command to access IDN search functionality within the CLI. For more information about the `search` command, refer to the CLI [Search guide](/docs/tools/cli/search).
- `search`: Run this command to access ISC search functionality within the CLI. For more information about the `search` command, refer to the CLI [Search guide](/docs/tools/cli/search).
- `set`: Run this command to configure your CLI settings. For more information about the `set` command, refer to the CLI [Set guide](/docs/tools/cli/set).
- `spconfig`: Run this command to access IDN SP Config functionality. For more information about the `spconfig` command, refer to the CLI [SPConfig guide](/docs/tools/cli/spconfig).
- `spconfig`: Run this command to access ISC SP Config functionality. For more information about the `spconfig` command, refer to the CLI [SPConfig guide](/docs/tools/cli/spconfig).
- `transform`: This command is a CLI interface that makes it easy to create, manage, and test transforms. For more information about the `transform` command, refer to the CLI [Transforms guide](/docs/tools/cli/transforms).
- `va`: Run this command to access VAs connected to your tenant. For more information about the `va` command, refer to the CLI [VA guide](/docs/tools/cli/va).
- `cluster`: Run this command to access VA clusters connected to your tenant. For more information about the `cluster` command, refer to the CLI [Clusters guide](/docs/tools/cli/cluster).

20
docs/tools/cli/search.md
View File

@@ -6,20 +6,20 @@ sidebar_label: Search
sidebar_position: 3
sidebar_class_name: cli
keywords: ['cli', 'search']
description: Learn how to use the CLI to search your IDN tenant in this guide.
description: Learn how to use the CLI to search your ISC tenant in this guide.
slug: /tools/cli/search
tags: ['CLI']
---
# Search
Learn how to use the CLI to search your IDN tenant in this guide.
Learn how to use the CLI to search your ISC tenant in this guide.
In IdentityNow (IDN), you can search across all the sources connected to your tenant and return virtually any information you have access to. The `search` command allows you to access IDN search functionality within the CLI. For more information about the `search` command, refer to the CLI [Search guide](docs/tools/cli/search). For more information about search in IDN, refer to [Search](docs/api/v3/search).
In Identity Security Cloud (ISC), you can search across all the sources connected to your tenant and return virtually any information you have access to. The `search` command allows you to access ISC search functionality within the CLI. For more information about the `search` command, refer to the CLI [Search guide](docs/tools/cli/search). For more information about search in ISC, refer to [Search](docs/api/v3/search).
In IdentityNow, you can search all the sources connected to your tenant and return virtually any information you have access to. To learn more about search in IdentityNow, refer to [Search](https://documentation.sailpoint.com/saas/help/search/index.html).
In Identity Security Cloud, you can search all the sources connected to your tenant and return virtually any information you have access to. To learn more about search in Identity Security Cloud, refer to [Search](https://documentation.sailpoint.com/saas/help/search/index.html).
The `search` command makes it easy to search in IdentityNow with the SailPoint CLI. Read this guide to learn how to use the `query` and `template` commands to search IdentityNow with the CLI.
The `search` command makes it easy to search in Identity Security Cloud with the SailPoint CLI. Read this guide to learn how to use the `query` and `template` commands to search Identity Security Cloud with the CLI.
- [Search](#search)
- [Query](#query)
@@ -35,11 +35,11 @@ The `search` command makes it easy to search in IdentityNow with the SailPoint C
## Query
Search queries in IdentityNow are flexible - they can be very broad or very narrow, and you can further narrow your results by using IdentityNow's specific syntax to structure your queries. To learn about structuring search queries, refer to [Building a Search Query](https://documentation.sailpoint.com/saas/help/search/building-query.html).
Search queries in Identity Security Cloud are flexible - they can be very broad or very narrow, and you can further narrow your results by using Identity Security Cloud's specific syntax to structure your queries. To learn about structuring search queries, refer to [Building a Search Query](https://documentation.sailpoint.com/saas/help/search/building-query.html).
The `query` command allows you to search IdentityNow for a query you specify.
The `query` command allows you to search Identity Security Cloud for a query you specify.
To use the `query` command to search IdentityNow, you must understand how to format your search queries.
To use the `query` command to search Identity Security Cloud, you must understand how to format your search queries.
The basic format of a query is "field:term", so an example `query` command would like this:
@@ -129,7 +129,7 @@ sail search query "name:a*" --indices identities --folderPath ./local/folder/pat
For more detailed search queries, you can provide a predefined template instead of constructing the whole query every time. This allows you to run very detailed search queries quickly and easily.
The `template` command allows you to use predefined templates to search IdentityNow.
The `template` command allows you to use predefined templates to search Identity Security Cloud.
### Command
@@ -139,7 +139,7 @@ This example shows the essential `template` command structure:
sail search template all-provisioning-events-90-days
```
The specified template file will give the CLI all the information it needs to perform its search in IdentityNow.
The specified template file will give the CLI all the information it needs to perform its search in Identity Security Cloud.
### Flags

16
docs/tools/cli/spconfig.md
View File

@@ -15,7 +15,7 @@ tags: ['CLI']
Learn how to use the CLI to import and export configurations.
You can use the [SP Config APIs](/docs/api/beta/sp-config) to import configurations into IDN and export them out.
You can use the [SP Config APIs](/docs/api/beta/sp-config) to import configurations into ISC and export them out.
With the `spconfig` command, you can access the same functionality.
@@ -38,9 +38,9 @@ To perform SPConfig operations, you can run these commands:
### Download
You can use the `download` command to download import and export job results from IDN. The `download` command is specified differently for **Linux/Mac** and **Windows**, respectively.
You can use the `download` command to download import and export job results from ISC. The `download` command is specified differently for **Linux/Mac** and **Windows**, respectively.
To download import and export job results from IDN on **Linux/Mac**, run this command:
To download import and export job results from ISC on **Linux/Mac**, run this command:
```shell
sail spconfig download \
@@ -48,7 +48,7 @@ sail spconfig download \
--export {export job ID}
```
To download import and export job results from IDN on **Windows**, run this command:
To download import and export job results from ISC on **Windows**, run this command:
```shell
sail spconfig download \
@@ -66,7 +66,7 @@ You can add these flags to the `download` command:
### Import
To begin an import task in IDN, run this command:
To begin an import task in ISC, run this command:
```shell
sail spconfig import \
@@ -81,7 +81,7 @@ You can add these flags to the `import` command:
### Export
To begin an export task in IDN, run this command:
To begin an export task in ISC, run this command:
```shell
sail spconfig export \
@@ -102,7 +102,7 @@ You can add these flags to the `export` command:
### Status
To check the status of import and export jobs in IDN, run this command:
To check the status of import and export jobs in ISC, run this command:
```shell
sail spconfig status --import {import job ID to check} --export {export job ID to check}
@@ -117,7 +117,7 @@ You can add these flags to the `status` command:
### Template
To begin exporting a template from IDN, run this command:
To begin exporting a template from ISC, run this command:
```shell
sail spconfig template

4
docs/tools/cli/transforms.md
View File

@@ -15,7 +15,7 @@ tags: ['CLI']
Learn about the CLI commands you can use to create, manage, and test transforms in this guide.
In IdentityNow (IDN), you can use transforms to manipulate attribute data without writing any code. For more information about transforms, refer to [Transforms](/docs/extensibility/transforms).
In Identity Security Cloud (ISC), you can use transforms to manipulate attribute data without writing any code. For more information about transforms, refer to [Transforms](/docs/extensibility/transforms).
With the `transforms` command, it's it easy to create, manage, and test transforms in the CLI.
@@ -73,7 +73,7 @@ To update a transform from a `json` file, run the following command. Use the `-f
sail transform update -f transform.json
```
A common workflow is to first download the transforms, then make edits to the transform file, and then use the update command to save those edits in IDN.
A common workflow is to first download the transforms, then make edits to the transform file, and then use the update command to save those edits in ISC.
## Delete transform

2
docs/tools/cli/workflow.md
View File

@@ -15,7 +15,7 @@ tags: ['CLI']
Learn how to use the SailPoint CLI to create, manage, and test workflows in this guide.
A workflow is a set of steps that are completed whenever a specific event occurs. Once that event triggers the workflow, the workflow performs the steps within IdentityNow.
A workflow is a set of steps that are completed whenever a specific event occurs. Once that event triggers the workflow, the workflow performs the steps within Identity Security Cloud.
The `workflow` command makes it easy to create, manage, and test workflows from within the SailPoint CLI. To learn more about workflows, refer to [Workflows](https://documentation.sailpoint.com/saas/help/workflows/workflow-basics.html?h=workflow).

6
docs/tools/rule-development-kit/index.md
View File

@@ -60,7 +60,7 @@ src/
* **`src/main/java/`** Use this folder to develop your rules before putting them into the rule XML format. Import objects as needed from `sailpoint.*`
* **`src/main/resources/rules/`** Use this folder to store your rules in the XML format you would expect to upload to IdentityNow (IDN).
* **`src/main/resources/rules/`** Use this folder to store your rules in the XML format you would expect to upload to Identity Security Cloud (ISC).
* **`src/test/java/sailpoint/`** Use this folder for test classes to test your rules.
@@ -84,7 +84,7 @@ The rule development kit provides you with intellisense when writing rules, you
## Create your new rule
To get syntax highlighting and the features from the IDE, this guide shows how to write the rule in native Java and move it over to the XML format needed when you're storing it in IdentityNow (IDN).
To get syntax highlighting and the features from the IDE, this guide shows how to write the rule in native Java and move it over to the XML format needed when you're storing it in Identity Security Cloud (ISC).
This guide will walk through an example of how to duplicate writing the 'Username Generator' rule that ships with the RDK.
@@ -527,7 +527,7 @@ Interpreter i = new Interpreter();
### Mock the objects and return the mocked data
Anywhere your rule uses data from IDN, you will need to mock out those objects. In the 'Username Generator' example, the objects used are `IdnRuleUtil`, `Application`, and `Identity`.
Anywhere your rule uses data from ISC, you will need to mock out those objects. In the 'Username Generator' example, the objects used are `IdnRuleUtil`, `Application`, and `Identity`.
```java
IdnRuleUtil idn = mock();

2
docs/tools/sdk/go/search.md
View File

@@ -11,7 +11,7 @@ slug: /tools/sdk/go/search
tags: ['SDK', 'Software Development Kit']
---
To try using the IDN [search functionality](/docs/api/v3/search-post) along with pagination, copy this code into your "sdk.go" file, following the main code:
To try using the ISC [search functionality](/docs/api/v3/search-post) along with pagination, copy this code into your "sdk.go" file, following the main code:
```go
func getSearchResults(ctx context.Context, apiClient *sailpoint.APIClient) {

4
docs/tools/sdk/powershell/search.md
View File

@@ -11,7 +11,7 @@ slug: /tools/sdk/powershell/search
tags: ['SDK']
---
The PowerShell SDK provides you access to IdentityNow's [Search](https://documentation.sailpoint.com/saas/help/search/index.html) functionality.
The PowerShell SDK provides you access to Identity Security Cloud's [Search](https://documentation.sailpoint.com/saas/help/search/index.html) functionality.
Here is an example search you can copy into your PowerShell instance to try it out:
@@ -79,7 +79,7 @@ try {
}
```
This example searches your IdentityNow tenant for all identities and sorts them by their `displayName` in descending order. The search returns a maximum of 150000 records (the `Limit`) and 5000 records per page (the `Increment`).
This example searches your Identity Security Cloud tenant for all identities and sorts them by their `displayName` in descending order. The search returns a maximum of 150000 records (the `Limit`) and 5000 records per page (the `Increment`).
To paginate the search results, you can specify these parameters:

2
docs/tools/sdk/typescript/search.md
View File

@@ -11,7 +11,7 @@ slug: /tools/sdk/typescript/search
tags: ['SDK']
---
To try using the IDN [search functionality](/docs/api/v3/search-post) along with pagination, copy this code into your "index.ts" file:
To try using the ISC [search functionality](/docs/api/v3/search-post) along with pagination, copy this code into your "index.ts" file:
```typescript
const search = async () => {

442
plugins.js
View File

@@ -23,6 +23,436 @@ module.exports = [
to: '/ambassador',
from: ['/ambassador-program'],
},
{
from: ['/idn/docs/event-triggers'],
to: '/docs/extensibility/event-triggers',
},
{
from: ['/idn/docs/event-triggers/available'],
to: '/docs/extensibility/event-triggers/available',
},
{
from: ['/idn/docs/event-triggers/early-access'],
to: '/docs/extensibility/event-triggers/early-access',
},
{
from: ['/idn/docs/event-triggers/filtering-events'],
to: '/docs/extensibility/event-triggers/filtering-events',
},
{
from: ['/idn/docs/event-triggers/preparing-subscriber-service'],
to: '/docs/extensibility/event-triggers/preparing-subscriber-service',
},
{
from: [
'/idn/docs/event-triggers/responding-request-response-trigger',
],
to: '/docs/extensibility/event-triggers/responding-request-response-trigger',
},
{
from: ['/idn/docs/event-triggers/subscribing-to-trigger'],
to: '/docs/extensibility/event-triggers/subscribing-to-trigger',
},
{
from: ['/idn/docs/event-triggers/testing-triggers'],
to: '/docs/extensibility/event-triggers/testing-triggers',
},
{
from: ['/idn/docs/event-triggers/trigger-types'],
to: '/docs/extensibility/event-triggers/trigger-types',
},
{
from: ['/idn/docs/event-triggers/triggers/access-request-decision'],
to: '/docs/extensibility/event-triggers/triggers/access-request-decision',
},
{
from: [
'/idn/docs/event-triggers/triggers/access-request-dynamic-approval',
],
to: '/docs/extensibility/event-triggers/triggers/access-request-dynamic-approval',
},
{
from: ['/idn/docs/event-triggers/triggers/access-request-submitted'],
to: '/docs/extensibility/event-triggers/triggers/access-request-submitted',
},
{
from: [
'/idn/docs/event-triggers/triggers/account-aggregation-completed',
],
to: '/docs/extensibility/event-triggers/triggers/account-aggregation-completed',
},
{
from: ['/idn/docs/event-triggers/triggers/campaign-activated'],
to: '/docs/extensibility/event-triggers/triggers/campaign-activated',
},
{
from: ['/idn/docs/event-triggers/triggers/campaign-ended'],
to: '/docs/extensibility/event-triggers/triggers/campaign-ended',
},
{
from: ['/idn/docs/event-triggers/triggers/campaign-generated'],
to: '/docs/extensibility/event-triggers/triggers/campaign-generated',
},
{
from: ['/idn/docs/event-triggers/triggers/certification-signed-off'],
to: '/docs/extensibility/event-triggers/triggers/certification-signed-off',
},
{
from: ['/idn/docs/event-triggers/triggers/form-submitted'],
to: '/docs/extensibility/event-triggers/triggers/form-submitted',
},
{
from: [
'/idn/docs/event-triggers/triggers/identity-attribute-changed',
],
to: '/docs/extensibility/event-triggers/triggers/identity-attribute-changed',
},
{
from: ['/idn/docs/event-triggers/triggers/identity-created'],
to: '/docs/extensibility/event-triggers/triggers/identity-created',
},
{
from: ['/idn/docs/event-triggers/triggers/identity-deleted'],
to: '/docs/extensibility/event-triggers/triggers/identity-deleted',
},
{
from: [
'/idn/docs/event-triggers/triggers/native-change-account-created',
],
to: '/docs/extensibility/event-triggers/triggers/native-change-account-created',
},
{
from: [
'/idn/docs/event-triggers/triggers/native-change-account-deleted',
],
to: '/docs/extensibility/event-triggers/triggers/native-change-account-deleted',
},
{
from: [
'/idn/docs/event-triggers/triggers/native-change-account-updated',
],
to: '/docs/extensibility/event-triggers/triggers/native-change-account-updated',
},
{
from: ['/idn/docs/event-triggers/triggers/outlier-detected'],
to: '/docs/extensibility/event-triggers/triggers/outlier-detected',
},
{
from: ['/idn/docs/event-triggers/triggers/provisioning-completed'],
to: '/docs/extensibility/event-triggers/triggers/provisioning-completed',
},
{
from: ['/idn/docs/event-triggers/triggers/scheduled-search'],
to: '/docs/extensibility/event-triggers/triggers/scheduled-search',
},
{
from: ['/idn/docs/event-triggers/triggers/source-account-created'],
to: '/docs/extensibility/event-triggers/triggers/source-account-created',
},
{
from: ['/idn/docs/event-triggers/triggers/source-account-deleted'],
to: '/docs/extensibility/event-triggers/triggers/source-account-deleted',
},
{
from: ['/idn/docs/event-triggers/triggers/source-account-updated'],
to: '/docs/extensibility/event-triggers/triggers/source-account-updated',
},
{
from: ['/idn/docs/event-triggers/triggers/source-created'],
to: '/docs/extensibility/event-triggers/triggers/source-created',
},
{
from: ['/idn/docs/event-triggers/triggers/source-deleted'],
to: '/docs/extensibility/event-triggers/triggers/source-deleted',
},
{
from: ['/idn/docs/event-triggers/triggers/source-updated'],
to: '/docs/extensibility/event-triggers/triggers/source-updated',
},
{
from: ['/idn/docs/event-triggers/triggers/va-cluster-status-change'],
to: '/docs/extensibility/event-triggers/triggers/va-cluster-status-change',
},
{
from: ['/idn/docs/rules'],
to: '/docs/extensibility/rules',
},
{
from: ['/idn/docs/rules/cloud-rules'],
to: '/docs/extensibility/rules/cloud-rules',
},
{
from: [
'/idn/docs/rules/cloud-rules/account-profile-attribute-generator',
],
to: '/docs/extensibility/rules/cloud-rules/account-profile-attribute-generator',
},
{
from: [
'/idn/docs/rules/cloud-rules/account-profile-attribute-generator-template',
],
to: '/docs/extensibility/rules/cloud-rules/account-profile-attribute-generator-template',
},
{
from: ['/idn/docs/rules/cloud-rules/before-provisioning-rule'],
to: '/docs/extensibility/rules/cloud-rules/before-provisioning-rule',
},
{
from: ['/idn/docs/rules/cloud-rules/buildmap-rule'],
to: '/docs/extensibility/rules/cloud-rules/buildmap-rule',
},
{
from: ['/idn/docs/rules/cloud-rules/correlation-rule'],
to: '/docs/extensibility/rules/cloud-rules/correlation-rule',
},
{
from: ['/idn/docs/rules/cloud-rules/generic-rule'],
to: '/docs/extensibility/rules/cloud-rules/generic-rule',
},
{
from: ['/idn/docs/rules/cloud-rules/identity-attribute-rule'],
to: '/docs/extensibility/rules/cloud-rules/identity-attribute-rule',
},
{
from: ['/idn/docs/rules/cloud-rules/manager-correlation-rule'],
to: '/docs/extensibility/rules/cloud-rules/manager-correlation-rule',
},
{
from: ['/idn/docs/rules/connector-rules'],
to: '/docs/extensibility/rules/connector-rules',
},
{
from: [
'/idn/docs/rules/connector-rules/before-and-after-rule-operations',
],
to: '/docs/extensibility/rules/connector-rules/before-and-after-rule-operations',
},
{
from: ['/idn/docs/rules/connector-rules/jdbc-buildmap-rule'],
to: '/docs/extensibility/rules/connector-rules/jdbc-buildmap-rule',
},
{
from: ['/idn/docs/rules/connector-rules/jdbc-provisioning-rule'],
to: '/docs/extensibility/rules/connector-rules/jdbc-provisioning-rule',
},
{
from: ['/idn/docs/rules/connector-rules/sap-buildmap-rule'],
to: '/docs/extensibility/rules/connector-rules/sap-buildmap-rule',
},
{
from: [
'/idn/docs/rules/connector-rules/sap-provisioning-modify-rule',
],
to: '/docs/extensibility/rules/connector-rules/sap-provisioning-modify-rule',
},
{
from: [
'/idn/docs/rules/connector-rules/webservices-after-provisioning-rule',
],
to: '/docs/extensibility/rules/connector-rules/webservices-after-provisioning-rule',
},
{
from: [
'/idn/docs/rules/connector-rules/webservices-before-provisioning-rule',
],
to: '/docs/extensibility/rules/connector-rules/webservices-before-provisioning-rule',
},
{
from: ['/idn/docs/rules/guides'],
to: '/docs/extensibility/rules/guides',
},
{
from: ['/idn/docs/rules/guides/your-first-rule'],
to: '/docs/extensibility/rules/guides/your-first-rule',
},
{
from: ['/idn/docs/rules/java-docs'],
to: '/docs/extensibility/rules/java-docs',
},
{
from: ['/idn/docs/rules/rule-utility'],
to: '/docs/extensibility/rules/rule-utility',
},
{
from: ['/idn/docs/transforms'],
to: '/docs/extensibility/transforms',
},
{
from: ['/idn/docs/transforms/guides'],
to: '/docs/extensibility/transforms/guides',
},
{
from: ['/idn/docs/transforms/guides/identity-context-examples'],
to: '/docs/extensibility/transforms/guides/identity-context-examples',
},
{
from: ['/idn/docs/transforms/guides/lifecycle-state-transform'],
to: '/docs/extensibility/transforms/guides/lifecycle-state-transform',
},
{
from: ['/idn/docs/transforms/guides/temporary-password'],
to: '/docs/extensibility/transforms/guides/temporary-password',
},
{
from: [
'/idn/docs/transforms/guides/transforms-in-provisioning-policies',
],
to: '/docs/extensibility/transforms/guides/transforms-in-provisioning-policies',
},
{
from: ['/idn/docs/transforms/guides/your-first-transform'],
to: '/docs/extensibility/transforms/guides/your-first-transform',
},
{
from: ['/idn/docs/transforms/operations'],
to: '/docs/extensibility/transforms/operations',
},
{
from: ['/idn/docs/transforms/operations/account-attribute'],
to: '/docs/extensibility/transforms/operations/account-attribute',
},
{
from: ['/idn/docs/transforms/operations/base64-decode'],
to: '/docs/extensibility/transforms/operations/base64-decode',
},
{
from: ['/idn/docs/transforms/operations/base64-encode'],
to: '/docs/extensibility/transforms/operations/base64-encode',
},
{
from: ['/idn/docs/transforms/operations/concatenation'],
to: '/docs/extensibility/transforms/operations/concatenation',
},
{
from: ['/idn/docs/transforms/operations/conditional'],
to: '/docs/extensibility/transforms/operations/conditional',
},
{
from: ['/idn/docs/transforms/operations/date-compare'],
to: '/docs/extensibility/transforms/operations/date-compare',
},
{
from: ['/idn/docs/transforms/operations/date-format'],
to: '/docs/extensibility/transforms/operations/date-format',
},
{
from: ['/idn/docs/transforms/operations/date-math'],
to: '/docs/extensibility/transforms/operations/date-math',
},
{
from: ['/idn/docs/transforms/operations/decompose-diacritical-marks'],
to: '/docs/extensibility/transforms/operations/decompose-diacritical-marks',
},
{
from: ['/idn/docs/transforms/operations/e164-phone'],
to: '/docs/extensibility/transforms/operations/e164-phone',
},
{
from: ['/idn/docs/transforms/operations/first-valid'],
to: '/docs/extensibility/transforms/operations/first-valid',
},
{
from: ['/idn/docs/transforms/operations/generate-random-string'],
to: '/docs/extensibility/transforms/operations/generate-random-string',
},
{
from: ['/idn/docs/transforms/operations/get-end-of-string'],
to: '/docs/extensibility/transforms/operations/get-end-of-string',
},
{
from: [
'/idn/docs/transforms/operations/get-reference-identity-attribute',
],
to: '/docs/extensibility/transforms/operations/get-reference-identity-attribute',
},
{
from: ['/idn/docs/transforms/operations/identity-attribute'],
to: '/docs/extensibility/transforms/operations/identity-attribute',
},
{
from: ['/idn/docs/transforms/operations/index-of'],
to: '/docs/extensibility/transforms/operations/index-of',
},
{
from: ['/idn/docs/transforms/operations/iso-3166'],
to: '/docs/extensibility/transforms/operations/iso-3166',
},
{
from: ['/idn/docs/transforms/operations/last-index-of'],
to: '/docs/extensibility/transforms/operations/last-index-of',
},
{
from: ['/idn/docs/transforms/operations/left-pad'],
to: '/docs/extensibility/transforms/operations/left-pad',
},
{
from: ['/idn/docs/transforms/operations/lookup'],
to: '/docs/extensibility/transforms/operations/lookup',
},
{
from: ['/idn/docs/transforms/operations/lower'],
to: '/docs/extensibility/transforms/operations/lower',
},
{
from: ['/idn/docs/transforms/operations/name-normalizer'],
to: '/docs/extensibility/transforms/operations/name-normalizer',
},
{
from: ['/idn/docs/transforms/operations/random-alphanumeric'],
to: '/docs/extensibility/transforms/operations/random-alphanumeric',
},
{
from: ['/idn/docs/transforms/operations/random-numeric'],
to: '/docs/extensibility/transforms/operations/random-numeric',
},
{
from: ['/idn/docs/transforms/operations/reference'],
to: '/docs/extensibility/transforms/operations/reference',
},
{
from: ['/idn/docs/transforms/operations/replace'],
to: '/docs/extensibility/transforms/operations/replace',
},
{
from: ['/idn/docs/transforms/operations/replace-all'],
to: '/docs/extensibility/transforms/operations/replace-all',
},
{
from: ['/idn/docs/transforms/operations/right-pad'],
to: '/docs/extensibility/transforms/operations/right-pad',
},
{
from: ['/idn/docs/transforms/operations/rule'],
to: '/docs/extensibility/transforms/operations/rule',
},
{
from: ['/idn/docs/transforms/operations/split'],
to: '/docs/extensibility/transforms/operations/split',
},
{
from: ['/idn/docs/transforms/operations/static'],
to: '/docs/extensibility/transforms/operations/static',
},
{
from: ['/idn/docs/transforms/operations/substring'],
to: '/docs/extensibility/transforms/operations/substring',
},
{
from: ['/idn/docs/transforms/operations/trim'],
to: '/docs/extensibility/transforms/operations/trim',
},
{
from: ['/idn/docs/transforms/operations/upper'],
to: '/docs/extensibility/transforms/operations/upper',
},
{
from: ['/idn/docs/transforms/operations/username-generator'],
to: '/docs/extensibility/transforms/operations/username-generator',
},
{
from: ['/idn/docs/transforms/operations/uuid-generator'],
to: '/docs/extensibility/transforms/operations/uuid-generator',
},
{
from: ['/idn/docs/access-intelligence-center'],
to: '/docs/reporting/access-intelligence-center',
@@ -533,10 +963,6 @@ module.exports = [
from: ['/iiq/api/get-workflow-by-id'],
to: '/docs/api/iiq/get-workflow-by-id',
},
{
from: ['/iiq/api/identityiq-scim-rest-api'],
to: '/docs/api/iiq/identityiq-scim-rest-api',
},
{
from: ['/iiq/api/launch-workflow'],
to: '/docs/api/iiq/launch-workflow',
@@ -607,7 +1033,7 @@ module.exports = [
},
{
from: ['/nerm/api/nerm-api'],
to: '/docs/api/nerm/nerm-api'
to: '/docs/api/nerm/v1/nerm-api',
},
{
from: ['/nerm/api'],
@@ -615,7 +1041,7 @@ module.exports = [
},
{
from: ['/nerm/api/authentication'],
to: '/docs/api/nerm/v1/authentication',
to: '/docs/api/nerm/authentication',
},
{
from: ['/nerm/api/create-approval-action'],
@@ -973,10 +1399,6 @@ module.exports = [
from: ['/nerm/api/getting-started'],
to: '/docs/api/nerm/getting-started',
},
{
from: ['/nerm/api/nerm-api'],
to: '/docs/api/nerm/v1/nerm-api',
},
{
from: ['/nerm/api/pagination-metadata-filtering'],
to: '/docs/api/nerm/pagination-metadata-filtering',

4
sidebars.js
View File

@@ -115,7 +115,7 @@ const sidebars = {
slug: '/api/nerm/v1',
},
// @ts-ignore
items: require('./docs/api/nerm/sidebar.js'),
items: require('./docs/api/nerm/v1/sidebar.js'),
},
],
},
@@ -232,7 +232,7 @@ const sidebars = {
label: 'Plugin Developer Guide',
link: {
type: 'doc',
id: 'iiq/plugin-developer-guide/plugin-developer-guide',
id: 'plugin-developer-guide',
},
items: [
{