Connector limitations
Informatica Cloud Services
The Informatica Cloud Services connector allows you to connect Informatica Cloud Services with One Identity Starling enabling you to take advantage of the features and products available with Starling Connect that complement and enhance the services provided by Informatica Cloud Services.
Informatica Cloud Services is an Integration Platform as a Service (iPaaS) that allows you to integrate and synchronize data and applications in a hybrid environments.
Supervisor configuration parameters
To configure the connector, following parameters are required:
Supported objects and operations
Users
Table 234: Supported operations for Users
Create User |
POST |
Get User |
GET |
Get all Users |
GET |
Delete User |
DELETE |
Groups
Table 235: Supported operations for Groups
Create Group |
POST |
Get Group |
GET |
Get all Groups |
GET |
Delete Group |
DELETE |
Roles
Table 236: Supported operations for Roles
Get all roles |
GET |
Get role |
GET |
Mandatory fields
This section lists the mandatory fields required to create a User or Group:
Users
-
userName
-
name.givenName
-
name.familyName
-
emails[].value
-
entitlements[].value
NOTE: The first available entitlement from the target system would be assigned to entitlements[].value if the property is not provided in the SCIM request. The entitlement property is Roles from the target system.
Groups
- displayName
- entitlements[].value
NOTE: The first available entitlement from the target system would be assigned to entitlements[].value if the property is not provided in the SCIM request. The entitlement property is Roles from the target system.
Mappings
The user and group mappings are listed in the tables below.
Table 237: User mapping
id |
id |
userName |
userName |
lastName |
name.familyName |
firstName lastName |
name.formatted |
firstName lastName |
displayName |
email |
emails[0].value |
title |
title |
state |
active |
locale |
locale |
timeZoneId |
timezone |
roles[].id |
roles[].value |
roles[].roleName |
roles[].display |
groups[].id |
groups[].value |
groups[].userGroupName |
groups[].display |
orgId |
userExtension.orgId |
description |
userExtension.description |
authentication |
userExtension.authentication |
forcePasswordChange |
userExtension.forcePasswordChange |
maxLoginAttempts |
userExtension.maxLoginAttempts |
createTime |
meta.created |
updateTime |
meta.lastModified |
Groups
Table 238: Group mapping
id |
id |
userGroupName |
displayName |
users[].id |
members[].value |
users[].userName |
members[].display |
roles[].id |
roles[].value |
roles[].roleName |
roles[].display |
orgId |
userExtension.orgId |
description |
extension.description |
createTime |
meta.created |
updateTime |
meta.lastModified |
Roles
Table 239: Roles mapping
id |
id |
name |
roleName |
-
The connector does not support update operation for users and groups as the target cloud system does not support update operation for users and groups.
- Target system roles are mapped against the entitlements in SCIM connector.
-
While creating a user or a group, role ids (entitlements) are required. It is not possible to assign entitlements from One Identity Manager client during the creation of users or groups. Hence, a logic has been added in the Starling Connect to retrieve all the roles from the target system and assign the first role (except for those which contain admin in role name) to the create resource request.
AppDynamics
The AppDynamics connector allows you to connect AppDynamics with One Identity Starling enabling you to take advantage of the features and products available with Starling Connect that complement and enhance the services provided by AppDynamics.
AppDynamics is a real-time business and application performance management and monitoring platform that provides a complete view of the application environment, allowing you to monitor and fix issues quickly.
Supervisor configuration parameters
To configure the connector, following parameters are required:
-
Connector name
-
Client Secret
-
API Client Name
-
Account Name
Supported objects and operations
Users
Table 240: Supported operations for Users
Create User |
POST |
Update User |
PUT |
Delete User |
DELETE |
Get User |
GET |
Get All Users |
GET |
Groups
Table 241: Supported operations for Groups
Create Group |
POST |
Update Group |
PUT |
Delete Group |
DELETE |
Get Group |
GET |
Get All Groups |
GET |
Roles
Table 242: Supported operations for Roles
Get Role |
GET |
Get All Roles |
GET |
Mandatory fields
This section lists the mandatory fields required to create a User or Group:
Users
-
UserName
-
DisplayName
-
Security_provider_type
- Password
Groups
- DisplayName
-
Security_provider_type
Mappings
The user, group, and roles mappings are listed in the tables below.
Table 243: User mapping
Id |
id |
UserName |
name |
DisplayName |
displayName |
password |
password |
Groups[].value |
groups[].id |
Groups[].display |
groups[].name |
Roles[].value |
roles[].id |
Roles[].display |
roles[].name |
Extension.security_provider_type |
security_provider_type |
Groups
Table 244: Group mapping
Id |
id |
displayName |
name |
Extension.Description |
description |
Extension.security_provider_type |
security_provider_type |
Extension.Roles[].value |
roles[].id |
Extension.Roles[].display |
roles[].name |
Roles
Table 245: Roles mapping
Id |
id |
displayName |
name |
description |
description |
Connector limitations
- Groups members information will not be retrieved in response to GET specific Group. The reason for this is the Groups API of the target system does not support it. However, the same is done at Users API. To overcome this deviation from standard behavior (rfc: https://tools.ietf.org/html/rfc7643#section-4.2), the connector is designed in such a way that all membership operations are done at Users endpoint. Hence, GET specific User response will retrieve the membership associations of respective User.
-
-
A performance impact is expected in the assignment operation of Roles and Group memberships when the User belongs to multiple Roles and Groups. The reason for this is that separate API calls are made for each and every Roles or Group membership association.
- AppDynamics target system returns the error code 500 for most of the error scenarios except for very specific errors such as 401 Unauthorized. However, the connector handles few of those generic errors and responds appropriately.
-
Most error messages returned by the target system are neither sufficiently informative nor available. The connector follows the same behavior, wherever custom error messages are not possible.
-
Due to target system limitations, password update of User is not supported by the connector. However, the password can be set at the time of creation.
Synchronization and integration of Roles object type with One Identity Manager
For more information, see Synchronization and integration of Roles object type with One Identity Manager
User centric membership configuration for AppDynamics
For more information, see only the following sections in User centric membership:
Supervisor configuration parameters
The AppDynamics connector allows you to connect AppDynamics with One Identity Starling enabling you to take advantage of the features and products available with Starling Connect that complement and enhance the services provided by AppDynamics.
AppDynamics is a real-time business and application performance management and monitoring platform that provides a complete view of the application environment, allowing you to monitor and fix issues quickly.
To configure the connector, following parameters are required:
-
Connector name
-
Client Secret
-
API Client Name
-
Account Name
Supported objects and operations
Users
Table 240: Supported operations for Users
Create User |
POST |
Update User |
PUT |
Delete User |
DELETE |
Get User |
GET |
Get All Users |
GET |
Groups
Table 241: Supported operations for Groups
Create Group |
POST |
Update Group |
PUT |
Delete Group |
DELETE |
Get Group |
GET |
Get All Groups |
GET |
Roles
Table 242: Supported operations for Roles
Get Role |
GET |
Get All Roles |
GET |
Mandatory fields
This section lists the mandatory fields required to create a User or Group:
Users
-
UserName
-
DisplayName
-
Security_provider_type
- Password
Groups
- DisplayName
-
Security_provider_type
Mappings
The user, group, and roles mappings are listed in the tables below.
Table 243: User mapping
Id |
id |
UserName |
name |
DisplayName |
displayName |
password |
password |
Groups[].value |
groups[].id |
Groups[].display |
groups[].name |
Roles[].value |
roles[].id |
Roles[].display |
roles[].name |
Extension.security_provider_type |
security_provider_type |
Groups
Table 244: Group mapping
Id |
id |
displayName |
name |
Extension.Description |
description |
Extension.security_provider_type |
security_provider_type |
Extension.Roles[].value |
roles[].id |
Extension.Roles[].display |
roles[].name |
Roles
Table 245: Roles mapping
Id |
id |
displayName |
name |
description |
description |
Connector limitations
- Groups members information will not be retrieved in response to GET specific Group. The reason for this is the Groups API of the target system does not support it. However, the same is done at Users API. To overcome this deviation from standard behavior (rfc: https://tools.ietf.org/html/rfc7643#section-4.2), the connector is designed in such a way that all membership operations are done at Users endpoint. Hence, GET specific User response will retrieve the membership associations of respective User.
-
-
A performance impact is expected in the assignment operation of Roles and Group memberships when the User belongs to multiple Roles and Groups. The reason for this is that separate API calls are made for each and every Roles or Group membership association.
- AppDynamics target system returns the error code 500 for most of the error scenarios except for very specific errors such as 401 Unauthorized. However, the connector handles few of those generic errors and responds appropriately.
-
Most error messages returned by the target system are neither sufficiently informative nor available. The connector follows the same behavior, wherever custom error messages are not possible.
-
Due to target system limitations, password update of User is not supported by the connector. However, the password can be set at the time of creation.
Synchronization and integration of Roles object type with One Identity Manager
For more information, see Synchronization and integration of Roles object type with One Identity Manager
User centric membership configuration for AppDynamics
For more information, see only the following sections in User centric membership:
Supported objects and operations
The AppDynamics connector allows you to connect AppDynamics with One Identity Starling enabling you to take advantage of the features and products available with Starling Connect that complement and enhance the services provided by AppDynamics.
AppDynamics is a real-time business and application performance management and monitoring platform that provides a complete view of the application environment, allowing you to monitor and fix issues quickly.
Supervisor configuration parameters
To configure the connector, following parameters are required:
-
Connector name
-
Client Secret
-
API Client Name
-
Account Name
Users
Table 240: Supported operations for Users
Create User |
POST |
Update User |
PUT |
Delete User |
DELETE |
Get User |
GET |
Get All Users |
GET |
Groups
Table 241: Supported operations for Groups
Create Group |
POST |
Update Group |
PUT |
Delete Group |
DELETE |
Get Group |
GET |
Get All Groups |
GET |
Roles
Table 242: Supported operations for Roles
Get Role |
GET |
Get All Roles |
GET |
Mandatory fields
This section lists the mandatory fields required to create a User or Group:
Users
-
UserName
-
DisplayName
-
Security_provider_type
- Password
Groups
- DisplayName
-
Security_provider_type
Mappings
The user, group, and roles mappings are listed in the tables below.
Table 243: User mapping
Id |
id |
UserName |
name |
DisplayName |
displayName |
password |
password |
Groups[].value |
groups[].id |
Groups[].display |
groups[].name |
Roles[].value |
roles[].id |
Roles[].display |
roles[].name |
Extension.security_provider_type |
security_provider_type |
Groups
Table 244: Group mapping
Id |
id |
displayName |
name |
Extension.Description |
description |
Extension.security_provider_type |
security_provider_type |
Extension.Roles[].value |
roles[].id |
Extension.Roles[].display |
roles[].name |
Roles
Table 245: Roles mapping
Id |
id |
displayName |
name |
description |
description |
Connector limitations
- Groups members information will not be retrieved in response to GET specific Group. The reason for this is the Groups API of the target system does not support it. However, the same is done at Users API. To overcome this deviation from standard behavior (rfc: https://tools.ietf.org/html/rfc7643#section-4.2), the connector is designed in such a way that all membership operations are done at Users endpoint. Hence, GET specific User response will retrieve the membership associations of respective User.
-
-
A performance impact is expected in the assignment operation of Roles and Group memberships when the User belongs to multiple Roles and Groups. The reason for this is that separate API calls are made for each and every Roles or Group membership association.
- AppDynamics target system returns the error code 500 for most of the error scenarios except for very specific errors such as 401 Unauthorized. However, the connector handles few of those generic errors and responds appropriately.
-
Most error messages returned by the target system are neither sufficiently informative nor available. The connector follows the same behavior, wherever custom error messages are not possible.
-
Due to target system limitations, password update of User is not supported by the connector. However, the password can be set at the time of creation.
Synchronization and integration of Roles object type with One Identity Manager
For more information, see Synchronization and integration of Roles object type with One Identity Manager
User centric membership configuration for AppDynamics
For more information, see only the following sections in User centric membership: