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.

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 210: 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 211: 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 212: 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 213: 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.