Converse agora com nosso suporte
Chat com o suporte

Starling Connect Hosted - One Identity Manager Administration Guide

About this guide One Identity Starling Connect overview One Identity Starling Supported cloud applications Working with connectors Connector versions Salesforce Facebook Workplace SAP Cloud Platform JIRA Server RSA Archer SuccessFactors AWS IAM ServiceNow Dropbox Crowd Atlassian JIRA Confluence Trello Box Pipedrive SuccessFactors HR NutShell Insightly Egnyte SugarCRM Oracle IDCS Statuspage Zendesk Sell Workbooks DocuSign Citrix ShareFile Zendesk Azure AD Google Workspace Concur Tableau GoToMeeting Coupa AWS Cognito Okta DataDog Hideez Opsgenie Informatica Cloud Services AppDynamics Marketo Workday HR OneLogin PingOne Aha! SAP Litmos HackerRank Slack ActiveCampaign Webex Apigee Databricks Hive PagerDuty Dayforce Smartsheet Pingboard SAP Cloud for Customer Azure Infrastructure Oracle Fusion Cloud Majesco LuccaHR OpenText JFrog Artifactory xMatters Discourse Testrail ChipSoft PingOne Platform Azure DevOps UKG PRO Atlassian Cloud Appendix: Creating a service account in Google Workspace Appendix: Setting a trial account on Salesforce Registering the application, providing necessary permissions, retrieving Client Id and Client Secret from the Azure AD tenant Generating a private key for service account in GoToMeeting Configuring AWS IAM connector to support entitlements for User and Group Configuring Box connector to support additional email IDs for users One Identity Manager E2E integration needs for Hideez connector Configuring custom attributes for ServiceNow v.1.0 Configuring custom attributes for Coupa v.1.0 Configuring custom attributes in connectors Disabling attributes Configuring a connector that uses the consent feature Synchronization and integration of Roles object type with One Identity Manager Synchronization and integration of Workspaces object type with One Identity Manager Synchronization and integration of Products object type with One Identity Manager User centric membership Creating multi-valued custom fields in One Identity Manager Synchronization and assignment of PermissionSets to Users with One Identity Manager Connectors that support password attribute in User object Connectors that do not support special characters in the object ID Creating an app for using SCIM on Slack Enterprise Grid Organization Creating a Webex integration application, providing necessary scopes, retrieving Client Id and Client Secret Retrieving the API key from Facebook Workplace Outbound IP addresses Values for customer-specific configuration parameters in Workday HR connector Initiate an OAuth connection to SuccessFactors Creating custom editable/upsertable attributes in Successfactors employee central Custom Foundation Objects in Successfactors HR connector Configuring additional datetime offset in connectors How to Create custom attribute for Users in SuccessFactors portal SAP Cloud for Customer - Steps to add custom fields at One Identity Manager attributes Creating a Service Principal for the Azure Infrastructure Connector Workday permissions needed to integrate via the Starling Connector Configuring integration application in DocuSign Creating integration Connect Client in Coupa Retrieving Azure DevOps Personal Access Token (PAT) Setup integration system and field override service in Workday Retrieving Atlassian Cloud API Key and Directory ID

Okta

The Okta connector allows you to connect Okta with One Identity Starling Connect enabling you to take advantage of the features and products available in Starling Connect that complement and enhance the services provided by Okta.

Okta provides single sign-on, multi-factor authentication and Platform Services, which is a set of modular components that can be used to address requirements that are specific to an organization.

Supervisor configuration parameters

To configure the connector, following parameters are required:

  • Connector name

  • Token

  • Target URL (Cloud application's instance URL used as targetURI in payload)
  • Instance DateTime Offset (refer Configuring additional datetime offset in connectors for more details) 

  • Request Delay (in ms)

    NOTE: To handle the Okta rate limit issue, the Okta connector has been enabled with user configurable delay in milliseconds so that the each request to the target API would wait for the specific amount of time to help the connector to prevent the throttling of the Okta APIs. The default value for the configuration is 1000 (milliseconds) and OneIdentity recommends to keep the value below 2000 (milliseconds).

Configuring custom attributes for Okta

You can configure custom attributes for the Okta connector in Starling Connect for Users and Groups in the Custom Attributes section in Schema Configuration.

NOTE: For more information about how to configure custom attributes in Okta, see Configuring custom attributes in connectors.

Support for MultiValued Custom attributes

  • In connector schema, only String datatype corresponds to the multivalued custom attribute.

  • Connector output format for multivalued custom attributes will be as shown below:

    • "MultivaluedAttributeName" : "[abcd;; efgh;; xyzw;; uvty]"

  • As per the connector output format, the values will be double semicolon separated(;;) and will be enclosed inside opening and closing square brackets.

  • Opening and closing square brackets help to ensure that the attribute is of multivalued type.

Supported objects and operations

Users

Table 208: Supported operations for Users

Operation

VERB

Create User POST
Update User PUT
Delete User DELETE
Get User GET
Get All Users GET
Get All Users with pagination GET

Groups

Table 209: Supported operations for Groups

Operation

VERB

Create Group POST
Update Group PUT
Delete Group DELETE
Get Group GET
Get All Groups GET
Get All Groups with pagination GET
Create Membership POST

Add Membership

POST

Delete Membership

DELETE

Mandatory fields

Users

  • GivenName

  • FamilyName
  • Username
  • Email
  • Password

Groups

  • DisplayName

User and Group mapping

The user and group mappings are listed in the tables below.

Table 210: User mapping
SCIM parameter Okta parameter
Id id
UserName login
DisplayName displayName
NickName nickName
Name.GivenName firstName
Name.FamilyName lastName
Name.MiddleName middleName
Name.HonorificPrefix honorificPrefix

Name.HonorificSuffix

honorificSuffix

Addresses.StreetAddress streetAddress
Addresses.Locality city
Addresses.Region state
Addresses.PostalCode zipCode
Addresses.Country countryCode
Emails.value email

Extension.PasswordChanged

passwordChanged

PhoneNumbers.value

primaryPhone

UserType

userType

Title

title

PreferredLanguage

preferredLanguage

Locale

locale

Timezone

timezone

Groups[].value (On Demand)

Id (groupsForUserResponse)

Groups[].display (On Demand)

Profile.name (groupsForUserResponse)

Active

tatus == "ACTIVE"

Extension.EmployeeNumber

employeeNumber

Extension.Division

division

Extension.Department

department

Extension.CostCenter

costCenter

Extension.Organization

organization

Extension.Manager.value

managerId

Extension.Manager.DisplayName

manager

Meta.Created

created

Meta.LastModified

lastUpdated

Groups

Table 211: Group mapping
SCIM parameter Okta parameter
Id id
displayName profile.name
Extension.Description profile.description

Extension.GroupType

type

Members[].value id (GetGroupMembersResponse[])
Members[].display profile.displayName (GetGroupMembersResponse[])
Meta.Created created
Meta.LastModified lastUpdated

Extension.lastLogin

lastLogin

Connector limitations

  • Get Users and Groups by pagination will return resources in multiples of 100. The resource count will be same as the next nearest multiple of 100. For example, if the count is specified as 325, the resource count will be 400.
  • Inactivated User can be still be fetched.
  • Password update is not possible through the connector since it expects old and new passwords as parameter. Old password can never be fetched for any user.

  • UserName should be in the format of email id.

  • The connector deletes a user permanently from the target system irrespective of its status. When you perform a DELETE operation on:
    • a deprovisioned user, the user is deleted permanently.
    • an active user, the user is, first, deprovisioned and then deleted permanently. This process is taken care internally.
  • When you modify the email value, both the username and email values get updated. But when you modify the username alone, only the username gets updated with the username value. user who hav not been deactivated, the user gets deactivated.

  • After activating a user, the active value will still be false until the user verifies or changes their password through the mail sent by Okta while activating the user.

Supervisor configuration parameters

The Okta connector allows you to connect Okta with One Identity Starling Connect enabling you to take advantage of the features and products available in Starling Connect that complement and enhance the services provided by Okta.

Okta provides single sign-on, multi-factor authentication and Platform Services, which is a set of modular components that can be used to address requirements that are specific to an organization.

To configure the connector, following parameters are required:

  • Connector name

  • Token

  • Target URL (Cloud application's instance URL used as targetURI in payload)
  • Instance DateTime Offset (refer Configuring additional datetime offset in connectors for more details) 

  • Request Delay (in ms)

    NOTE: To handle the Okta rate limit issue, the Okta connector has been enabled with user configurable delay in milliseconds so that the each request to the target API would wait for the specific amount of time to help the connector to prevent the throttling of the Okta APIs. The default value for the configuration is 1000 (milliseconds) and OneIdentity recommends to keep the value below 2000 (milliseconds).

Configuring custom attributes for Okta

You can configure custom attributes for the Okta connector in Starling Connect for Users and Groups in the Custom Attributes section in Schema Configuration.

NOTE: For more information about how to configure custom attributes in Okta, see Configuring custom attributes in connectors.

Support for MultiValued Custom attributes

  • In connector schema, only String datatype corresponds to the multivalued custom attribute.

  • Connector output format for multivalued custom attributes will be as shown below:

    • "MultivaluedAttributeName" : "[abcd;; efgh;; xyzw;; uvty]"

  • As per the connector output format, the values will be double semicolon separated(;;) and will be enclosed inside opening and closing square brackets.

  • Opening and closing square brackets help to ensure that the attribute is of multivalued type.

Supported objects and operations

Users

Table 208: Supported operations for Users

Operation

VERB

Create User POST
Update User PUT
Delete User DELETE
Get User GET
Get All Users GET
Get All Users with pagination GET

Groups

Table 209: Supported operations for Groups

Operation

VERB

Create Group POST
Update Group PUT
Delete Group DELETE
Get Group GET
Get All Groups GET
Get All Groups with pagination GET
Create Membership POST

Add Membership

POST

Delete Membership

DELETE

Mandatory fields

Users

  • GivenName

  • FamilyName
  • Username
  • Email
  • Password

Groups

  • DisplayName

User and Group mapping

The user and group mappings are listed in the tables below.

Table 210: User mapping
SCIM parameter Okta parameter
Id id
UserName login
DisplayName displayName
NickName nickName
Name.GivenName firstName
Name.FamilyName lastName
Name.MiddleName middleName
Name.HonorificPrefix honorificPrefix

Name.HonorificSuffix

honorificSuffix

Addresses.StreetAddress streetAddress
Addresses.Locality city
Addresses.Region state
Addresses.PostalCode zipCode
Addresses.Country countryCode
Emails.value email

Extension.PasswordChanged

passwordChanged

PhoneNumbers.value

primaryPhone

UserType

userType

Title

title

PreferredLanguage

preferredLanguage

Locale

locale

Timezone

timezone

Groups[].value (On Demand)

Id (groupsForUserResponse)

Groups[].display (On Demand)

Profile.name (groupsForUserResponse)

Active

tatus == "ACTIVE"

Extension.EmployeeNumber

employeeNumber

Extension.Division

division

Extension.Department

department

Extension.CostCenter

costCenter

Extension.Organization

organization

Extension.Manager.value

managerId

Extension.Manager.DisplayName

manager

Meta.Created

created

Meta.LastModified

lastUpdated

Groups

Table 211: Group mapping
SCIM parameter Okta parameter
Id id
displayName profile.name
Extension.Description profile.description

Extension.GroupType

type

Members[].value id (GetGroupMembersResponse[])
Members[].display profile.displayName (GetGroupMembersResponse[])
Meta.Created created
Meta.LastModified lastUpdated

Extension.lastLogin

lastLogin

Connector limitations

  • Get Users and Groups by pagination will return resources in multiples of 100. The resource count will be same as the next nearest multiple of 100. For example, if the count is specified as 325, the resource count will be 400.
  • Inactivated User can be still be fetched.
  • Password update is not possible through the connector since it expects old and new passwords as parameter. Old password can never be fetched for any user.

  • UserName should be in the format of email id.

  • The connector deletes a user permanently from the target system irrespective of its status. When you perform a DELETE operation on:
    • a deprovisioned user, the user is deleted permanently.
    • an active user, the user is, first, deprovisioned and then deleted permanently. This process is taken care internally.
  • When you modify the email value, both the username and email values get updated. But when you modify the username alone, only the username gets updated with the username value. user who hav not been deactivated, the user gets deactivated.

  • After activating a user, the active value will still be false until the user verifies or changes their password through the mail sent by Okta while activating the user.

Configuring custom attributes for Okta

The Okta connector allows you to connect Okta with One Identity Starling Connect enabling you to take advantage of the features and products available in Starling Connect that complement and enhance the services provided by Okta.

Okta provides single sign-on, multi-factor authentication and Platform Services, which is a set of modular components that can be used to address requirements that are specific to an organization.

Supervisor configuration parameters

To configure the connector, following parameters are required:

  • Connector name

  • Token

  • Target URL (Cloud application's instance URL used as targetURI in payload)
  • Instance DateTime Offset (refer Configuring additional datetime offset in connectors for more details) 

  • Request Delay (in ms)

    NOTE: To handle the Okta rate limit issue, the Okta connector has been enabled with user configurable delay in milliseconds so that the each request to the target API would wait for the specific amount of time to help the connector to prevent the throttling of the Okta APIs. The default value for the configuration is 1000 (milliseconds) and OneIdentity recommends to keep the value below 2000 (milliseconds).

You can configure custom attributes for the Okta connector in Starling Connect for Users and Groups in the Custom Attributes section in Schema Configuration.

NOTE: For more information about how to configure custom attributes in Okta, see Configuring custom attributes in connectors.

Support for MultiValued Custom attributes

  • In connector schema, only String datatype corresponds to the multivalued custom attribute.

  • Connector output format for multivalued custom attributes will be as shown below:

    • "MultivaluedAttributeName" : "[abcd;; efgh;; xyzw;; uvty]"

  • As per the connector output format, the values will be double semicolon separated(;;) and will be enclosed inside opening and closing square brackets.

  • Opening and closing square brackets help to ensure that the attribute is of multivalued type.

Supported objects and operations

Users

Table 208: Supported operations for Users

Operation

VERB

Create User POST
Update User PUT
Delete User DELETE
Get User GET
Get All Users GET
Get All Users with pagination GET

Groups

Table 209: Supported operations for Groups

Operation

VERB

Create Group POST
Update Group PUT
Delete Group DELETE
Get Group GET
Get All Groups GET
Get All Groups with pagination GET
Create Membership POST

Add Membership

POST

Delete Membership

DELETE

Mandatory fields

Users

  • GivenName

  • FamilyName
  • Username
  • Email
  • Password

Groups

  • DisplayName

User and Group mapping

The user and group mappings are listed in the tables below.

Table 210: User mapping
SCIM parameter Okta parameter
Id id
UserName login
DisplayName displayName
NickName nickName
Name.GivenName firstName
Name.FamilyName lastName
Name.MiddleName middleName
Name.HonorificPrefix honorificPrefix

Name.HonorificSuffix

honorificSuffix

Addresses.StreetAddress streetAddress
Addresses.Locality city
Addresses.Region state
Addresses.PostalCode zipCode
Addresses.Country countryCode
Emails.value email

Extension.PasswordChanged

passwordChanged

PhoneNumbers.value

primaryPhone

UserType

userType

Title

title

PreferredLanguage

preferredLanguage

Locale

locale

Timezone

timezone

Groups[].value (On Demand)

Id (groupsForUserResponse)

Groups[].display (On Demand)

Profile.name (groupsForUserResponse)

Active

tatus == "ACTIVE"

Extension.EmployeeNumber

employeeNumber

Extension.Division

division

Extension.Department

department

Extension.CostCenter

costCenter

Extension.Organization

organization

Extension.Manager.value

managerId

Extension.Manager.DisplayName

manager

Meta.Created

created

Meta.LastModified

lastUpdated

Groups

Table 211: Group mapping
SCIM parameter Okta parameter
Id id
displayName profile.name
Extension.Description profile.description

Extension.GroupType

type

Members[].value id (GetGroupMembersResponse[])
Members[].display profile.displayName (GetGroupMembersResponse[])
Meta.Created created
Meta.LastModified lastUpdated

Extension.lastLogin

lastLogin

Connector limitations

  • Get Users and Groups by pagination will return resources in multiples of 100. The resource count will be same as the next nearest multiple of 100. For example, if the count is specified as 325, the resource count will be 400.
  • Inactivated User can be still be fetched.
  • Password update is not possible through the connector since it expects old and new passwords as parameter. Old password can never be fetched for any user.

  • UserName should be in the format of email id.

  • The connector deletes a user permanently from the target system irrespective of its status. When you perform a DELETE operation on:
    • a deprovisioned user, the user is deleted permanently.
    • an active user, the user is, first, deprovisioned and then deleted permanently. This process is taken care internally.
  • When you modify the email value, both the username and email values get updated. But when you modify the username alone, only the username gets updated with the username value. user who hav not been deactivated, the user gets deactivated.

  • After activating a user, the active value will still be false until the user verifies or changes their password through the mail sent by Okta while activating the user.

Supported objects and operations

The Okta connector allows you to connect Okta with One Identity Starling Connect enabling you to take advantage of the features and products available in Starling Connect that complement and enhance the services provided by Okta.

Okta provides single sign-on, multi-factor authentication and Platform Services, which is a set of modular components that can be used to address requirements that are specific to an organization.

Supervisor configuration parameters

To configure the connector, following parameters are required:

  • Connector name

  • Token

  • Target URL (Cloud application's instance URL used as targetURI in payload)
  • Instance DateTime Offset (refer Configuring additional datetime offset in connectors for more details) 

  • Request Delay (in ms)

    NOTE: To handle the Okta rate limit issue, the Okta connector has been enabled with user configurable delay in milliseconds so that the each request to the target API would wait for the specific amount of time to help the connector to prevent the throttling of the Okta APIs. The default value for the configuration is 1000 (milliseconds) and OneIdentity recommends to keep the value below 2000 (milliseconds).

Configuring custom attributes for Okta

You can configure custom attributes for the Okta connector in Starling Connect for Users and Groups in the Custom Attributes section in Schema Configuration.

NOTE: For more information about how to configure custom attributes in Okta, see Configuring custom attributes in connectors.

Support for MultiValued Custom attributes

  • In connector schema, only String datatype corresponds to the multivalued custom attribute.

  • Connector output format for multivalued custom attributes will be as shown below:

    • "MultivaluedAttributeName" : "[abcd;; efgh;; xyzw;; uvty]"

  • As per the connector output format, the values will be double semicolon separated(;;) and will be enclosed inside opening and closing square brackets.

  • Opening and closing square brackets help to ensure that the attribute is of multivalued type.

Users

Table 208: Supported operations for Users

Operation

VERB

Create User POST
Update User PUT
Delete User DELETE
Get User GET
Get All Users GET
Get All Users with pagination GET

Groups

Table 209: Supported operations for Groups

Operation

VERB

Create Group POST
Update Group PUT
Delete Group DELETE
Get Group GET
Get All Groups GET
Get All Groups with pagination GET
Create Membership POST

Add Membership

POST

Delete Membership

DELETE

Mandatory fields

Users

  • GivenName

  • FamilyName
  • Username
  • Email
  • Password

Groups

  • DisplayName

User and Group mapping

The user and group mappings are listed in the tables below.

Table 210: User mapping
SCIM parameter Okta parameter
Id id
UserName login
DisplayName displayName
NickName nickName
Name.GivenName firstName
Name.FamilyName lastName
Name.MiddleName middleName
Name.HonorificPrefix honorificPrefix

Name.HonorificSuffix

honorificSuffix

Addresses.StreetAddress streetAddress
Addresses.Locality city
Addresses.Region state
Addresses.PostalCode zipCode
Addresses.Country countryCode
Emails.value email

Extension.PasswordChanged

passwordChanged

PhoneNumbers.value

primaryPhone

UserType

userType

Title

title

PreferredLanguage

preferredLanguage

Locale

locale

Timezone

timezone

Groups[].value (On Demand)

Id (groupsForUserResponse)

Groups[].display (On Demand)

Profile.name (groupsForUserResponse)

Active

tatus == "ACTIVE"

Extension.EmployeeNumber

employeeNumber

Extension.Division

division

Extension.Department

department

Extension.CostCenter

costCenter

Extension.Organization

organization

Extension.Manager.value

managerId

Extension.Manager.DisplayName

manager

Meta.Created

created

Meta.LastModified

lastUpdated

Groups

Table 211: Group mapping
SCIM parameter Okta parameter
Id id
displayName profile.name
Extension.Description profile.description

Extension.GroupType

type

Members[].value id (GetGroupMembersResponse[])
Members[].display profile.displayName (GetGroupMembersResponse[])
Meta.Created created
Meta.LastModified lastUpdated

Extension.lastLogin

lastLogin

Connector limitations

  • Get Users and Groups by pagination will return resources in multiples of 100. The resource count will be same as the next nearest multiple of 100. For example, if the count is specified as 325, the resource count will be 400.
  • Inactivated User can be still be fetched.
  • Password update is not possible through the connector since it expects old and new passwords as parameter. Old password can never be fetched for any user.

  • UserName should be in the format of email id.

  • The connector deletes a user permanently from the target system irrespective of its status. When you perform a DELETE operation on:
    • a deprovisioned user, the user is deleted permanently.
    • an active user, the user is, first, deprovisioned and then deleted permanently. This process is taken care internally.
  • When you modify the email value, both the username and email values get updated. But when you modify the username alone, only the username gets updated with the username value. user who hav not been deactivated, the user gets deactivated.

  • After activating a user, the active value will still be false until the user verifies or changes their password through the mail sent by Okta while activating the user.
Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação