Let's know more about SAP Identity Provisioning Service (IPS) - Properties..
Properties can help you filter which entities and entity attributes are read from the source system or written to the target system. for example - Azure Active Directory or Azure Directory will be source system where all of your Users and groups are stored and SAP Identity Authentication Services (IAS) will be Target System for maintiaing the users and groups to access different SAP Applications.
You need to set mandatory properties to configure the connection between your source and target systems. So in this blog, you will find all the list of properties available
Properties help you to customize the way your identities are read from a source system or provisioned to the target one. They can also filter which entities and attributes to be read or skipped during the provisioning job. According to their usability, properties can be categorized as:
Standard
Credential
Default
Parameterized
Internal
Name | Description | System Type |
a4c.bulk.operations.max.count | If you have enabled the bulk operations, you can use this property to set the number of users to be provisioned per request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, the service will replace it with the default value (20). System Role: Target | SAP BTP ABAP environment |
a4c.roles.filter | Enter OData filtering for reading roles in the SAP BTP ABAP environment system. To learn what criteria you can use, see: OData URI Conventions → 4.5 Filter System Query Option System Role: Source, Proxy | SAP BTP ABAP environment |
a4c.roles.page.size | This property indicates how many business roles (considered as groups) per page to be read from your SAP BTP ABAP environment source system. Possible values: Integer number For example, if you set the property's value = 30, the Identity Provisioning will read 30 roles (groups) at once, then – another 30, and so on. System Role: Source, Proxy | SAP BTP ABAP environment |
a4c.roles.prefix | This property distinguishes SAP BTP ABAP environment roles by specific prefix. It is an optional property which does not appear by default at system creation. Example value: A4C_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the roles that are read from the SAP BTP ABAP environment source system and will be provisioned to the target system with the following name pattern: A4C_<role_name> . This way SAP BTP ABAP environment roles in the target system will be easily distinguished from roles provisioned from other applications. If the property is not set, the SAP BTP ABAP environment roles will be read and provisioned to the target system with their actual role names.When set in the target system, only roles containing the A4C_ prefix in their role name will be provisioned to SAP BTP ABAP environment. Roles without this prefix in their names won't be provisioned. If the property is not set, all roles will be be provisioned to SAP BTP ABAP environment.System Role: Source and Target | SAP BTP ABAP environment |
a4c.skip.read.archived | In the event of archived (disabled) entities in a source SAP BTP ABAP environment system, you can choose whether the provisioning jobs to continue reading such entities or to skip them. In the source and proxy systems, this property is activated by default. If you want to always read disabled entities, set the property to false, or delete it. Possible values:true falseDefault value: trueSystem Role: Source, Target, Proxy | SAP BTP ABAP environment |
a4c.support.bulk.operation | Set this property to true if you want to enable bulk operations for provisioning entities. That means, the Identity Provisioning service can write, update, and delete multiple users or groups in a single request. For more information, see: APIs for Business User Management Possible values:true falseDefault value: false System Role: Target | SAP BTP ABAP environment |
a4c.user.roles.overwrite | This property defines whether the current roles of a user to be preserved or overwritten by the Identity Provisioning service within the SAP BTP ABAP environment target or proxy system. See also: Extended Explanation of the *user.roles.overwrite PropertiesPossible values:true – the current user roles will be deleted in the proxy system, and the user will be updated only with the roles provisioned by the service. false – the current user roles will be preserved, and the new roles (if any) will be added for the relevant user in the proxy system.Default value (if the property is missing during system creation): trueDefault value (if the property appears during system creation): false System Role: Target, Proxy | SAP BTP ABAP environment |
aad.domain.name | Enter one of the verified domain names from the corresponding Azure AD tenant. System Role: Source, Target, Proxy | Microsoft Azure Active Directory |
aad.entities.top | This property defines the number of entities to be read per page. Default value: 100 System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.group.attributes | Defines which group attributes are read from Microsoft Azure AD system. The property is set during system creation with the following default value: id,displayName,mailNickname This means that by default, Identity Provisioning will read from MS Azure AD the group attributes defined in the property value and will also return the members attribute. Those attributes are used in the default read transformation. To check the complete set of group attributes (properties) supported by Microsoft Azure AD, see: Microsoft Graph: Group Properties If you want the Identity Provisioning to read additional group attributes, add them to the default list of attributes separated by comma and adapt the transformations. For example, to read the description of the MS Azure AD groups in addition to the default list of attributes, and provision them to Identity Authentication, proceed as follows:Add the attribute in the property value: id,displayName,mailNickname,descriptionExtend the MS Azure AD read transformation by adding the following mapping for the group resource:Code Syntax { "sourcePath": "$.description", "optional": true, "targetPath": "$.description" },Extend the Identity Authentication write transformation by adding the following mapping for the group resource: Code Syntax { "sourcePath": "$.description", "optional": true, "targetPath": "$['urn:sap:cloud:scim:schemas:extension:custom:2.0:Group']['description']" },In case you remove the default list of attributes from the value of this property and only add the additional attributes, Identity Provisioning will read from MS Azure AD the additional group attributes, the group id, displayName, mailNickname and will also return the members attribute. System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.group.attributes.expand | This property allows you to expand the list of attributes specified in the aad.group.attributes property with additional group attributes. Once you provide the value of the additional attributes in the aad.group.attributes.expand property, you need to extend the read transformation of MS Azure AD with attribute mappings based on the given value. For more information on the attributes (relationships) that support the $expand query parameter, refer to Microsoft Graph REST API v1.0 → Relationships. System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.group.filter | Via this property, you can filter groups by specific criteria, according to the syntax of Microsoft Graph REST API. Possible values: Text/numeric string For example:Value = displayName eq 'Employees 2020'Value = displayName eq 'Service Administrators' and mail eq 'serviceadmins@abcd.onmicrosoft.com'Value = startsWith(displayName, 'ABC_')System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.group.member.attributes | This property defines the attributes of a group member to be read by the Identity Provisioning. By default, it always reads the type and the id of a member. If you prefer the Identity Provisioning to read additional attributes, you can add them as a single or a comma-separated value. For example: ExampleIf you want to read the e-mails too, enter: aad.group.member.attributes=mailThis will read a member's type, ID and e-mail.If you want to read multiple additional attributes, enter: aad.group.member.attributes=mail,mobilePhone,displayName This will read a member's type, ID, e-mail, phone and display name.See: Microsoft Azure Active DirectoryPossible values: type (default) id (default) Any valid Microsoft Azure attribute of a group member A comma-separated list of valid MS Azure attributes of a group member Remember The Identity Provisioning service always retrieves the id and type attributes of a group member, regardless of the additional attributes you specify. System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.user.attributes | Defines which user attributes are read from Microsoft Azure AD system. The property is set during system creation with the following default value: id,mail,userPrincipalName,displayName,mailNickname,givenName,surname,mobilePhone,businessPhones This means that by default, Identity Provisioning will read from MS Azure AD the user attributes defined in the property value. Those attributes are also used in the default read transformation. To check the complete set of user attributes (properties) supported by Microsoft Azure AD, see: Microsoft Graph: User Properties If you want the Identity Provisioning to read additional user attributes, add them to the default list of attributes separated by comma and adapt the transformations. For example, to read the employeeId of the MS Azure AD users in addition to the default list of attributes, and provision them to Identity Authentication, proceed as follows:Add the attribute in the property value: id,mail,userPrincipalName,displayName,mailNickname,givenName,surname,mobilePhone,businessPhones,employeeIdExtend the MS Azure AD read transformation by adding the following mapping for the user resource: Sample Code { "sourcePath": "$.employeeId", "targetPath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['employeeNumber']", "optional": true },Make sure the following mapping is present in the Identity Authentication write transformation: Sample Code { "sourcePath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['employeeNumber']", "targetPath": "$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['employeeNumber']", "optional": true },In case you remove the default list of attributes from the value of this property and only add the additional attributes, Identity Provisioning will return the additional user attributes plus the mandatory ones: id,mail, userPrincipalName. System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.user.attributes.expand | This property allows you to expand the list of attributes specified in the aad.user.attributes property with additional user attributes. Once you provide the value of the additional attributes in the aad.user.attributes.expand property, you need to extend the read transformation of MS Azure AD with attribute mappings based on the given value. Currently, the read transformation of MS Azure AD is extended with the attribute mappings for manager id and displayName as follows:Code Syntax { "sourcePath":"$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['manager']['value']", "optional":true, "targetPath":"$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['manager']['value']" }, { "sourcePath":"$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['manager']['displayName']", "optional":true, "targetPath":"$['urn:ietf:params:scim:schemas:extension:enterprise:2.0:User']['manager']['displayName']" } To read the manager of the user, you need to provide the manager as a value of the aad.user.attributes.expand property in the following format: manager($select=id,displayName) For more information on the attributes (relationships) that support the $expand query parameter, refer to Microsoft Graph REST API v1.0 → Relationships. System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.user.attributes.membership.active | Use this property if you want to get information about all the groups to which the users are assigned (if any).If the property is missing, or is set to false – group membership details for the users will not be extracted. If the property is set to true – group membership details for the users will be extracted.If you set the property to true, you will get information about the group ID and its entity type (group) – default result. However, if you also set a value for property aad.group.attributes, you will get additional information relevant to this value. For example: If you set aad.user.attributes.membership.active = true and aad.group.attributes = displayName, you will receive the following exemplary data for a group as part of the user object: "groups": [ { "displayName": "Azure AD Group 1", "id": "aaa111999-0000-444-123-777fff000", "type": "group" } ]Possible values: true false (default) System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.user.filter | Via this property, you can filter users by specific criteria, according to the syntax of Microsoft Graph REST API. Note This property replaces the deprecated msgraph-filter property. Possible values: Text/numeric string For example:Value = Department eq 'Finance' Value = displayName eq 'John Smith' and city eq 'Sofia'System Role: Source, Proxy | Microsoft Azure Active Directory |
aad.user.filter.group.filter.combine | Filters Microsoft Azure AD users based on their group assignments. When set to true, this property combines user and group filters defined on the aad.user.filter and aad.group.filter properties to further narrow the search results. This way, only users that meet the following filtering criteria are returned:Users that match the user filter and at the same time are members of groups that match the group filter.Members of the filtered groups that match the user filter.Note To make the aad.user.filter.group.filter.combine property work, ensure that both user and group entities are read, that is, neither of them is ignored in the transformation code. ExampleYou have the following users, located in two cities with one or more assigned groups: User: David Thompson from London with assigned Groups: Marketing and Sales User: Julie Armstrong from New York with assigned Groups: Employee User: John Smith from New York with assigned Groups: Marketing and Sales You have defined the following filtering criteria: aad.user.filter = city eq "New York" aad.group.filter = displayName eq “Marketing” aad.user.filter.group.filter.combine = true You get the following result: Only user John Smith is returned as it matches the user filter and at the same time is a member of the group that matches the group filter. Although David Thompson matches the group filter, he doesn’t match the user filter. Although Julie Armstrong matches the user filter, shed doesn’t match the group filter. When set to false, user and group filters are not combined. For more information, see: Identity Provisioning: How to Get Users Based on Group Assignments from MS Azure AD Possible values: true When this property is set to true, it is expected that filtering criteria are defined for aad.user.filter and aad.group.filter properties. If one or both have empty values, be aware of the following behavior: Only aad.user.filter is defined: Users that match the user filter and are members of any group will be returned. If a user matches the user filter but is not a member of any group, this user will not be returned. Only aad.group.filter is defined: Users that are members of the groups matching the group filter will be returned. None of the properties are defined: Users that are members of any group will be returned. When this property is set to true and filtering criteria are defined for aad.user.filter and aad.group.filter properties, if you are searching for a specific user or group using Identity Provisioning service API, be aware of the following behavior: When searching for specific user with GET .../Users/UserId request, filtering criteria defined on both properties are not considered. The user is returned with all the groups he or she is a member of. When searching for specific group with GET ...Groups/GroupId request, filtering criteria defined on both properties are not considered. The group is returned with all its group members. false - default value System Role: Source, Proxy | Microsoft Azure Active Directory |
abap.host.timezone | Specifies the time zone of SAP Application Server ABAP on-premise systems. The value is used for calculating the correct assignments validity in case your SAP AS ABAP and Identity Provisioning tenant are running in different time zones. Possible values: The value should be provided in the following format: UTC+/- offset. For example: UTC+02:00, UTC-04:00, UTC+03:30. Internet Assigned Numbers Authority (IANA) Time Zone database format is also supported. For more information, see RFC 6557: Procedures for Maintaining the Time Zone Database. System Role: Source | SAP Application Server ABAP |
abap.role.filter | Filters user roles by a regular expression. The regex can define any kind of search pattern. Caution This property is rather obsolete. For newly created systems, please use abap.role.name.filter. Possible values: For example: abap.role.filter = ^order.* This filter provisions all roles that start with order. System Role: Source, Proxy | SAP Application Server ABAP |
abap.role.name.filter | Filters roles by a regular expression. The regex can define any kind of search pattern. This property has a higher priority over abap.role.filter. That means, if you set both properties in a system, the value of abap.role.name.filter will be used. However, if the value of abap.role.name.filter is empty, then abap.role.filter’s value will be used instead. Note As abap.role.filter is obsolete, we recommend that you use abap.role.name.filter. Possible values: For example: abap.role.name.filter = ^inter.* This regex reads all roles that start with inter, such as internal, internship, and so on. System Role: Source, Proxy | SAP Application Server ABAP |
abap.role.prefix | This property distinguishes SAP Application Server ABAP (AS ABAP) roles by specific prefix. It is an optional property which does not appear by default at system creation. Example value: ABAP_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the roles that are read from the AS ABAP source system and will be provisioned to the target system with the following name pattern: ABAP_<role_name> . This way AS ABAP roles in the target system will be easily distinguished from roles provisioned from other applications. If the property is not set, the AS ABAP roles will be read and provisioned to the target system with their actual role names.When set in the target system, only roles containing the ABAP_ prefix in their role name will be provisioned to AS ABAP. Roles without this prefix in their names won't be provisioned. If the property is not set, all roles will be be provisioned to AS ABAP.System Role: Source and Target | SAP Application Server ABAP |
abap.user.filter | Filters users by a regular expression on their username. The regex can define any kind of search pattern. Caution This property is rather obsolete. For newly created systems, please use abap.user.name.filter. Possible values: For example: abap.user.filter = ^A.* This filter returns all user names that start with capital A. System Role: Source, Proxy | SAP Application Server ABAP |
abap.user.membership.filter | Filters users by a regular expression, based on their Role memberships in AS ABAP. The regex can define any kind of search pattern. Possible values: For example: abap.user.membership.filter = (?i)^new.* This reads all users who have an assigned role which starts with new. This regex is case insensitive, which means the result can be roles starting with new, or New, or NEW, and so on. System Role: Source, Proxy | SAP Application Server ABAP |
abap.user.name.filter | Filters users by a regular expression on their username. The regex can define any kind of search pattern. This property has a higher priority over abap.user.filter. That means, if you set both properties in a system, the value of abap.user.name.filter will be used. However, if the value of abap.user.name.filter is empty, then abap.user.filter’s value will be used instead. Note As abap.user.filter is obsolete, we recommend that you use abap.user.name.filter. Possible values: For example: abap.user.name.filter = ^MAR.*This regex reads all user names that start with MAR, such as MARK, MARTINA, and so on. System Role: Source, Proxy | SAP Application Server ABAP |
ad.group.flatten | There are target systems that do not support nested groups (group structures). Therefore, if your Microsoft AD system contains such groups, they will not be resolved properly during the provisioning job. Such target systems are:SAP Jam Collaboration Identity AuthenticationTo enable reading of group structures, you can use the ad.group.flatten property and set it to true. It will read the group structure recursively and will "flatten" it so that all users from all groups and subgroups will be resolved and written in the target system as members of the main parent group. For best results, we recommend you also set the system property ldap.group.filter whose value is one or multiple Microsoft AD parent groups.Possible values:true false Default value: false Examples for filtering: If your Microsoft AD system contains a parent group "Canteen", which contains nested subgroups, you have to set the filter like this: ldap.group.filter = (cn=Canteen) The Identity Provisioning will resolve all the direct users and groups of "Canteen", along with all the users of its subgroups (and their subgroups). In the target system, all users will be written in one parent group named also "Canteen". If you have multiple parent groups (for example, Canteen, Finances, and Support_Team) that contain nested subgroups, you have to set the filter like this:ldap.group.filter = (|(cn=Canteen)(cn=Finance)(cn=Support_Team)) System Role: Source | Microsoft Active Directory |
ariba.applications.api.key | This property corresponds to the Application key for your SAP Ariba application. You obtain it during the creation of your application in the SAP Ariba developer portal. See: How to find your application's application key and OAuth client ID Possible values: Text/numeric string For example: 123abc123XYZ000abc123ABC012345 System Role: Source, Target, Proxy | SAP Ariba Applications |
ariba.applications.content.type | This property makes a SAP Ariba Applications connector to send a specified value for the Content-Type HTTP header. This is needed because SAP Ariba Applications could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json Default value: application/scim+json System Role: Target, Proxy | SAP Ariba Applications |
ariba.applications.group.filter | When specified, only those SAP Ariba Applications groups matching the filter expression will be read. Possible values: For example: displayName eq "ProjectTeam1" System Role: Source | SAP Ariba Applications |
ariba.applications.group.flatten | This property allows or forbids reading "nested groups" (group structures) from SAP Ariba Applications. If enabled (true), group members of type group will be ignored during read in order not to be provisioned to target systems that do not support nested groups. Possible values: Default value: false Predefined value (during system creation):Source systems: trueSet it to This property distinguishes SAP Ariba Applications groups by specific prefix. It is an optional property which does not appear by default at system creation.false only if you are sure that the target system supports nested groups. Proxy systems: falseLeave the default/predefinedThis property distinguishes SAP Ariba Applications groups by falseLeave the default/predefined value only if you are sure that the consuming external application (identity management system) supports nested groups.System Role: Source, Proxy | SAP Ariba Applications |
ariba.applications.group.prefix | This property distinguishes SAP Ariba Applications groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: ARIBA_APPLICATIONS_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP Ariba Applications source system and will be provisioned to the target system with the following name pattern: ARIBA_APPLICATIONS_<GroupDisplayName>. This way SAP Ariba Applications groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP Ariba Applications groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the ARIBA_APPLICATIONS_ prefix in their display name will be provisioned to SAP Ariba Applications. Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be be provisioned to SAP Ariba Applications.System Role: Source and Target | SAP Ariba Applications |
ariba.applications.group.unique.attribute | If the Identity Provisioning tries to create a group that already exists on the SAP Ariba Applications target system, the creation will fail. In this case, the existing group only needs to be updated. This group can be found via search, based on an attribute (default or specific). To make the search filter by a specific attribute, specify this attribute as a value for this property. Possible values: Default value (when not specified): displayName If the property is not specified, the search is done by the default attribute: displayName System Role: Target, Proxy | SAP Ariba Applications |
ariba.applications.include.if.match.wildcard.header | Makes the SAP Ariba Applications connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by an SAP Ariba Applications system for entity versioning. Possible values:true falseDefault value: falseSystem Role: Target, Proxy | SAP Ariba Applications |
ariba.applications.patch.group.members.above.threshold | This property is relevant only when ariba.applications.patch.group.members.of.nested.groups is set to true. It defines the maximum number of user members of a group that are included in one PATCH request. If the maximum value of 200 000 is exceeded, the system sets automatically the default value. Possible values: integer Default value: 20 000 Maximum value: 200 000 System Role: Target | SAP Ariba Applications |
ariba.applications.patch.group.members.of.nested.groups | If you set this property to true, Identity Provisioning will update only user members of a group in SAP Ariba Applications target system. The update will be executed on batches via PATCH requests. This will preserve the group hierarchy with nested groups in the SAP Ariba Applications backend. Possible values: true falseDefault value: falseSystem Role: Target | SAP Ariba Applications |
ariba.applications.realm.id | This property corresponds to the SAP Ariba realm that your application has access to. To learn how to get it, see: How to find your SAP Ariba realm name? Possible values: Text/numeric string For example: 123abc123XYZ000abc123ABC012345 System Role: Source, Target, Proxy | SAP Ariba Applications |
ariba.applications.support.patch.operation | The default value of this property is false. But for SAP Ariba Applications proxy systems, this property appears during creation and its predefined value is true. That means, when the Identity Provisioning identifies a changed entity in the back-end system, it will execute the updates as PATCH requests instead of PUT. That is, only changes will be written in SAP Ariba Applications, instead of provisioning the whole entity data. Note that only attributes without "scope": "createEntity" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with explicitly set "scope": "createEntity". Possible values: Default value: false Predefined value (during system creation): true System Role: Target, Proxy | SAP Ariba Applications |
ariba.applications.user.filter | When specified, only those SAP Ariba Applications users matching the filter expression will be read. Possible values: For example: userName eq "SmithJ"System Role: Source | SAP Ariba Applications |
ariba.applications.user.unique.attribute | When the Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists in SAP Ariba Applications. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). According to your use case, choose how to set up this property:Default behavior: This property is missing during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such а userName is not found, the creation of the conflicting user fails. Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = userName,emails[0].value. If the service finds an existing user with both these userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Possible values:userName emails[0].value userName,emails[0].valueDefault value: userName System Role: Target, Proxy | SAP Ariba Applications |
Authentication | Authentication type required for HTTP connection Possible values:NoAuthenticationBasicAuthenticationClientCertificateAuthenticationSystem Role: Source, Target, Proxy | All HTTP systems Note Identity Provisioning supports certificate-based authentication for secure communication with the provisioning systems (connectors) provided by the service. Refer to the documentation of the respective systems to find out how to upload Identity Provisioning certificates on their end. For example, see How to Create Communication Users in SAP BTP ABAP Environment. |
AuthType | Enter the type of authentication used for access token retrieval for OAuth HTTP destinations. Possible values:Basic FormDefault value: Basic System Role: Source, Target, Proxy | SCIM System SAP Analytics Cloud SAP Commissions SAP Jam Collaboration Identity Authentication Local Identity Directory Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) Sales Cloud – Analytics & AI SAP BTP Account Members (Neo) SAP Fieldglass |
bn.api.key | An API Key represents the unique key that identifies a particular application as a legitimate consumer of an API. System Role:Source, Target, Proxy | SAP Business Network |
bn.content.type | This property makes SAP Business Network connector to send a specified value for the Content-Type HTTP header. This is needed because SAP Business Network could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json Default value: application/scim+json System Role: Target, Proxy | SAP Business Network |
bn.group.filter | When specified, only those SAP Business Network groups matching the filter expression will be read. Possible values: displayName eq "Employees" System Role: Source | SAP Business Network |
bn.include.if.match.wildcard.header | Makes the connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by a SCIM system for entity versioning. Possible values:true falseDefault value: false System Role: Target, Proxy | SAP Business Network |
bn.realm.id | The realm name is part of the URL you use to access SAP Business Network. System Role:Source, Target, Proxy | SAP Business Network |
bn.support.patch.operation | This property controls how modified entities (users and groups) in the source system are updated in the target system.If set to true, Identity Provisioning sends a PATCH request to the user or group resource in the target system. Only attributes without "scope": "createEntity" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with explicitly set "scope": "createEntity".If set to false, PUT operations are used to update users and groups in the target system. This means, for example, that if a user attribute is modified or a group member is removed from a group, all user attributes and all group attributes are replaced in the target system, instead of updating only the modified ones.Users and groups can be updated in the target system in various cases, such as:In the source system, some user or group attributes are modified, or new attributes are added. In the source system, a condition or a filter is set for users or groups not to be read anymore. A user or a group is deleted from the source system. In the last two cases, it's possible to keep the entity in the target system – it will not be deleted but only disabled. To do this, use the deleteEntity scope in the transformation of your target or proxy system. See:Transformation Expressions → deleteEntity. Possible values: true false Default value for proxy systems: true Default value for target systems: false System Role: Target, Proxy | SAP Business Network |
bn.user.filter | When specified, only those SAP Business Network users matching the filter expression will be read. Possible values:userName eq "Julie Armstrong"userName sw "J"name.familyName eq "Armstrong"emails eq "julie.armstrong@example.com" System Role: Source | SAP Business Network |
bn.user.unique.attribute | If Identity Provisioning tries to provision a user that already exists in the target system (a conflicting user), this property defines the unique attributes by which the existing user will be searched and resolved. The property is not added automatically at system creation. Default value: userName If the service finds an existing user by userName, it updates this user with the data of the conflicting one. If the service does not find an existing user by userName, the creation of the conflicting user fails. System Role: Target, Proxy | SAP Business Network |
c4c.api.version | This property defines the API version that the API of your SAP Sales Cloud and SAP Service Cloud system uses. Possible values:1 2 3By default, Identity Provisioning uses version 3, which means - SCIM 2.0 based API. System Role: Source, Target, Proxy | SAP Sales Cloud and SAP Service Cloud |
c4c.custom.namespace.<prefix> | Note Only relevant to API v.2. The Identity Provisioning service uses a single predefined namespace for all attributes. However, you can provision entities by defining your own (custom) namespaces for some attributes. For this purpose, you have to:Specify a namespace using this property. Set the custom namespace in the JSON transformation.For more information, see: SAP Sales Cloud and SAP Service CloudPossible values: The value of this property is the namespace URI. For <prefix>, enter the prefix of the custom XML namespace (for example, a123). Example for setting up the whole property: c4c.custom.namespace.a123=http://sap.com/xi/AP/CustomerExtension/ABC/A123XXSystem Role: Target | SAP Sales Cloud and SAP Service Cloud |
c4c.group.filter | When specified, only those SAP Sales Cloud and SAP Service Cloud groups matching the filter expression will be read. SAP Sales Cloud and SAP Service Cloud is formerly known as SAP Cloud for Customer (in short, C4C). Example: displayName eq "ProjectTeam1" and "Employees2020" | SAP Sales Cloud and SAP Service Cloud |
c4c.user.filter | When specified, only those SAP Sales Cloud and SAP Service Cloud users matching the filter expression will be read. SAP Sales Cloud and SAP Service Cloud is formerly known as SAP Cloud for Customer (in short, C4C). Example: name.familyName eq "Smith" and addresses.country eq "US" | SAP Sales Cloud and SAP Service Cloud |
cbc.group.filter | When specified, only those SAP Central Business Configuration groups matching the filter expression will be read. Possible values: For example: displayName eq "ProjectTeam1" or "Employees2020" System Role: Source, Proxy | SAP Central Business Configuration |
cbc.group.prefix | This property distinguishes SAP Central Business Configuration groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: CBC_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP Central Business Configuration source system and will be provisioned to the target system with the following name pattern: CBC_<GroupDisplayName>. This way SAP Central Business Configuration groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP Central Business Configuration groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the CBC_ prefix in their display name will be provisioned to SAP Central Business Configuration. Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be be provisioned to SAP Central Business Configuration.System Role: Source and Target | SAP Central Business Configuration |
cbc.user.filter | When specified, only those SAP Central Business Configuration users matching the filter expression will be read. Note For source systems only: Using this property makes sense only if you have set the "ignore": true statement to false. Possible values: For example: name.familyName eq "Smith" and addresses.country eq "US" System Role: Source, Proxy | SAP Central Business Configuration |
cc.content.type | Makes the connector send a specified value for the Content-Type HTTP header. This is needed because a SCIM system could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json If the property is not specified, the default value is taken: application/scim+json System Role: Target, Proxy | SAP Commerce Cloud |
cc.group.filter | When specified, only those groups matching the filter expression will be read. Possible values: For example: displayName eq "ProjectTeam1" or "Students2018" System Role: Source, Proxy | SAP Commerce Cloud |
cc.group.unique.attribute | If you try to provision a group that already exists in a target system, the group creation will fail. In this case, the existing group only needs to be updated. This property defines by which unique attribute(s) the existing group will be searched and resolved. The default value is displayName. Currently, it is the only unique attribute that is supported. When set, you can expect the following behavior:If a group with the given displayName is found in the target system, the group that you try to provision will overwrite the existing one.If a group with the given displayName is not found in the target system, the group that you try to provision will not be created in the target system.Possible values: If the property is not specified, the search is done by the default attribute: displayNameSystem Role: Target, Proxy | SAP Commerce Cloud |
cc.include.if.match.wildcard.header | Makes the SAP Commerce Cloud connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by an SAP Commerce Cloud system for entity versioning. Possible values:true falseDefault value: falseSystem Role: Target, Proxy | SAP Commerce Cloud |
cc.patch.group.members.above.threshold | Defines the threshold number of group members above which they are provisioned on batches with PATCH requests, and below which they are provisioned with PUT request. Setting this property allows you to avoid timeouts when updating groups with a large number of group members. Note You can use this property when SAP Commerce Cloud is based on SAP Commerce Cloud SCIM API (in short, SCIM API version 2).Default value: 20 000 Maximum value: 200 000For example:PATCH requests: If you have a group with 700 members and you update the group by adding another 1200 members, setting this property to 900 results in the following: As 1900 (the target count of the members) is above the threshold number of 900, 2 PATCH requests will be sent to the Identity Authentication target system. The first request will add 900 group members and the second request will add 300 group members. The threshold number you set defines the maximum number of group members processed per batch.PUT request: If you have a group with 700 members and you update the group by adding another 100 members, setting this property to 900 results in the following: As 800 (the target count of the members) is below the threshold number of 900, 1 PUT request with 800 group members will be sent to the Identity Authentication target system to update the group. Note Regardless of the threshold number you define, when removing group members in SAP Commerce Cloud, the maximum number of members which can be removed per one PATCH request is 98. System Role: Target | SAP Commerce Cloud |
cc.patch.group.members.of.nested.groups | If you set this property to true, Identity Provisioning will update only user members of a group in SAP Commerce Cloud target system. The update will be executed on batches via PATCH requests. This will preserve the group hierarchy with nested groups in the SAP Commerce Cloud backend. Possible values: true falseDefault value: falseSystem Role: Target | SAP Commerce Cloud |
cc.support.patch.operation | This property controls how modified entities (users and groups) in the source system are updated in the target system.If set to true, Identity Provisioning sends a PATCH request to the user or group resource in the target system. Only attributes without "scope": "createEntity" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with explicitly set "scope": "createEntity".If set to false, PUT operations are used to update users and groups in the target system. This means, for example, that if a user attribute is modified or a group member is removed from a group, all user attributes and all group attributes are replaced in the target system, instead of updating only the modified ones.Additional Information: There are different cases when an entity should be updated in the target system:In the source system, some of the entity attributes have been changed, or new attributes have been added. In the source system, a condition or a filter is set for this entity not to be read anymore. The whole entity has been deleted from the source system. In the last two cases, it's possible to keep the entity in the target system – it will not be deleted but only disabled. To do this, use the deleteEntity scope in the transformation of your target or proxy system. See: Transformation Expressions → deleteEntity. Possible values: true false Default value for proxy systems: true Default value for target systems: false System Role: Proxy, Target | SAP Commerce Cloud |
cc.user.filter | When specified, only those users matching the filter expression will be read. You can filter users by userName, emails.value, and externalId, according to the API syntax of SAP Commerce Cloud. Possible values: text/ numeric string For example: userName eq "johnbrown" and externalId eq "P000252" userName eq "johnbrown" and emails.value eq "johnbrown@email.com"userName eq "johnbrown" and emails.value eq "johnbrown@email.com" and externalId eq "P000252"Note These combinations are valid for both 'or' and 'and' operators.System Role: Source, Proxy | SAP Commerce Cloud |
cc.user.unique.attribute | When Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). If the service finds such a user on the target system via this filter, then the conflicting user will overwrite the existing one. If the service does not find such a user, the creation will fail. The property is automatically added during system creation. If the service finds an existing user by at least one of the uniqueness criteria, which are email, userName, or externalId, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the update of the conflicting user fails. If more than one users with these unique attributes are found, the update fails. Possible values:emails[0].value, userName, externalId Default value: emails[0].value, userName, externalIdSystem Role: Target, Proxy | SAP Commerce Cloud |
cflp.bulk.operations.max.count | This property sets the number of operations to be performed in one bulk request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, the service will replace it with the default value (20). System Role: Target | SAP Build Work Zone, standard edition |
cflp.group.filter | When specified, only those SAP Build Work Zone, standard edition groups matching the filter expression will be read. By default, groups are always filtered by the providerId. Possible values:externalId eq 12345678urn:ietf:params:scim:schemas:extension:2.0:mapping.providerId eq 'ABC123'meta.isIAG eq true This filtering attribute indicates whether the group will be used in a hybrid scenario with SAP Cloud Identity Access Governance.System Role: Proxy | SAP Build Work Zone, standard edition |
cflp.group.unique.attribute | If Identity Provisioning tries to provision a group that already exists in the target system (a conflicting group), this property defines the unique attributes by which the existing group will be searched and resolved. Possible values: SAP Build Work Zone, standard edition supports a pair of unique attributes which is automatically filled in when the target system is added in the service UI: externalId,['urn:ietf:params:scim:schemas:extension:2.0:mapping']['providerId'] For the conflict to be resolved, an existing group matching both unique attributes should be found. In this case, Identity Provisioning updates the group. This means, the conflicting group overwrites the existing one. If the group matches only one of the unique attributes, the conflict is not resolved, and the group creation fails. Recommendation We recommend that you do not modify the value of the cflp.group.unique.attribute property. Otherwise, the group creation fails. System Role: Target, Proxy | SAP Build Work Zone, standard edition |
cflp.patch.group.members.above.threshold | Defines the threshold number of group members above which they are provisioned on batches with PATCH requests, and below which they are provisioned with PUT request. Setting this property allows you to avoid timeouts when updating groups with a large number of group members. Possible values: integer Default and maximum value: 5000 For example:PATCH requests: If you have a group with 700 members and you update the group by adding another 1200 members, setting this property to 900 results in the following: As 1900 (the target count of the members) is above the threshold number of 900, 2 PATCH requests will be sent to the SAP Build Work Zone, standard edition target system. The first request will add 900 group members and the second request will add 300 group members. The threshold number you set defines the maximum number of group members processed per batch.PUT request: If you have a group with 700 members and you update the group by adding another 100 members, setting this property to 900 results in the following: As 800 (the target count of the members) is below the threshold number of 900, 1 PUT request with 800 group members will be sent to the SAP Build Work Zone, standard edition target system to update the group.Note If the maximum value of 5 000 is exceeded, the system will automatically use the default value. System Role: Target | SAP Build Work Zone, standard edition |
cflp.providerId | Your SAP Build Work Zone, standard edition provider ID The provider ID is specified in the Channel Manager of theSAP Build Work Zone, standard edition when defining a new content provider. For more information about configuring the content provider to use the Identity Provisioning service, see Configure Integration with the Identity Provisioning Service Possible values: The value of your SAP Build Work Zone, standard edition provider ID For example: ABC123 System Role: Target, Proxy | SAP Build Work Zone, standard edition |
cflp.support.bulk.operation | This property enables bulk operations for users and groups. When bulk operations are enabled (set to true), Identity Provisioning service creates, updates, and deletes multiple users and groups in one request. When bulk operations are not enabled (set to false), Identity Provisioning service creates, updates, and deletes one user and group at a time. Possible values:true falseDefault value: false System Role: Target | SAP Build Work Zone, standard edition |
cflp.support.patch.operation | This property controls how modified entities (users and groups) in the source system are updated in the target system.If set to true, Identity Provisioning sends a PATCH request to the user or group resource in the target system. Only attributes without "scope": "createEntity" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with explicitly set "scope": "createEntity".If set to false, PUT operations are used to update users and groups in the target system. This means, for example, that if a user attribute is modified or a group member is removed from a group, all user attributes and all group attributes are replaced in the target system, instead of updating only the modified ones.Users and groups can be updated in the target system in various cases, such as:In the source system, some user or group attributes are modified, or new attributes are added. In the source system, a condition or a filter is set for users or groups not to be read anymore. A user or a group is deleted from the source system. In the last two cases, it's possible to keep the entity in the target system – it will not be deleted but only disabled. To do this, use the deleteEntity scope in the transformation of your target or proxy system. See: Transformation Expressions → deleteEntity. Possible values: true false Default value for proxy systems: true Default value for target systems: false System Role: Target, Proxy | SAP Build Work Zone, standard edition |
cflp.user.filter | When specified, only those SAP Build Work Zone, standard edition users matching the filter expression will be read. By default, users are always filtered by the providerId. If another filtering attribute is defined, for example the email of the user, both filters are combined. Possible values:emails.value eq 'john.smith@example.com' Note Although, the email is supported as a filtering attribute, it is not returned when searching for the user.urn:ietf:params:scim:schemas:extension:2.0:mapping.providerId eq 'ABC123'System Role: Proxy | SAP Build Work Zone, standard edition |
cflp.user.unique.attribute | If Identity Provisioning tries to provision a user that already exists in the target system (a conflicting user), this property defines the unique attributes by which the existing user will be searched and resolved. Possible values: SAP Build Work Zone, standard edition supports the following unique attributes which are automatically filled in when the target system is added in the service UI: emails[0].value,['urn:ietf:params:scim:schemas:extension:2.0:mapping']['providerId'],externalIdIf the user has an externalId, the conflict is resolved by externalId and providerId.If the user doesn't have an externalId, the conflict is resolved by email and providerId.For the conflict to be resolved, an existing user matching both unique attributes should be found. If an existing user doesn't match both unique attributes or matches only one of them, the user creation fails. Recommendation We recommend that you do not modify the value of the cflp.user.unique.attribute property. Otherwise, user craetion fails. System Role: Target, Proxy | SAP Build Work Zone, standard edition |
CloudConnectorLocationId | Relevant when the ProxyType property is set to OnPremise. Use it only if your SAP Business Technology Platform account uses more than one Cloud Connector. Possible values: String System Role: Source, Target, Proxy | SSH Server (Beta) SAP HANA Database (Beta) LDAP Server Microsoft AD All HTTP systems |
com.sun.jndi.ldap.connect.timeout | Use this property if you want to set the timeout (in milliseconds) for connecting to the LDAP server. Possible values: For example: 500 This value causes the LDAP service provider to abort the connection attempt if a connection cannot be established in half a second. System Role: Source | LDAP Server Microsoft AD |
com.sun.jndi.ldap.read.timeout | Use this property if you want to specify the read timeout (in milliseconds) for an LDAP connection. Possible values: For example: 5000 This value causes the LDAP service provider to abort the read attempt if the server does not respond within 5 seconds. System Role: Source | LDAP Server Microsoft AD |
concur.api.version | Defines the version of SAP Concur API. Possible values:1 - SAP Concur User v1 API is used.2 - SAP Concur Identity v4 API (SCIM API) is used. This is the default value.System Role: Source, Target, Proxy | SAP Concur (using SAP Concur Identity v4 API) |
concur.authorization.code | Enter the Company Request Token and run a provisioning job within 24 hours from generating the token in the SAP Concur Company Request Token self-service tool. Otherwise, the token will expire, and you’ll need a new one. After the first run of the job, Identity Provisioning fills in automatically a refresh token as the value of the concur.refresh.token property. If a provisioning job has not been run for six months, you’ll again need to generate a new token. Remember The company request token has a 24 hour validity. If this token expires, you must request a new token.The refresh token has a six month validity. Every time you run a provisioning job, the validity of the refresh token is extended with six months starting from the date of the last run. If you haven't run a provisioning job for six months, your refresh token will expire and you must request a new company request token.The Company Request Token is generated in the SAP Concur Company Request Token self-service tool.System Role: Source, Target, Proxy | SAP Concur (using SAP Concur Identity v4 API) |
concur.company.domain | Your company domain The username and the company domain are concatenated in the SAP Concur default transformations in the following format: user@domain Your company domain is the part of your username behind the @ symbol. For example: johnsmith@example.com System Role: Target, Proxy | SAP Concur (using SAP Concur Identity v4 API) |
concur.company.id | Your company UUID The Company ID is generated in the SAP Concur Company Request Token self-service tool. System Role: Target, Proxy | SAP Concur (using SAP Concur Identity v4 API) |
concur.content.type | Makes the connector send a specified value for the Content-Type HTTP header. This is needed because a SCIM system could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json If the property is not specified, the default value is taken: application/scim+json System Role: Target, Proxy | SAP Concur (using SAP Concur Identity v4 API) |
concur.datacenter | The SAP Concur data center your Identity Provisioning tenant belongs to. Based on the provided data center, Identity Provisioning configures the URL of the SAP Concur Identity v4 API. For example, if you provide us1, the service will configure the URL in the following pattern: us.api.concursolutions.com. Possible values: The following SAP Concur data centers are available:us1 us2 eu1 eu2 emea cn1 usg intSystem Role: Source, Target, Proxy | SAP Concur (using SAP Concur Identity v4 API) |
concur.include.if.match.wildcard.header | Makes the connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by a SCIM system for entity versioning. Possible values:true falseDefault value: false System Role: Target, Proxy | SAP Concur (using SAP Concur Identity v4 API) |
concur.page.size | Use this property to configure the paging. That means, the number of entities to be read from Concur at once. Possible values: Default value: 100Note The maximum allowed number is 100. System Role: Source | SAP Concur |
concur.user.filter | When specified, only those users matching the filter expression will be read. Possible values: For example:userName eq "johnsmith@example.com"As the userName must be unique across SAP Concur, this filter returns only the user matching this userName.companyId eq "aa067ada-71a9-4f57-8e98-9300b1c3171d"This filter returns all users in the company with this companyId. externalId eq "0fe44868-31a7-4930-9ah30-757tg2513b64" This filter returns a user with the specified value, that is, the userUUID generated for the user in Identity Authentication. employeeNumber eq "Concur Administrator" This filter returns a user with the specified employee number. The employeeNumber could also be a number having six or more digits. System Role: Source | SAP Concur (using SAP Concur Identity v4 API) |
concur.user.unique.attribute | When the Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). If the service finds such a user on the target system via this filter, then the conflicting user will overwrite the existing one. If the service does not find such a user, the creation will fail. According to your use case and system type, choose how to set up this property:Default behavior: This property is missing during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such а userName is not found, the creation of the conflicting user fails. Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = userName,emails[0].value. If the service finds an existing user with both these userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Possible values:userName emails[0].value userName,emails[0].value externalId, or another SCIM attribute, or a conjunction of SCIM attributesDefault value: userName System Role: Target | SAP Concur (using SAP Concur Identity v4 API) |
cpq.group.prefix | This property distinguishes SAP CPQ groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: CPQ_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP CPQ source system and will be provisioned to the target system with the following name pattern: CPQ_<GroupDisplayName>. This way SAP CPQ groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP CPQ groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the CPQ_ prefix in their display name will be provisioned to SAP CPQ. Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be provisioned to SAP CPQ.System Role: Source and Target | SAP CPQ |
cpq.user.filter | When specified, only those SAP CPQ users matching the filter expression will be read. Example: name.familyName eq "Smith" and addresses.country eq "US" System Role: Source, Proxy | SAP CPQ |
csrf.token.path | Path added to the URL to retrieve the CSRF token. The property is automatically added in the system, with default value: /api/v1/scim/Users?count=1. System Role: Source, Target, Proxy | SAP Analytics Cloud |
ep.group.filter | When specified, only those SAP Enterprise Portal groups matching the filter expression will be read. For more information, see Filtering. | SAP Enterprise Portal |
ep.user.filter | When specified, only those SAP Enterprise Portal users matching the filter expression will be read. For more information, see Filtering. | SAP Enterprise Portal |
fg.bulk.operations.max.count | This property sets the number of operations to be performed in one bulk request. Possible values: Default value: 20 Minimum value: 10Maximum value: 100If you provide a value outside of the minimum and maximum range, the service will replace it with the default value (20). System Role: Target | SAP Fieldglass |
fg.group.prefix | This property distinguishes SAP Fieldglass groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: FG_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP Fieldglass source system and will be provisioned to the target system with the following name pattern: FG_<GroupDisplayName>. This way SAP Fieldglass groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP Fieldglass groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the FG_ prefix in their display name will be provisioned to SAP Fieldglass. Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be be provisioned to SAP Fieldglass.System Role: Source and Target | SAP Fieldglass |
fg.support.bulk.operation | Set this property to true if you want to enable bulk operations for provisioning users and groups. This means, the Identity Provisioning service can write, update, and delete multiple users in a single request. For more information, see: SAP Fieldglass Identity Management API Possible values:true falseDefault value: false System Role: Target | SAP Fieldglass |
fsm.content.type | This property makes the SAP Field Service Management connector to send a specified value for the Content-Type HTTP header. This is needed because SAP Field Service Management could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json Default value: application/scim+json System Role: Target, Proxy | SAP Field Service Management |
fsm.group.filter | When specified, only those SAP Field Service Management groups matching the filter expression will be read. Possible values: For example: displayName eq "ProjectTeam1" System Role: Source, Proxy | SAP Field Service Management |
fsm.group.prefix | This property distinguishes SAP Field Service Management groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: FSM_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP Field Service Management source system and will be provisioned to the target system with the following name pattern: FSM_<GroupDisplayName>. This way SAP Field Service Management groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP Field Service Management groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the FSM_ prefix in their display name will be provisioned to SAP Field Service Management. Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be be provisioned to SAP Field Service Management.System Role: Source and Target | SAP Field Service Management |
fsm.group.unique.attribute | If the Identity Provisioning tries to create a group that already exists in the SAP Field Service Management target system, the creation will fail. In this case, the existing group only needs to be updated. This group can be found via search, based on an attribute (default or specific). To make the search filter by a specific attribute, specify this attribute as a value for this property. Possible values: Default value (when not specified): displayName If the property is not specified, the search is done by the default attribute: displayName. System Role: Target, Proxy | SAP Field Service Management |
fsm.include.if.match.wildcard.header | Makes the SAP Field Service Management connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by an SAP Field Service Management system for entity versioning. Possible values:truefalseDefault value: false System Role: Target, Proxy | SAP Field Service Management |
fsm.support.patch.operation | The default value of this property is false. But for SAP Field Service Management proxy systems, this property appears during creation and its predefined value is true. That means, when the Identity Provisioning identifies a changed entity in the back-end system, it will execute the updates as PATCH requests instead of PUT. That is, only changes will be written in SAP Field Service Management, instead of provisioning the whole entity data. Note that only attributes without "scope": "createEntity" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with explicitly set "scope": "createEntity". Possible values: Default value: false Predefined value (during system creation): true System Role: Target, Proxy | SAP Field Service Management |
fsm.user.filter | When specified, only those SAP Field Service Management users matching the filter expression will be read. Possible values: For example: userName eq "SmithJ" System Role: Source, Proxy | SAP Field Service Management |
fsm.user.unique.attribute | When the Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists in SAP Field Service Management. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). According to your use case, choose how to set up this property:Default behavior: This property is missing during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such а userName is not found, the creation of the conflicting user fails. Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = userName,emails[0].value. If the service finds an existing user with both these userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Possible values:userName emails[0].value userName,emails[0].valueDefault value: userName System Role: Target, Proxy | SAP Field Service Management |
gsuite.customer.id | This property determines whether entities for a particular customer ID to be read. This property takes precedence over gsuite.domain. Possible values: Customer ID number For more information, see Google G Suite API: User Accounts. System Role: Source | Google G Suite |
gsuite.domain | This property determines whether entities from a particular domain should be read. Possible values: For example: myaccount.ondemand.com System Role: Source | Google G Suite |
gsuite.get.deleted | This property determines whether recently deleted entities should be read. Note You can apply this property only for users. For groups it will be ignored. Possible values:true falseDefault value: falseSystem Role: Source | Google G Suite |
gsuite.page.size | Use this property to configure the paging. That means, the number of entities to be read from Google G Suite at once. Possible values: Default value: 100Note The maximum allowed number is 500. System Role: Source | Google G Suite |
hana.jdbc.access.type | There are three types of SAP HANA access: direct – It requires only hana.jdbc.db.* properties ssh.tunnel – it requires hana.jdbc.db.* and hana.jdbc.ssh.tunnel.* properties. cf.app.ssh.tunnel – It requires hana.jdbc.ssh.tunnel.cf.* properties to establish an SSH tunnel to the Cloud Foundry application, from which to access the JDBC SQL port of SAP HANA. Possible values: direct ssh.tunnel cf.app.ssh.tunnel System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.db.host | SAP HANA Database host System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.db.password | (Credential) System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.db.port | SAP HANA Database port Possible values: 30015 System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.db.user | Name of the SAP HANA Database user System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.auth.type | The authentication type for the SSH Tunnel. Possible values: Supported SSH authentication types:key pwd otp key+otp key+pwd pwd+otp key+pwd+otpSystem Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.api.url | The URL of the Cloud Foundry API. Possible values: For example: https://api.cf.mycloudfoundryhost.ondemand.com System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.app | This is the Cloud Foundry application to which the SAP HANA Database (Beta) system opens an SSH tunnel. For more information, see: Cloud Foundry: Accessing apps with SSH System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.app.instance | This is the instance number of the Cloud Foundry application. System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.oauth.token.url | The URL of the OAuth token endpoint. Remember Remove the /oauth/token part at the end of the URL. System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.org | This is the Cloud Foundry organization. System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.password | (Credential) The password for property hana.jdbc.ssh.tunnel.cf.username System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.space | This is the Cloud Foundry space. System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.technical.user.origin | This is the origin of the Cloud Foundry technical user, specified in property hana.jdbc.ssh.tunnel.cf.username. If the origin is the same as of the other Cloud Foundry users, you don't need this property – leave it empty or delete it. Possible values: Text/numeric string For example: uaa System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.cf.username | This is the Cloud Foundry user. It has the role Developer for the space where the application is deployed. System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.host | SSH Tunnel’s host System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.password | (Credential) Taken into account only if the authentication type includes pwd. That means any of the following:hana.jdbc.ssh.tunnel.auth.type = pwd hana.jdbc.ssh.tunnel.auth.type = pwd+otp hana.jdbc.ssh.tunnel.auth.type = key+pwd hana.jdbc.ssh.tunnel.auth.type = key+pwd+otpSystem Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.port | SSH Tunnel’s port Possible values: 22 System Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.private.key | (Credential) Taken into account only if the authentication type includes key. That means any of the following:hana.jdbc.ssh.tunnel.auth.type = key hana.jdbc.ssh.tunnel.auth.type = key+pwd hana.jdbc.ssh.tunnel.auth.type = key+otp hana.jdbc.ssh.tunnel.auth.type = key+pwd+otpSystem Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.totp.secret.key | (Credential) Taken into account only if the authentication type includes otp. That means any of the following:hana.jdbc.ssh.tunnel.auth.type = otp hana.jdbc.ssh.tunnel.auth.type = key+otp hana.jdbc.ssh.tunnel.auth.type = pwd+otp hana.jdbc.ssh.tunnel.auth.type = key+pwd+otpSystem Role: Target | SAP HANA Database (Beta) |
hana.jdbc.ssh.tunnel.username | The username used for opening the SSH Tunnel System Role: Target | SAP HANA Database (Beta) |
hcp.application.names | Enter a comma-separated list of application names. That could be applications deployed on your account, or applications for which your account has subscribed. The property returns the roles assigned to these applications.Possible values: Use the following format (no spaces): <app_name1>,<app_name2>,<provider_subaccount>:<provider_app> For example: myapp1,myapp2,provider1:app123,provider2:cloud789,mynewapp Caution You must not leave this property with an empty value.System Role: Source | SAP BTP Java/HTML5 apps (Neo) |
hcp.group.prefix | This property distinguishes groups from Java/HTML5 applications running on SAP BTP, Neo environment by specific prefix. It is an optional property which does not appear by default at system creation. Example value: HCP_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP Business Technology Platform source system and will be provisioned to the target system with the following name pattern: HCP_<GroupDisplayName>. This way groups from Java/HTML5 applications running on SAP BTP, Neo environment in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the groups from Java/HTML5 applications running on SAP BTP, Neo environment will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the HCP_ prefix in their display name will be provisioned to SAP Business Technology Platform. Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be provisioned to SAP Business Technology Platform.System Role: Source and Target | SAP BTP Java/HTML5 apps (Neo) |
hcp.patch.response.with.resource | Use this property when you execute hybrid scenarios with SAP Business Technology Platform (Neo) as a SCIM proxy system, and you update an entity (mostly relevant to groups, like when you change the members of a group) via a PATCH request.If you set this property to true, the successful PATCH request will return a response code 200 (OK) back to the consumer client application with a payload body containing the updated attributes of the relevant group.If you don't specify the property (or it's set to false), the successful PATCH request will return a response code 204 (No Content) indicating successful group update but with no payload body.For more information, see: SCIM 2.0: Modifying with PATCH.Possible values: true false Default value: falseSystem Role: Proxy | SAP BTP Java/HTML5 apps (Neo) |
hcp.read.group.roles | If you set this property to true, the Identity Provisioning will read the following additional attributes for a SAP Business Technology Platform group:Application roles Group mappings, defined by your identity providerRestriction This property is applicable only if SAP Business Technology Platform and the external SCIM-based system belong to one and the same region. Possible values:true falseDefault value: false System Role: Proxy | SAP BTP Java/HTML5 apps (Neo) |
ias.api.version | Defines the version of Identity Authentication SCIM API. Possible values:1 - the Identity Authentication SCIM API is used.2 - the Identity Directory SCIM API is used.Default value: 2 System Role: Source, Target, Proxy | Identity Authentication |
ias.bulk.operations.max.count | This property sets the number of operations to be performed in one bulk request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, Identity Provisioning will replace it with the default value (20). System Role: Target | Identity Authentication (using SCIM API version 2) |
ias.content.type | Makes the connector send a specified value for the Content-Type HTTP header. This is needed because a SCIM system could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json If the property is not specified, the default value is taken: application/scim+json System Role: Target, Proxy | Identity Authentication (SCIM API version 2) |
ias.group.filter | This property filters groups by display name. You can set a single display name or multiple ones as filter criteria. If you enter multiple display names (using OR operator), the filter will search for any of them. Single attribute: displayName eq "<group_name>" Multiple attributes: displayName eq "<group_name1>" or displayName eq "<group_name2>" Possible values: For example:Single attribute: displayName eq "FellowshipTeam1"Multiple attributes: displayName eq "FellowshipTeam1" or displayName eq "JuniorTest3"System Role: Source, Proxy | Identity Authentication (SCIM API version 2) |
ias.group.members.paging.enabled | This property enables paging of group members. The maximum number of group members returned per request is 20 000. To read more than 20 000 group members, paging must be enabled. Possible values:true - Paging is enabled. You can read more than 20 000 group members in one request.false - Paging is disabled. You can read up to 20 000 group members in one request.Default value: false System Role: Source, Proxy | Identity Authentication (SCIM API version 2) |
ias.group.unique.attribute | If you try to provision a group that already exists in a target system, the group creation will fail. In this case, the existing group only needs to be updated. This property defines by which unique attribute(s) the existing group will be searched and resolved. The default value is displayName. Currently, it is the only unique attribute that is supported. When set, you can expect the following behavior:If a group with the given displayName is found in the target system, the group that you try to provision will overwrite the existing one.If a group with the given displayName is not found in the target system, the group that you try to provision will not be created in the target system.Possible values: If the property is not specified, the search is done by the default attribute: displayNameSystem Role: Target, Proxy | Identity Authentication (SCIM API version 2) |
ias.include.if.match.wildcard.header | Makes the connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by a SCIM system for entity versioning. Possible values:true falseDefault value: false System Role: Target, Proxy | Identity Authentication (SCIM API version 2) |
ias.patch.group.members.above.threshold | Defines the threshold number of group members above which they are provisioned on batches with PATCH requests, and below which they are provisioned with PUT request. Setting this property allows you to avoid timeouts when updating groups with a large number of group members. Note You can use this property when Identity Authentication is based on Identity Directory SCIM API (in short, SCIM API version 2).Default value: 20 000 Maximum value: 200 000For example:PATCH requests: If you have a group with 700 members and you update the group by adding another 1200 members, setting this property to 900 results in the following: As 1900 (the target count of the members) is above the threshold number of 900, 2 PATCH requests will be sent to the Identity Authentication target system. The first request will add 900 group members and the second request will add 300 group members. The threshold number you set defines the maximum number of group members processed per batch.PUT request: If you have a group with 700 members and you update the group by adding another 100 members, setting this property to 900 results in the following: As 800 (the target count of the members) is below the threshold number of 900, 1 PUT request with 800 group members will be sent to the Identity Authentication target system to update the group. Note Regardless of the threshold number you define, when removing group members in Identity Authentication, the maximum number of members which can be removed per one PATCH request is 90. System Role: Target | Identity Authentication |
ias.support.bulk.operation | This property enables bulk operations for users and groups. When bulk operations are enabled, Identity Provisioning creates, updates, and deletes multiple users and groups in one request. When bulk operations are not enabled, Identity Provisioning creates, updates, and deletes one user at a time. For more information, see: Identity Directory SCIM API. Possible values:true - bulk operations are enabledfalse - bulk operations are not enabledDefault value: false System Role: Target | Identity Authentication (using SCIM API version 2) |
ias.support.patch.operation | This property controls how modified entities (users and groups) in the source system are updated in the target system.If set to true, Identity Provisioning sends a PATCH request to the user or group resource in the target system. Only attributes without "scope" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with "scope": "createEntity", such as: { "constant":true, "targetPath":"$['urn:ietf:params:scim:schemas:extension:sap:2.0:User']['mailVerified']", "scope":"createEntity" }If set to false, Identity Provisioning sends a PUT request to the user or group resource in the target system. This means, for example, that if a user attribute is modified or a group member is removed from a group, all user attributes and all group attributes are replaced in the target system, instead of updating only the modified ones.Users and groups can be updated in the target system in various cases, such as:In the source system, some user or group attributes are modified, or new attributes are added. In the source system, a condition or a filter is set for users or groups not to be read anymore. A user or a group is deleted from the source system. In the last two cases, it's possible to keep the entity in the target system – it will not be deleted but only disabled. To do this, use the deleteEntity scope in the transformation of your target or proxy system. See: Transformation Expressions → deleteEntity. Possible values: true false Default value: false System Role: Target, Proxy | Identity Authentication (SCIM API version 2) |
ias.user.automatic.conflict.resolution | Controls whether automatic conflict resolution is switched on or off in Identity Authentication (target system) when provisioning is triggered from source systems containing different users with the same user identifiers (IDs). For example, when SAP SuccessFactors and SAP SuccessFactors Learning are configured as source systems for provisioning users to Identity Authentication, it could happen that different SAP SuccessFactors and SAP SuccessFactors Learning users have the same user IDs. In this case, when the first user is created in Identity Authentication, after triggering a provisioning job, the second (conflicting) user will either overwrite the already existing one (automatic conflict resolution is switched on) or will fail and won't be created (automatic conflict resolution is switched off). To control this behavior, you can use the ias.user.automatic.conflict.resolution property in the target Identity Authentication system. This property is not added by default.Possible values:true - If the property is set to true, or is not set at all, the automatic conflict resolution is switched on. This means that Identity Provisioning takes into account the unique attribute(s) defined on the scim.user.unique.attribute property (when using SCIM API version 1) or ias.user.unique.attribute property (when using SCIM API version 2) and tries to find an already existing user in Identity Authentication matching these attributes.If a user is found, the provisioning of a new (conflicting) user is resolved as follows: the conflicting user overwrites the existing one.If a user is not found, the provisioning of a conflicting user fails, and it is not created in Identity Authentication. false - If the property is set to false, the automatic conflict resolution is switched off. This means that Identity Provisioning does not take into account the unique attribute(s) defined on the scim.user.unique.attribute property (when using SCIM API version 1) or ias.user.unique.attribute property (when using SCIM API version 2) and fails the provisioning of a conflicting user. This user is not created in Identity Authentication and does not overwrite the existing one. In the Job Log, an error code 409, uniqueness will be displayed. Default value: true System Role: Target | Identity Authentication |
ias.user.filter | This property filters users by attributes from the SCIM core schema, the Enterprise user resource schema and the Custom defined schema. For example: userName, emails.value, addresses.country, employeeNumber, costCenter, department and others. For more information on the attributes defined in the SCIM core schema and the Enterprise user resource schema, see Identity Directory Service Schema View You can set a single attribute or multiple ones as search criteria in the following value pattern: Single attribute: <user_attribute> eq "<value>" Multiple attributes: <user_attribute1> eq "<value1>" and/or <user_attribute2> eq "<value2>"Possible values: For example:Single attribute: userName eq "Sebastian"Multiple attributes (with OR): userName eq "Sebastian" or addresses.country eq "France"Multiple attributes (with AND): userName eq "Sebastian" and addresses.country eq "France" Multiple attributes (with brackets): userName eq "Sebastian" or (addresses.country eq "France" and emails.value eq "sebastian123@mail.com") Multiple attributes (enterprise attributes): urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department eq "Dev" and urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization eq "Technology" System Role: Source, Proxy | Identity Authentication (SCIM API version 2) |
ias.user.groups.paging.enabled | This property enables paging of user’s groups. The maximum number of user’s groups returned per request is 1000. To read more than 1000 user’s groups, paging must be enabled. Possible values:true - Paging is enabled. You can read more than 1000 user’s groups in one request.false - Paging is disabled. You can read up to 1000 user’s groups in one request.Default value: false System Role: Source, Proxy | Identity Authentication (SCIM API version 2) |
ias.user.unique.attribute | When Identity Provisioning attempts to provision a user for the first time, it may detect that this user already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user will be searched and resolved. If the service finds a user on the target system via this filter, then the conflicting user will overwrite the existing one. If the service does not find a user on the target system via this filter, the creation will fail. According to your use case and system type, choose how to set up this property:Default behavior: This property is set during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such userName is not found, the creation of the conflicting user fails. Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = userName,emails[0].value. If the service finds an existing user with both these userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = phoneNumbers[0].value. If the service finds an existing user with such phoneNumber, it updates this user with the data of the conflicting one. If a user with such phoneNumber is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Value = userName, phoneNumbers[0].value. If the service finds an existing user with both these userName and phoneNumber, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Value = userName, emails[0].value, phoneNumbers[0].value. If the service finds an existing user with these userName, email and phoneNumber, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Possible values: userName emails[0].value userName,emails[0].value phoneNumbers[0].value userName, phoneNumbers[0].value userName, emails[0].value, phoneNumbers[0].value externalId, or another SCIM attribute, or a conjunction of SCIM attributes Default value: userName System Role: Target, Proxy | Identity Authentication (SCIM API version 2) |
ias.user.update.instead.delete | When using SCIM API version 2, this property allows you to update user attributes with PATCH request in Identity Authentication target system and to preserve the user record instead of deleting it. This behavior is supported only when the scope of the attribute is set to deleteEntity. In addition to configuring this property, you also need to adapt the write transformation. For example, if you want to disable a user account in Identity Authentication, you need to do the following:Set ias.user.update.instead.delete=trueAdapt the write transformation as follows: { "user":{ "mappings":[ { "constant":"urn:ietf:params:scim:api:messages:2.0:PatchOp", "targetPath":"$.schemas[0]", "scope":"deleteEntity" }, { "constant":"replace", "targetPath":"$.Operations[0].op", "scope":"deleteEntity" }, { "constant":"active", "targetPath":"$.Operations[0].path", "scope":"deleteEntity" }, { "constant":false, "targetPath":"$.Operations[0].value", "scope":"deleteEntity" }, ...In this case, the PATCH operation will replace true with false as the value of the active user attribute. As a result, when the PATCH operation is executed, the user record in the target system will no longer be managed by Identity Provisioning as it is considered deleted. For more information, see: Transformation Expressions → Scope → deleteEntity → Identity Authentication (SCIM API version 2)Possible values: true false Default value: false When the property is set to true, adapt the write transformation with the attribute name and the attribute value you want to update: { "user":{ "mappings":[ { "constant":"urn:ietf:params:scim:api:messages:2.0:PatchOp", "targetPath":"$.schemas[0]", "scope":"deleteEntity" }, { "constant":"replace", "targetPath":"$.Operations[0].op", "scope":"deleteEntity" }, { "constant":"<attribute_name>", "targetPath":"$.Operations[0].path", "scope":"deleteEntity" }, { "constant":<attribute_value>, "targetPath":"$.Operations[0].value", "scope":"deleteEntity" }, ... System Role: Target | Identity Authentication |
ibp.bulk.operations.max.count | If you have enabled the bulk operations, you can use this property to set the number of users to be provisioned per request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, the service will replace it with the default value (20). System Role: Target | SAP Integrated Business Planning for Supply Chain |
ibp.roles.filter | Enter OData filtering for reading roles in the SAP IBP system. To learn what criteria you can use, see: OData URI Conventions → 4.5 Filter System Query Option System Role: Source, Proxy | SAP Integrated Business Planning for Supply Chain |
ibp.roles.page.size | This property indicates how many business roles (considered as groups) per page to be read from your SAP IBP source system. Possible values: Integer number For example, if you set the property's value = 30, the Identity Provisioning will read 30 roles (groups) at once, then – another 30, and so on. System Role: Source, Proxy | SAP Integrated Business Planning for Supply Chain |
ibp.roles.prefix | This property distinguishes SAP Integrated Business Planning for Supply Chain roles by specific prefix. It is an optional property which does not appear by default at system creation. Example value: IBP_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the roles that are read from the SAP Integrated Business Planning for Supply Chain source system and will be provisioned to the target system with the following name pattern: IBP_<role_name> . This way SAP Integrated Business Planning for Supply Chain roles in the target system will be distinguished from roles provisioned from other applications. If the property is not set, the SAP Integrated Business Planning for Supply Chain roles will be read and provisioned to the target system with their actual role names.When set in the target system, only roles containing the IBP_ prefix in their role name will be provisioned to SAP Integrated Business Planning for Supply Chain. Roles without this prefix in the role name won't be provisioned. If the property is not set, all roles will be be provisioned to SAP Integrated Business Planning for Supply Chain.System Role: Source and Target | SAP Integrated Business Planning for Supply Chain |
ibp.skip.read.archived | In the event of archived (disabled) entities in a source SAP IBP system, you can choose whether the provisioning jobs to continue reading such entities or to skip them. In the source systems, this property is activated by default. If you want to always read disabled entities, set the property to false, or delete it. Possible values:true falseDefault value: true System Role: Source, Target, Proxy | SAP Integrated Business Planning for Supply Chain |
ibp.support.bulk.operation | Set this property to true if you want to enable bulk operations for provisioning entities. That means, the Identity Provisioning service can write, update, and delete multiple users or groups in a single request. For more information, see: APIs for Business User Management Possible values:true falseDefault value: false System Role: Target | SAP Integrated Business Planning for Supply Chain |
ibp.user.roles.overwrite | This property defines whether the current roles of a user to be preserved or overwritten by the Identity Provisioning service within the SAP IBP target or proxy system. See also: Extended Explanation of the *user.roles.overwrite Properties Possible values:true – the current user roles will be deleted in the proxy system, and the user will be updated only with the roles provisioned by the service. false – the current user roles will be preserved, and the new roles (if any) will be added for the relevant user in the proxy system.Default value (if the property is missing during system creation): trueDefault value (if the property appears during system creation): false System Role: Target, Proxy | SAP Integrated Business Planning for Supply Chain |
idds.bulk.operations.max.count | This property sets the number of operations to be performed in one bulk request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, Identity Provisioning will replace it with the default value (20). System Role: Target | Local Identity Directory (when Identity Provisioning is running on SAP Cloud Identity Infrastructure) |
idds.group.filter | This property filters groups by display name. You can set a single display name or multiple ones as filter criteria. If you enter multiple display names (using OR operator), the filter will search for any of them. Value pattern (single): displayName eq "<group_name>" Value pattern (multiple): displayName eq "<group_name1>" or displayName eq "<group_name2>" Possible values: For example:Single: displayName eq "FellowshipTeam1"Multiple: displayName eq "FellowshipTeam1" or displayName eq "JuniorTest3"System Role: Source, Proxy | Local Identity Directory |
idds.group.members.paging.enabled | This property enables paging of group members. The maximum number of group members returned per request is 20 000. To read more than 20 000 group members, paging must be enabled. Possible values:true - Paging is enabled. false - Paging is disabled.Default value: false System Role: Source, Proxy | Local Identity Directory |
idds.patch.group.members.above.threshold | Defines the threshold number of group members above which they are provisioned on batches with PATCH requests, and below which they are provisioned with PUT request. Setting this property allows you to avoid timeouts when updating groups with a large number of group members. Note You can use this property when Identity Authentication and Identity Provisioning (where Local Identity Directory is configured), are running on the same infrastructure, that is, the infrastructure of Identity Authentication.Default value: 20 000 Maximum value: 200 000For example:PATCH requests: If you have a group with 700 members and you update the group by adding another 1200 members, setting this property to 900 results in the following: As 1900 (the target count of the members) is above the threshold number of 900, 2 PATCH requests will be sent to the Local Identity Directory target system. The first request will add 900 group members and the second request will add 300 group members. The threshold number you set defines the maximum number of group members processed per batch.PUT request: If you have a group with 700 members and you update the group by adding another 100 members, setting this property to 900 results in the following: As 800 (the target count of the members) is below the threshold number of 900, 1 PUT request with 800 group members will be sent to the Local Identity Directory target system to update the group. Note Regardless of the threshold number you define, when removing group members in Local Identity Directory, the maximum number of members which can be removed per one PATCH request is 90. System Role: Target | Local Identity Directory |
idds.support.bulk.operation | This property enables bulk operations for users and groups. When bulk operations are enabled, Identity Provisioning creates, updates, and deletes multiple users and groups in one request. When bulk operations are not enabled, Identity Provisioning creates, updates, and deletes one user at a time. For more information, see: Identity Directory SCIM API. Possible values:true - bulk operations are enabledfalse - bulk operations are not enabledDefault value: false System Role: Target | Local Identity Directory (when Identity Provisioning is running on SAP Cloud Identity Infrastructure) |
idds.user.filter | This property filters users by particular attributes. You can set a single attribute or multiple ones as search criteria. Value pattern (single): <user_attribute> eq "<value>" Value pattern (multiple): <user_attribute1> eq "<value1>" and/or <user_attribute2> eq "<value2>" Possible values: For example:Single: userName eq "Sebastian"Multiple (with OR): userName eq "Sebastian" or addresses.country eq "France" Multiple (with AND): userName eq "Sebastian" and addresses.country eq "France" Multiple (with brackets): userName eq "Sebastian" or (addresses.country eq "France" and emails.value eq "sebastian123@mail.com")Multiple (enterprise attributes): urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department eq "Dev" and urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:organization eq "Technology"System Role: Source, Proxy | Local Identity Directory |
idds.user.groups.paging.enabled | This property enables paging of user’s groups. The maximum number of user’s groups returned per request is 1000. To read more than 1000 user’s groups, paging must be enabled. Possible values:true - Paging is enabled. false - Paging is disabled.Default value: false System Role: Source, Proxy | Local Identity Directory |
ips.date.variable.format | This is a default property that the Identity Provisioning UI automatically adds to the configuration of every newly created system. The property allows you to change the default date format to another, more suitable for your scenario. See also: Transformation Variables. Possible values: Default value: yyyy-MM-dd HH:mm:ss.SSS System Role: Source, Target, Proxy | All systems |
ips.delete.existedbefore.entities | Use case: An entity exists on the target system, and then a provisioning job reads the same entity from a source system and updates it on the target. If later on you delete this entity from the source system, the next provisioning job will recognize it as a "previously existed one" and will not delete it from the target. If you want such recognized entities to be deleted from the target as well, open the relevant target system and set this property to true. For more information, see Manage Deleted Entities.Possible values:true falseDefault value: falseSystem Role: Target, Proxy | All systems |
ips.delta.read | If this property is enabled, every time a provisioning job is started, it does not retrieve the entire amount of source system data but only the last changed entities. For more information, see Manage Full and Delta Read. Possible values:enabled disabledSystem Role: Source | Identity Authentication Local Identity Directory Microsoft AD SAP SuccessFactors SAP SuccessFactors Learning SCIM System SAP Central Business Configuration |
ips.failed.request.retry.attempts | If an entity operation (create, update, delete) fails due to a rate limit (response code 429 Too Many Requests), you can specify a number of retries for this operation. Use this property to set the number of retries. Tip Rate limit is the controlled rate of requests sent to a system. Some systems implement rate limit to avoid overloading and performance issues. Possible values: Default value: 2 Maximum value: 3 System Role: Source, Target, Proxy Note Not relevant for proxy Identity Authentication. | SAP Jam Collaboration Identity Authentication SAP Analytics Cloud |
ips.failed.request.retry.attempts.interval | Specify a time interval (in seconds) between the retries, in case an operation fails due to a timeout or rate limit. This property is related to ips.failed.request.retry.attempts. Possible values: Default value: 30 Maximum value: 60 System Role: Source, Target, Proxy Note Not relevant for proxy Identity Authentication. | SAP Jam Collaboration Identity Authentication SAP Analytics Cloud SAP BTP XS Advanced UAA (Cloud Foundry) Note Following an HTTP 502 Bad Gateway server error, the time interval for this system must not exceed 50 (seconds). |
ips.full.read.force.count | If your system (connector) works in delta read mode, it's recommended to enforce full reads from time to time. To achieve this, set this property to an integer number. Possible values: For example: 10 This value results in alternating full reads after every 10 delta reads are performed. In case the property is not set, only delta read jobs will be executed. For more information, see Manage Full and Delta Read. System Role: Source | All, except for: SAP Application Server ABAP SSH Server (Beta) |
ips.http.header.<header_name> | Use this property to pass additional information with the HTTP requests. The provisioning system may override your custom HTTP headers, if specific header settings are implemented in the system.Possible values: Example for an authorization header: ips.http.header.authorization = Basic VDAwdfhjgHGSzmfnNA== Note If you provide credentials for the provisioning system, this property will not take effect. Its value (token) will be overridden by the token generated by the system implementation.System Role: Source, Target, Proxy | All HTTP systems |
ips.job.notification.ignored.consecutive.failures | If you have activated notifications for a source system and a provisioning job fails, you'll receive notification e-mails with subject Provisioning Finished with Error. You can also receive an e-mail if you manually stop a running job. With property ips.job.notification.ignored.consecutive.failures, you can control the number of the received consecutive notifications. Note Property ips.job.notification.repeat.on.failure must be set to false or not specified at all. Example: If you set ips.job.notification.ignored.consecutive.failures = 3 and the job is constantly failing, the first three times you'll not receive a notification. On the fourth job fail, you will receive one notification e-mail. No subsequent e-mails will be sent by the service until the first successful run of the job. See also: Manage Job Notifications.Possible values: Default value: 0. That means, a notification e-mail will be sent after the first job fail.System Role: Source | All systems |
ips.job.notification.repeat.on.failure | If you have activated notifications for a source system and a provisioning job fails, you'll receive notification e-mails with subject Provisioning Finished with Error. You can also receive an e-mail if you manually stop a running job. With property ips.job.notification.repeat.on.failure, you can control the frequency of the received notifications.If you set the property to true, you will receive notification e-mails every time a job fails. If you want to stop or control the notification frequency, set the property to false (default value).This property has a higher priority than ips.job.notification.ignored.consecutive.failures. See also: Manage Job Notifications.Possible values:true false Default value: false. That means, when a job fails, only one notification e-mail will be sent. System Role: Source | All systems |
ips.job.notification.skip.intermediate.notifications | If you have activated notifications for a source system, and an entity fails during the provisioning job, you'll receive one notification e-mail with subject Provisioning Running with Error. Property ips.job.notification.skip.intermediate.notifications controls whether you will receive a notification or not.If the property is set to true, no notifications will be sent.If the property is not specified or is set to false (default), you'll receive one notification e-mail. No subsequent e-mails will be sent by the service until the first successful run of the job.See also: Manage Job Notifications.Possible values: true false Default value: false. That means, after the first failed entity, a notification e-mail will be sent. System Role: Source | All systems |
ips.overwrite.existedbefore.assignments | This property defines whether or not the Identity Provisioning service to overwrite user/group assignments that have existed in the target system before you start provisioning entities to that system. Example: Let's say there is a group in the target system that contains some assignments (users and subgroups). In the source system there is a matching group, which contains different assignments.If you start a provisioning job without setting this property (by default, it's true), all assignments from the source group will overwrite the ones from the target group. If you set the property to false, all existing assignments will be kept in the target system group, and the new ones will just be added.Possible values:true falseDefault value: true System Role: Target | SAP Application Server ABAP |
ips.trace.failed.entity.content | If a provisioning job repeatedly fails and you need problem investigation, you can enable logging and tracing for the personal and sensitive data of your provisioned entities. To do this, set this property to true. If the property is not set, in the logs you see: content = <hidden content> To learn more about personal and sensitive data, see:Glossary for Data Protection and Privacy Customer Data → Data Storage SecurityPossible values:true falseDefault value: false System Role: Source | All systems |
ips.trace.skipped.entity | This property allows you to download and view the details of all skipped entities for a given job in a zip archive. For more information, see Manage Provisioning Job Logs Possible values:true - The downloaded zip file contains all skipped entities for the given job, the systems they are skipped from, the reason behind this, as well as the content of the entities (if ips.trace.skipped.entity.content is set to true).false - The downloaded zip file is empty.Default value: falseSystem Role: Source | All systems |
ips.trace.skipped.entity.content | If a provisioning job results in skipping entities from source or target systems, you can view the details for each skipped user and group. To do this, you need to enable logging and tracing for the personal and sensitive data of your provisioned entities by setting the property to true. If the property is not set, in the logs you see: content = <hidden content> To learn more about personal and sensitive data, see:Glossary for Data Protection and Privacy Customer Data → Data Storage SecurityPossible values:true falseDefault value: false System Role: Source | All systems |
jam.group.prefix | This property distinguishes SAP Jam Collaboration groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: SJC_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP Jam Collaboration source system and will be provisioned to the target system with the following name pattern: SJC_<GroupDisplayName>. This way SAP Jam Collaboration groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP Jam Collaboration groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the SJC_ prefix in their display name will be provisioned to SAP Jam Collaboration. Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be be provisioned to SAP Jam Collaboration.System Role: Source and Target | SAP Jam Collaboration |
jco.client.ashost | Enter the virtual host entry that you have configured in the Cloud connector → Access Control configuration. Possible values: For example: abapserver.hana.cloud System Role: Source, Target, Proxy | SAP Application Server ABAP |
jco.client.client | Enter the client to be used in the ABAP system. Valid format is a three-digit number. Possible values: For example: 001 System Role: Source, Target, Proxy | SAP Application Server ABAP |
jco.client.mshost | Represents the message server host to be used. System Role: Source, Target, Proxy | SAP Application Server ABAP |
jco.client.passwd | Enter the password for the AS ABAP user. System Role: Source, Target, Proxy | SAP Application Server ABAP |
jco.client.r3name | Enter the three-character system ID of the ABAP system to be addressed. Possible values: For example: WPE System Role: Source, Target, Proxy | SAP Application Server ABAP |
jco.client.sysnr | Enter the "system number" of the ABAP system. Possible values: For example: 42 System Role: Source, Target, Proxy | SAP Application Server ABAP |
jco.client.user | Enter the user for AS ABAP. System Role: Source, Target, Proxy | SAP Application Server ABAP |
jco.destination.peak_limit | Represents the maximum number of active connections that can simultaneously be created for a destination. Possible values: For example: 10 System Role: Source, Target, Proxy | SAP Application Server ABAP |
jco.destination.pool_capacity | Represents the maximum number of idle connections kept open by the destination. Possible values: For example: 5 System Role: Source, Target, Proxy | SAP Application Server ABAP |
jwt.scope | Enter space-separated Google Directory API authorization scopes. System Role: Target, Proxy | Google G Suite |
jwt.subject | Enter the Google G Suite user on behalf of which the Google Directory API is called. System Role: Target, Proxy | Google G Suite |
ldap.attribute.dn | This property denotes the distinguished name of a user or a group. The distinguished name is auttomatically assigned and cannot be configured. The behavior described below is valid only when Microsoft Active Directory is used as target system: When the Identity Provisioning attempts to provision a user or a group to Microsoft Active Directory for the first time, it may detect that such a user or group already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user or group by using this property for conflict resolution. If the service finds such a user on the target system via this filter, the creation will fail. In this case, the conflicting user will overwrite the existing one. If the service finds such a group on the target system via this filter, the creation will fail. In this case, the existing group only needs to be updated. If the service does not find a user or a group via this filter, the creation will fail. Possible values: Default and only possible value: distinguishedName System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.attribute.group.id | This property denotes the ID of a group. When a user is a member of a group, this group is returned in the memberOf array for this user. This property evaluates the attribute used as ID of this group. When a group is a member of another group, this property evaluates the attribute used as ID of the "parent group". In this case, the ldap.attribute.group.id property has a higher priority than ldap.group.uniquename.attribute. Possible values: cn (default) distinguishedName – this will produce a memberOf array which contains the distinguishedName attribute value of the groups to which the entity belongs. Note Whatever value you choose for this property, it should correspond to the one in the JSON transformation of your LDAP system (the group mapping). System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.attribute.group.member | Default value: member System Role: Source, Target, Proxy | LDAP Server |
ldap.attribute.group.object.class.required | The LDAP object classes have attributes required for creation of entities.For Open LDAP Server, the required attribute is the common name (CN) of the group. For other implementations, it could be another attribute.Default value: cn System Role: Target, Proxy | LDAP Server |
ldap.attribute.user.givenName | Default value: givenName System Role: Source, Target, Proxy | LDAP Server |
ldap.attribute.user.groups | Default value: memberOf System Role: Source, Target, Proxy | LDAP Server |
ldap.attribute.user.id | This property denotes the ID of a user. When a user is a member of a group, this property evaluates the attribute used as ID of this member. In this case, the ldap.attribute.user.id or ldap.attribute.group.id property has a higher priority than ldap.member.uniquename.attribute.Possible values: Possible values for LDAP Server:cn (default for Microsoft AD) uid (default for LDAP Server) distinguishedNameNote Whatever value you choose for this property, it should correspond to the one in the JSON transformation of your system (the user mapping).System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.attribute.user.mail | Default value: mail System Role: Source, Target, Proxy | LDAP Server |
ldap.attribute.user.mobile | Default value: mobile System Role: Source, Target, Proxy | LDAP Server |
ldap.attribute.user.object.class.required | The LDAP object classes have attributes required for creation of entities.For Open LDAP Server, the required attribute is the common name (CN) of the user. For other implementations, it could be another attribute.Default value: cn System Role: Target, Proxy | LDAP Server |
ldap.attribute.user.surname | Default value: sn System Role: Source, Target, Proxy | LDAP Server |
ldap.attribute.user.telephoneNumber | Default value: telephoneNumber System Role: Source, Target, Proxy | LDAP Server |
ldap.authentication | Authentication type for the LDAP connection Possible values: BasicAuthentication System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.group.attributes | Shows which group attributes from the source system to be included in the LDAP search result (and respectively, in the intermediate JSON data). Separate the attributes by comma (,). Possible values: If nothing is set, all attributes are included. System Role: Source | LDAP Server Microsoft AD |
ldap.group.filter | You can optimize the search to return only particular groups. To enter correct group filters, stick to the standard LDAP specification. See: LDAP Representation of Filters – Examples. Possible values: For example: Value (cn=mar*) will return only groups whose CN starts with "mar" (such as marked, March, or Marketing). By default, this filter is empty. That is, if the property is not specified, the filter will search for every group. System Role: Source | LDAP Server Microsoft AD |
ldap.group.object.class | Criteria for group. In the intermediate JSON data the following LDAP filter is used: (objectClass=group) For target LDAP systems: this property defines the set of supported and required attributes for an LDAP group entity. Possible values: Default value: groupOfNames System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.group.path | Enter the complete path to the node containing the groups in the LDAP tree. Remember We strongly recommend that you enter different paths for LDAP users and groups. That means, the value of ldap.group.path should be different than the value of ldap.user.path. Possible values: For example: ldap.group.path=OU=Groups,OU=IAS,DC=global,DC=corp,DC=mycompany System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.group.uniquename.attribute | By default, the memberOf array in the source JSON data contains the CN part of the complete distinguished name of the groups to which the entity belongs. An administrator can use this property to change the default behavior and specify an attribute name to be used instead of CN. NoteAny group that doesn't have the attribute specified, will not be part of the resulting memberOf JSON array. Any group that doesn't match the ldap.group.path property, will not be part of the resulting memberOf JSON array.Possible values:cn (default for LDAP) displayName – this will produce a memberOf array which contains the displayName attribute value of the groups to which the entity belongs.Note Whatever value you choose for this property, it should correspond to the one in the JSON transformation of your LDAP system (the group mapping). System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.member.uniquename.attribute | Determines the value of the member attribute of groups in the intermediate JSON data. This property can return either the common name (CN) of the user or the entire distinguished name (DN). Possible values:cn (default for Microsoft AD) uid (default for LDAP Server) distinguishedNameNote Whatever value you choose for this property, it should correspond to the one in the JSON transformation of your system (the user mapping). System Role: Source | LDAP Server Microsoft AD |
ldap.page.size | Use this property to configure the paging (pagination). That means, the number of entities to be read from the LDAP server at once. Possible values: Default value: 100Note It is not recommended to exceed 1000. System Role: Source | LDAP Server Microsoft AD |
ldap.password | Password for the LDAP Server user Possible values: Encrypted string System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.proxyType | Proxy type for the LDAP connection Possible values: OnPremise System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.respond.with.resource.after.create | When set to true, the SCIM create operation will read the created entity from the LDAP server. Value true is required because the SCIM create operation must return the created entity. Default value: true System Role: Proxy | LDAP Server |
ldap.respond.with.resource.after.update | When set to true, the SCIM update operation will read the modified entity from the LDAP server. When set to false or the property is missing, the update operation will respond with error 204 (no content). Default value: true System Role: Proxy | LDAP Server |
ldap.url | URL needed to make an LDAP connection to an on-premise system or a cloud service Possible values: ldap://<host><port> System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.user | User name for the LDAP Server Possible values: Text/numeric string System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.user.attributes | Shows which user attributes from the source system to be included in the LDAP search result (and respectively, in the intermediate JSON data). Separate the attributes by comma (,). Possible values: If nothing is set, all attributes are included. System Role: Source | LDAP Server Microsoft AD |
ldap.user.filter | You can optimize the search to return only particular users. To enter correct user filters, stick to the standard LDAP specification. See: LDAP Representation of Filters – Examples. Possible values: For example: Value (cn=123*) will return only users whose UID starts with "123" (such as 1234567689 or 1230011). By default, this filter is empty. That is, if the property is not specified, the filter will search for every user. System Role: Source | LDAP Server Microsoft AD |
ldap.user.object.class | Criteria for user. In the intermediate JSON data, the following LDAP filter is used: (objectClass=user) For target LDAP systems: this property defines the set of supported and required attributes for an LDAP user entity. Possible values: Default value: inetOrgPerson System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
ldap.user.path | Enter the complete path to the users in the LDAP Server or Microsoft AD. Remember We strongly recommend that you enter different paths for LDAP users and groups. That means, the value of ldap.users.path should be different than the value of ldap.group.path. Possible values: For example: ldap.user.path=OU=Users,OU=IAS,DC=global,DC=corp,DC=mycompany System Role: Source, Target, Proxy | LDAP Server Microsoft AD |
lms.content.type | This property makes the SAP SuccessFactors Learning connector to send a specified value for the Content-Type HTTP header. This is needed because SAP SuccessFactors Learning could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json Default value: application/scim+json System Role: Target, Proxy | SAP SuccessFactors Learning |
lms.include.if.match.wildcard.header | Makes the connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by a SCIM system for entity versioning. Possible values:truefalseSystem Role: Target, Proxy | SAP SuccessFactors Learning |
lms.instance.host | Enter the host of your SAP SuccessFactors Learning instance. This property must be configured if you what to use client certificate authentication for the communication between Identity Provisioning and SAP SuccessFactors Learning. System Role: Source, Target, Proxy | SAP SuccessFactors Learning |
lms.support.patch.operation | This property controls how modified users in the source system are updated in the target system.If set to true, Identity Provisioning sends a PATCH request to the user or group resource in the target system. Only attributes without "scope": "createEntity" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with explicitly set "scope": "createEntity".If set to false, PUT operations are used to update users in the target system. This means, for example, that if a user attribute is modified, all user attributes are replaced in the target system, instead of updating only the modified ones.Users can be updated in the target system in various cases, such as:In the source system, some user attributes are modified, or new attributes are added. In the source system, a condition or a filter is set for users not to be read anymore. A user is deleted from the source system. In the last two cases, it's possible to keep the entity in the target system – it will not be deleted but only disabled. To do this, use the deleteEntity scope in the transformation of your target or proxy system. See: Transformation Expressions → deleteEntity. Possible values: true false Default value: false System Role: Target | SAP SuccessFactors Learning |
lms.user.filter | When specified, only those users matching the filter expression will be read. Possible values:userName eq "testName"externalID eq "testID"active eq "true"sourceSystem eq "Learning" - indicates that the user is created directly in SAP SuccessFactors Learning with no involvement of Identity Provisioning. sourceSystem eq "Identity Provisioning" - indicates that the user is created in SAP SuccessFactors Learning by Identity Provisioning. System Role: Source | SAP SuccessFactors Learning |
lms.user.unique.attribute | When Identity Provisioning attempts to provision a user for the first time, it may detect that such user already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). If the service finds such user on the target system via this filter, then the conflicting user will overwrite the existing one. If the service does not find such a user, the creation will fail. Default behavior: The property is missing during system creation. Its default value is userName. This means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such userName is not found, the creation of the conflicting user fails. Possible values: Default value: userName System Role: Target | SAP SuccessFactors Learning |
maco.bulk.operations.max.count | If you have enabled the bulk operations, you can use this property to set the number of users to be provisioned per request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, the service will replace it with the default value (20). System Role: Target | SAP Market Communication |
maco.roles.filter | Enter OData filtering for reading roles in the SAP Market Communication system. To learn what criteria you can use, see: OData URI Conventions → 4.5 Filter System Query Option System Role: Source, Proxy | SAP Market Communication |
maco.roles.page.size | This property indicates how many business roles (considered as groups) per page to be read from your SAP Market Communication source system. Possible values: Integer number In the event of archived (disabled) entities in a source For example, if you set the property's value = In the event of archived (disabled) entities in a source nullnullnullnull30, the Identity Provisioning so on. will read 30 roles (groups) at once, then – another 30, and so on. system, you can choose whether the provisioning jobs to continue reading such entities or to skip them. System Role: Source, Proxy | SAP Market Communication |
maco.roles.prefix | This property distinguishes SAP Market Communication roles by specific prefix. It is an optional property which does not appear by default at system creation. Example value: SMC_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the roles that are read from the SAP Market Communication source system and will be provisioned to the target system with the following name pattern: SMC_<role_name> . This way SAP Market Communication roles in the target system will be distinguished from roles provisioned from other applications. If the property is not set, the SAP Market Communication roles will be read and provisioned to the target system with their actual role names.When set in the target system, only roles containing the SMC_ prefix in their role name will be provisioned to SAP Market Communication. Roles without this prefix in the role name won't be provisioned. If the property is not set, all roles will be be provisioned to SAP Market Communication.System Role: Source and Target | SAP Market Communication |
maco.skip.read.archived | In the event of archived (disabled) entities in a source For example, if you set the property's value = In the event of archived (disabled) entities in a source nullnullnullSAP Market Communication system, you canIn the source and proxy systems, this property is activated by default. If you want to always read disabled entities, set the property to false, or delete it. Possible values:true falseDefault value: trueSystem Role: Source, Target, Proxy | SAP Market Communication |
maco.support.bulk.operation | Set this property to true if you want to enable bulk operations for provisioning entities. That means, the Identity Provisioning service can write, update, and delete multiple users or groups in a single request. For more information, see: APIs for Business User Management Possible values:true falseDefault value: false System Role: Target | SAP Market Communication |
maco.user.roles.overwrite | This property defines whether the current roles of a user to be preserved or overwritten by the Identity Provisioning service within the SAP Market Communication target or proxy system. See also: Extended Explanation of the *user.roles.overwrite PropertiesPossible values:true – the current user roles will be deleted in the proxy system, and the user will be updated only with the roles provisioned by the service. false – the current user roles will be preserved, and the new roles (if any) will be added for the relevant user in the proxy system.Default value (if the property is missing during system creation): trueDefault value (if the property appears during system creation): false System Role: Target, Proxy | SAP Market Communication |
marketing.cloud.bulk.operations.max.count | If you have enabled the bulk operations, you can use this property to set the number of users to be provisioned per request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, the service will replace it with the default value (20). System Role: Target | SAP Marketing Cloud |
marketing.cloud.roles.filter | Enter OData filtering for reading roles in the SAP Marketing Cloud system. To learn what criteria you can use, see: OData URI Conventions → 4.5 Filter System Query Option System Role: Source, Proxy | SAP Marketing Cloud |
marketing.cloud.roles.page.size | This property indicates how many business roles (considered as groups) per page to be read from your SAP Marketing Cloud source system. Possible values: Integer number For example, if you set the property's value = 30, the Identity Provisioning will read 30 roles (groups) at once, then – another 30, and so on. System Role: Source, Proxy | SAP Marketing Cloud |
marketing.cloud.roles.prefix | This property distinguishes SAP Marketing Cloud roles by specific prefix. It is an optional property which does not appear by default at system creation. Example value: SMKC_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the roles that are read from the SAP Marketing Cloud source system and will be provisioned to the target system with the following name pattern: SMKC_<role_name> . This way SAP Marketing Cloud roles in the target system will be distinguished from roles provisioned from other applications. If the property is not set, the SAP Marketing Cloud roles will be read and provisioned to the target system with their actual role names.When set in the target system, only roles containing the SMKC_ prefix in their role name will be provisioned to SAP Marketing Cloud. Roles without this prefix in the role name won't be provisioned. If the property is not set, all roles will be be provisioned to SAP Marketing Cloud.System Role: Source and Target | SAP Marketing Cloud |
marketing.cloud.skip.read.archived | In the event of archived (disabled) entities in a source SAP Marketing Cloud system, you can choose whether the provisioning jobs to continue reading such entities or to skip them. In the source and proxy systems, this property is activated by default. If you want to always read disabled entities, set the property to false, or delete it. Possible values:true falseDefault value: true System Role: Source, Target, Proxy | SAP Marketing Cloud |
marketing.cloud.support.bulk.operation | Set this property to true if you want to enable bulk operations for provisioning entities. That means, the Identity Provisioning service can write, update, and delete multiple users or groups in a single request. For more information, see: APIs for Business User Management Possible values:true falseDefault value: false System Role: Target | SAP Marketing Cloud |
marketing.cloud.user.roles.overwrite | This property defines whether the current roles of a user to be preserved or overwritten by the Identity Provisioning service within the SAP Marketing Cloud target or proxy system. See also: Extended Explanation of the *user.roles.overwrite Properties Possible values:true – the current user roles will be deleted in the proxy system, and the user will be updated only with the roles provisioned by the service. false – the current user roles will be preserved, and the new roles (if any) will be added for the relevant user in the proxy system.Default value (if the property is missing during system creation): trueDefault value (if the property appears during system creation): false System Role: Target, Proxy | SAP Marketing Cloud |
msgraph-filter (Deprecated) | Use this property to filter users and groups by specific criteria, according to the API syntax of Microsoft Azure AD. Note This property is deprecated. Use aаd.user.filter and aаd.group.filter instead. Possible values: Default value: nullTo set a particular value, see Microsoft Graph: filter parameter. System Role: Source | Microsoft Azure Active Directory |
oauth.resource.name | Enter the URL to the Microsoft Graph. Possible values: https://graph.microsoft.com System Role: Source, Target, Proxy | Microsoft Azure Active Directory |
OAuth2TokenServiceURL | If you need to make OAuth authentication to the system, enter the URL to the access token provider service. Possible values: Access token URL System Role: Target, Proxy | SCIM System SAP Analytics Cloud SAP Commissions SAP Jam Collaboration Identity Authentication Local Identity Directory Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) Sales Cloud – Analytics & AI SAP BTP Account Members (Neo) SAP Fieldglass |
Password | It represents: Password – used in standard destinations Client secret key – used for access token retrieval in OAuth HTTP destinations Possible values: Encrypted string System Role: Source, Target, Proxy | All HTTP systems |
ProxyType | Proxy type required for HTTP connection Possible values:Internet OnPremiseSystem Role: Source, Target, Proxy | All HTTP systems |
RecipientPartyID | Note Only relevant to API v.2. Enter the recipient system name. Possible values: For example: 0011SAP System Role: Target | SAP Sales Cloud and SAP Service Cloud |
RemoteSystemID | Note Only relevant to API v.1. Enter the system instance ID, configured for the communication system setting in the SAP Sales Cloud and SAP Service Cloud system. Possible values: For example: IPS System Role: Target | SAP Sales Cloud and SAP Service Cloud |
s4hana.cloud.api.version | This property defines the API version that your SAP S/4HANA Cloud system uses. Version 1 means your SAP S/4HANA Cloud system uses SAP_COM_0193 communication arrangement. System Role: Source, Target, Proxy | SAP S/4HANA Cloud |
s4hana.cloud.bulk.operations.max.count | If you have enabled the bulk operations, you can use this property to set the number of users to be provisioned per request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, the service will replace it with the default value (20). System Role: Target | SAP S/4HANA Cloud |
s4hana.cloud.hr.switch.active | A default property, whose only possible value is true. That means, HR integration is enabled for your system. Caution Do not change this value! Otherwise, your provisioning job will fail. Possible value: true System Role: Target, Proxy | SAP S/4HANA Cloud |
s4hana.cloud.hr.switch.dependent.role.codes | A default property. Add the codes of the roles maintained by the HR integration. Make sure these role codes are part of your read and write transformations. Possible values: For example: BUP003, BBP010, BBP005 That means, your HR integration will support employees, freelancers, and service performers. System Role: Target, Proxy | SAP S/4HANA Cloud |
s4hana.cloud.roles.filter | Enter OData filtering for reading roles in the SAP S/4HANA Cloud system. To learn what criteria you can use, see: OData URI Conventions → 4.5 Filter System Query Option System Role: Source, Proxy | SAP S/4HANA Cloud |
s4hana.cloud.roles.page.size | This property indicates how many business roles (considered as groups) per page to be read from your SAP S/4HANA Cloud source system. Possible values: Integer number For example, if you set the property's value = 30, the Identity Provisioning will read 30 roles (groups) at once, then – another 30, and so on. System Role: Source, Proxy | SAP S/4HANA Cloud |
s4hana.cloud.skip.read.archived | In the event of archived (disabled) entities in a source SAP S/4HANA Cloud system, you can choose whether the provisioning jobs to continue reading such entities or to skip them. In the source and proxy systems, this property is activated by default. If you want to always read disabled entities, set the property to false, or delete it. Possible values:true falseDefault value: trueSystem Role: Source, Proxy | SAP S/4HANA Cloud |
s4hana.cloud.support.bulk.operation | Set this property to true if you want to enable bulk operations for provisioning entities. That means, the Identity Provisioning service can write, update, and delete multiple users or groups in a single request. For more information, see: APIs for Business User Management Possible values:true falseDefault value: false System Role: Target | SAP S/4HANA Cloud |
s4hana.cloud.user.roles.overwrite | This property defines whether the current roles of a user to be preserved or overwritten by the Identity Provisioning service within the SAP S/4HANA Cloud target or proxy system. See also: Extended Explanation of the *user.roles.overwrite PropertiesPossible values:true – the current user roles will be deleted in the proxy system, and the user will be updated only with the roles provisioned by the service. false – the current user roles will be preserved, and the new roles (if any) will be added for the relevant user in the proxy system.Default value (if the property is missing during system creation): trueDefault value (if the property appears during system creation): false System Role: Target, Proxy | SAP S/4HANA Cloud |
s4hana.onprem.bulk.operations.max.count | If you have enabled the bulk operations, you can use this property to set the number of users to be provisioned per request. Possible values: Default value: 20 Maximum value: 100If you enter a number larger than 100, the service will replace it with the default value (20). System Role: Target | SAP S/4HANA On-Premise |
s4hana.onprem.hr.switch.active | Defines whether the system should include HR integration or not. This property is related to s4hana.onprem.hr.switch.dependent.role.codes. Possible values:true – HR integration is enabled for your system false – HR integration is disabled for your systemDefault value: false System Role: Target, Proxy | SAP S/4HANA On-Premise |
s4hana.onprem.hr.switch.dependent.role.codes | Add the codes of the roles maintained by the HR integration. Make sure these role codes are part of your read and write transformations. This property is applicable only if s4hana.onprem.hr.switch.active = true Possible values: For example: BUP003, BBP010, BBP005 That means, your HR integration will support employees, freelancers, and service performers. System Role: Target, Proxy | SAP S/4HANA On-Premise |
s4hana.onprem.sap-client | Use this property if you want to specify a particular AS ABAP client to use as the sap-client URL parameter. If this property is not specified, the URL will open your default AS ABAP client. To learn more, see: Specifying the Client For more information about sap-client, see: SAP URL ParametersPossible values: A three-digit integer number For example: 102System Role: Source, Target, Proxy | SAP S/4HANA On-Premise |
s4hana.onprem.skip.read.archived | In the event of archived (disabled) entities in a source SAP S/4HANA On-Premise system, you can choose whether the provisioning jobs to continue reading such entities or to skip them. In the source and proxy systems, this property is activated by default. If you want to always read disabled entities, set the property to false, or delete it. Possible values:true falseDefault value: trueSystem Role: Source, Proxy | SAP S/4HANA On-Premise |
s4hana.onprem.support.bulk.operation | Set this property to true if you want to enable bulk operations for provisioning entities. That means, the Identity Provisioning service can write, update, and delete multiple users or groups in a single request. For more information, see: APIs for Business User Management Possible values:true falseDefault value: falseSystem Role: Source, Target, Proxy | SAP S/4HANA On-Premise |
s4hana.pp.content.type | Makes the connector send a specified value for the Content-Type HTTP header. This is needed because a SCIM system could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json If the property is not specified, the default value is taken: application/scim+json System Role: Target, Proxy | SAP S/4HANA for procurement planning |
s4hana.pp.include.if.match.wildcard.header | Makes the connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by a SCIM system for entity versioning. Possible values:true falseDefault value: false System Role: Target, Proxy | SAP S/4HANA for procurement planning |
s4hana.pp.user.filter | When specified, only those SAP S/4HANA for procurement planning users matching the filter expression will be read. Possible values: Example: name.familyName eq "Smith" and addresses.country eq "US" System Role: Source, Proxy | SAP S/4HANA for procurement planning |
s4hana.pp.user.unique.attribute | When the Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). If the service finds such a user on the target system via this filter, then the conflicting user will overwrite the existing one. If the service does not find such a user, the creation will fail. According to your use case and system type, choose how to set up this property:Default behavior: This property is missing during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such а userName is not found, the creation of the conflicting user fails. Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = userName,emails[0].value. If the service finds an existing user with both these userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Possible values:userName emails[0].value userName,emails[0].value externalId, or another SCIM attribute, or a conjunction of SCIM attributesDefault value: userName System Role: Target | SAP S/4HANA for procurement planning |
sac.bulk.operations.max.count | If you have enabled the SCIM bulk operations, you can use this property to set the number of users to be provisioned per request. Possible values: Default value: 100 Note The value must not exceed the number of entities defined by the SAP Analytics Cloud system as a SCIM service provider. Otherwise, the provisioning job will fail with HTTP response code 413 (Payload Too Large). System Role: Target | SAP Analytics Cloud |
sac.group.prefix | This property distinguishes SAP Analytics Cloud groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: SAC_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP Analytics Cloud source system and will be provisioned to the target system with the following name pattern: SAC_<GroupDisplayName>. This way SAP Analytics Cloud groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP Analytics Cloud groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the SAC_ prefix in their display name will be provisioned to SAP Analytics Cloud. Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be provisioned to SAP Analytics Cloud.System Role: Source and Target | SAP Analytics Cloud |
sac.support.bulk.operation | Set this property to true if you want to enable SCIM bulk operations for provisioning users. That means, the Identity Provisioning service can write, update, and delete a potentially large collection of users in a single request. For more information, see: SCIM Protocol: Bulk Operations For more information, see: SCIM Protocol: Bulk Operations Note SCIM bulk operations are not supported for provisioning groups to SAP Analytics Cloud.Possible values: true false Default value: falseSystem Role: Target | SAP Analytics Cloud |
sales.cloud.analytics_ai.group.filter | Use this property to filter groups by specific criteria, according to the API syntax of SCAAI. Possible values: Text/numeric string For example: displayName eq "first_group" System Role: Source, Proxy | Sales Cloud – Analytics & AI (Beta) |
sales.cloud.analytics_ai.user.filter | Use this property to filter users by specific criteria, according to the API syntax of SCAAI. Possible values: Text/numeric string For example: externalId eq "John123" System Role: Source, Proxy | Sales Cloud – Analytics & AI (Beta) |
scim.api.csrf.protection | Specifies whether to fetch a CSRF token when sending requests to the system. The property is automatically added in the system, with default value: enabled. Possible values:enabled disabledDefault value: enabled System Role: Source, Target, Proxy | SAP Analytics Cloud |
scim.content.type | Makes the connector send a specified value for the Content-Type HTTP header. This is needed because a SCIM system could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json If the property is not specified, the default value is taken: application/scim+json System Role: Target, Proxy | SCIM System SAP Analytics Cloud SAP Commissions SAP Jam Collaboration Identity Authentication (SCIM API version 1) Local Identity Directory Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) Sales Cloud – Analytics & AI SAP BTP Account Members (Neo) SAP Fieldglass |
scim.group.filter | When specified, only those groups matching the filter expression will be read. Possible values: For example: displayName eq "ProjectTeam1" or "Students2018" System Role: Source | SCIM System SAP Analytics Cloud SAP Commissions SAP Jam Collaboration Identity Authentication (SCIM API version 1) Local Identity Directory Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) Sales Cloud – Analytics & AI SAP BTP Account Members (Neo) SAP Fieldglass |
scim.group.members.additional.attributes | Defines additional attributes you can request from an Identity Authentication source system when reading groups. If you read groups through REST API, use the GET request. Add the additional attributes (coma-separated) as a value of the URL parameter membersAdditionalAttributes. Possible values: a coma-separated list of attribute names You can add the following attributes:emails userName displayName urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:employeeNumberSystem Role: Source | Identity Authentication (SCIM API version 1) |
scim.group.unique.attribute | If the service tries to create a group that already exists in the target system, the creation will fail. In this case, the existing group only needs to be updated. This group can be found via search, based on an attribute (default or specific). To make the search filter by a specific attribute, specify this attribute as a value for the scim.group.unique.attribute property. If the property is not specified, the search is done by the default attribute: displayName System Role: Target, Proxy | SCIM System SAP Analytics Cloud SAP Commissions SAP Jam Collaboration Identity Authentication (SCIM API version 1) Local Identity Directory Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) Sales Cloud – Analytics & AI SAP BTP Account Members (Neo) SAP Fieldglass |
scim.include.if.match.wildcard.header | Makes the connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by a SCIM system for entity versioning. Possible values:true falseDefault value: false System Role: Target, Proxy | SCIM System SAP Analytics Cloud SAP Commissions SAP Jam Collaboration Identity Authentication (SCIM API version 1) Local Identity Directory Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) Sales Cloud – Analytics & AI SAP BTP Account Members (Neo) SAP Fieldglass |
scim.support.patch.operation | If your target or proxy system is among the SCIM-based ones listed under System Type and supports PATCH operations, set this property to true. This way, when the Identity Provisioning identifies a changed entity in the source system, it will execute the updates as PATCH requests instead of PUT. That means, only the changes will be written in the target system, instead of provisioning the whole entity data. Note that only attributes without "scope" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with scope, such as: { "constant": "xsuaa-dummy-value", "targetPath": "$.id", "scope": "createEntity" } Additional Information: There are different cases when an entity should be updated in the target system:In the source system, some of the entity attributes have been changed, or new attributes have been added.In the source system, a condition or a filter is set for this entity not to be read anymore.The whole entity has been deleted from the source system.In the last two cases, it's possible to keep the entity in the target system – it will not be deleted but only disabled. To do this, use the deleteEntity scope in the transformation of your target or proxy system. See: Transformation Expressions → deleteEntity. Possible values: true false Default value: false System Role: Target, Proxy | SAP Jam Collaboration Local Identity Directory Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) |
scim.user.filter | When specified, only those users matching the filter expression will be read. Possible values: For example: name.familyName eq "SmithJ" and addresses.country eq "US" System Role: Source | SCIM System SAP Analytics Cloud SAP Commissions SAP Jam Collaboration Identity Authentication (SCIM API version 1) Local Identity Directory Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) Sales Cloud – Analytics & AI SAP BTP Account Members (Neo) SAP Fieldglass |
scim.user.unique.attribute | When the Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). If the service finds such a user on the target system via this filter, then the conflicting user will overwrite the existing one. If the service does not find such a user, the creation will fail. According to your use case and system type, choose how to set up this property:Default behavior: This property is missing during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such а userName is not found, the creation of the conflicting user fails. Note Relevant only for Identity Authentication and SAP Analytics Cloud: For systems created before April 7, 2020, this property is missing during system creation, and it has the default value, userName. If the service does not find an existing user with such a userName, it will try again to resolve the conflicting user – by email. If the second attempt for resolution is unsuccessful too, the creation of the conflicting user fails. For systems created after April 7, 2020, this property appears by default during system creation, and its value is set to userName. If the service does not find an existing user with such a userName, the creation of the conflicting user fails.However, if you delete the property, the service will try again to resolve the conflicting user – by email. If the second attempt for resolution is unsuccessful too, the creation of the conflicting user fails.Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = userName,emails[0].value. If the service finds an existing user with both these userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Possible values:userName emails[0].value userName,emails[0].value externalId, or another SCIM attribute, or a conjunction of SCIM attributes Note phoneNumbers[0].value - supported unique attribute for Local Identity Directory (when Identity Provisioning is running on SAP Cloud Identity Infrastructure) Default value: userName System Role: Target | SCIM System SAP Analytics Cloud SAP Commissions SAP Jam Collaboration Identity Authentication (SCIM API version 1) Local Identity Directory Local Identity Directory (when Identity Provisioning is running on SAP Cloud Identity Infrastructure) Cloud Foundry UAA Server SAP BTP XS Advanced UAA (Cloud Foundry) Sales Cloud – Analytics & AI SAP BTP Account Members (Neo) SAP Fieldglass |
scp.group.prefix | This property distinguishes SAP BTP Account Members (Neo) groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: SCP_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP BTP Account Members (Neo) source system and will be provisioned to the target system with the following name pattern: SCP_<GroupDisplayName>. This way SAP BTP Account Members (Neo) groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP BTP Account Members (Neo) groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the SCP_ prefix in their display name will be provisioned to SAP BTP Account Members (Neo). Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be provisioned to SAP BTP Account Members (Neo).System Role: Source and Target | SAP BTP Account Members (Neo) |
scp.user.userbase | This property specifies the host to the identity provider to be used with this target system. All provisioned users can be authenticated only by this identity provider. If you use another IdP, enter its value as configured in the SAP BTP cockpit. For example: <account_ID>.accounts.ondemand.com Possible values: Default value: account.sap.com System Role: Target, Proxy | SAP BTP Account Members (Neo) |
SenderPartyID | Note Only relevant to API v.2. Enter the name of the sender system name. It's equal to the value of property RemoteSystemID from API v.1. Possible values: For example: IPS System Role: Target | SAP Sales Cloud and SAP Service Cloud |
sf.api.version | Handles the version of the API which is consumed by the SAP SuccessFactors system. Possible values:1 - When the value is set to 1, or the property is not defined - SAP SuccessFactors HCM Suite OData API (in short, OData API) is used. This is the default value. SAP SuccessFactors source systems created before the introduction of sf.api.version property, use OData API.2 - When the value is set to 2 - SAP SuccessFactors Workforce SCIM API (in short, SCIM API) is used.Default value: 1 System Role: Source, Target, Proxy | SAP SuccessFactors version 1 (using SAP SuccessFactors HCM Suite OData API)SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.company.id | Enter the Company ID of your SAP SuccessFactors system. The Company ID is a short string of characters that identifies each SAP SuccessFactors system. It is like a username for your organization. All users of the same system share the same Company ID. This property must be configured if you what to use client certificate authentication for the communication between Identity Provisioning and SAP SuccessFactors. System Role: Source, Target, Proxy | SAP SuccessFactors version 1 (using SAP SuccessFactors HCM Suite OData API)SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.content.type | This property makes the SAP SuccessFactors connector to send a specified value for the Content-Type HTTP header. This is needed because SAP SuccessFactors could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json Default value: application/scim+json System Role: Target, Proxy | SAP SuccessFactors version 1 (using SAP SuccessFactors HCM Suite OData API) |
sf.group.filter | The possible values of this property depend on the API version which your SAP SuccessFactors system consumes. Use this property to filter dynamic groups from SAP SuccessFactors. The filter obtains values as described in the OData 2.0 syntax, except any statements with attribute lastModifiedDateTime. To learn more, see:OData version 2 → 4.5. Filter System Query Option ($filter) SAP SuccessFactors HCM Suite OData API → 6.3 DynamicGroup syntax, except anySAP SuccessFactors Workforce SCIM APIPossible values: If your system consumes SAP SuccessFactors Workforce SCIM API, you can filter groups only by displayName. For example: groupType eq 'permission' System Role: Source, Proxy | SAP SuccessFactors version 1 (using SAP SuccessFactors HCM Suite OData API)SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.group.members.paging.enabled | This property enables paging of group members. The maximum number of group members returned per request is 100. To read more than 100 group members, paging must be enabled. Possible values:true - Paging is enabled. false - Paging is disabled.Default value: false System Role: Source, Proxy | SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.group.unique.attribute | If the service tries to create a group that already exists in the target system, the creation will fail. In this case, the existing group only needs to be updated. This group can be found via search, based on an attribute (default or specific). To make the search filter by a specific attribute, specify this attribute as a value for the sf.group.unique.attribute property. If the property is not specified, the search is done by the default attribute: displayName System Role: Target, Proxy | SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.include.if.match.wildcard.header | Makes the connector send the If-Match HTTP header with a value of “*” for every request to the target system. This header could be used by a SCIM system for entity versioning. Possible values:truefalseSystem Role: Target, Proxy | SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.page.size | Use this property to configure the paging. That means, the number of entities to be read from SAP SuccessFactors at once. Default value: 100 System Role: Source, Proxy | SAP SuccessFactors version 1 (using SAP SuccessFactors HCM Suite OData API) |
sf.patch.group.members.above.threshold | Defines the threshold number of group members above which they are provisioned on batches with PATCH requests, and below which they are provisioned with PUT request. Setting this property allows you to avoid timeouts when updating groups with a large number of group members. Note You can use this property when SAP SuccessFactors is based on SAP SuccessFactors Workforce SCIM API (in short, SCIM API).Default value: 20 000 Maximum value: 200 000For example:PATCH requests: If you have a group with 700 members and you update the group by adding another 1200 members, setting this property to 900 results in the following: As 1900 (the target count of the members) is above the threshold number of 900, 2 PATCH requests will be sent to the Local Identity Directory target system. The first request will add 900 group members and the second request will add 300 group members. The threshold number you set defines the maximum number of group members processed per batch.PUT request: If you have a group with 700 members and you update the group by adding another 100 members, setting this property to 900 results in the following: As 800 (the target count of the members) is below the threshold number of 900, 1 PUT request with 800 group members will be sent to the Local Identity Directory target system to update the group. System Role: Target | SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.patch.group.members.of.nested.groups | If you set this property to true, Identity Provisioning will update only user members of a group in SAP SuccessFactors target system. The update will be executed on batches via PATCH requests. This will preserve the group hierarchy with nested groups in the SAP SuccessFactors backend. Possible values: true falseDefault value: falseSystem Role: Target | SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.support.patch.operation | This property controls how modified users in the source system are updated in the target system.If set to true, Identity Provisioning sends a PATCH request to the user or group resource in the target system. Only attributes without "scope": "createEntity" in the attribute mappings in the write transformation will be updated. For example, if the last name of a user is changed in the source system, the patch operation will update it in the target system and will leave unchanged other attributes with explicitly set "scope": "createEntity".If set to false, PUT operations are used to update users in the target system. This means, for example, that if a user attribute is modified, all user attributes are replaced in the target system, instead of updating only the modified ones.Users can be updated in the target system in various cases, such as:In the source system, some user attributes are modified, or new attributes are added. In the source system, a condition or a filter is set for users not to be read anymore. A user is deleted from the source system. In the last two cases, it's possible to keep the entity in the target system – it will not be deleted but only disabled. To do this, use the deleteEntity scope in the transformation of your target or proxy system. See: Transformation Expressions → deleteEntity. Possible values: true false Default value: false System Role: Target | SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.user.attributes | The value of this property is a comma-separated list of user attributes that have to be loaded from/to the SAP SuccessFactors system.Possible values: Default value: userId,username,status,email,lastName,firstName,lastModifiedDateTime,personKeyNav SAP SuccessFactors supports a huge amount of user information, which requires a lot of memory processing time and may even lead to time-out errors. That's why we recommend that you keep the default list of attributes, or specify only a few (the most significant attributes) for your provisioning scenario. Note If you want to add more attributes, make sure you have added: the relevant extra attributes to the value of this property, separated by commas extra mappings for these attributes in the user transformation extra mappings for these attributes in the write transformation of the relevant target systemRemember Always make sure that attribute lastModifiedDateTime is in the list. If you don't specify it, the provisioning from/to SAP SuccessFactors will fail.System Role: Source, Target, Proxy | SAP SuccessFactors version 1 (using SAP SuccessFactors HCM Suite OData API) |
sf.user.attributes.expand | This property reads/writes additional user data related to complex (navigation) attributes, which are specified in the sf.user.attributes property. Possible values: Default value: personKeyNav,personKeyNav/userAccountNav For example: If you also need to read the username of the manager of a company employee, enter the following configuration in the Properties tab: sf.user.attributes = username,firstName,lastName,manager/usernamesf.user.attributes.expand = personKeyNav,personKeyNav/userAccountNav,managerSystem Role: Source, Target, Proxy | SAP SuccessFactors version 1 (using SAP SuccessFactors HCM Suite OData API) |
sf.user.filter | The possible values of this property depend on the API version which your SAP SuccessFactors system consumes. This property takes values as described in the OData version 2lastModifiedDateTime. Caution Attribute lastModifiedDateTime is used internally by the Identity Provisioning service, for calculating the delta load from the SAP SuccessFactors system. You must not use it in your filter statements. If you do, your provisioning jobs will fail.Tip By default, only active users are read from SAP SuccessFactors. If you want to filter by another user status, you can set it in the value of this property, using either the status value or the status text parameters. See: SAP SuccessFactors HCM Suite OData API → 5.14.10.1 Querying Different Types of UsersPossible values: For example: division eq 'Manufacturing (MANU)' Note You can only use attributes supported as filterable by the SAP SuccessFactors HCM Suite OData API. Some of these filterable attributes are: firstName, lastName, department, division, jobCode, location, status, userId, username.If your system consumes SAP SuccessFactors Workforce SCIM API, you can filter users by userName. For example: userName eq "Sebastian" See : SAP SuccessFactors Workforce SCIM API System Role: Source, Proxy | SAP SuccessFactors version 1 (using SAP SuccessFactors HCM Suite OData API)SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
sf.user.unique.attribute | When the Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). If the service finds such a user on the target system via this filter, then the conflicting user will overwrite the existing one. If the service does not find such a user, the creation will fail. According to your use case and system type, choose how to set up this property:Default behavior: This property is missing during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such а userName is not found, the creation of the conflicting user fails. Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = userName,emails[0].value. If the service finds an existing user with both these userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Possible values:userName emails[0].value userName,emails[0].value externalId, or another SCIM attribute, or a conjunction of SCIM attributesDefault value: userName System Role: Target | SAP SuccessFactors version 2 (using SAP SuccessFactors Workforce SCIM API) |
ssh.auth.type | Supported SSH authentication types: key pwd otp key+otp key+pwd pwd+otp key+pwd+otp System Role: Source, Target | SSH Server (Beta) |
ssh.create.group.command | Path to the bash command you need to execute to create a group. System Role: Source, Target | SSH Server (Beta) |
ssh.create.group.command.exit.code.already.exists | An exit code number System Role: Source, Target | SSH Server (Beta) |
ssh.create.user.command | Path to the bash command you need to execute to create a user. System Role: Source, Target | SSH Server (Beta) |
ssh.create.user.command.exit.code.already.exists | An exit code number System Role: Source, Target | SSH Server (Beta) |
ssh.delete.group.command | Path to the bash command you need to execute to delete a group. System Role: Source, Target | SSH Server (Beta) |
ssh.delete.group.command.exit.code.not.found | An exit code number System Role: Source, Target | SSH Server (Beta) |
ssh.delete.user.command | Path to the bash command you need to execute to delete a user. System Role: Source, Target | SSH Server (Beta) |
ssh.delete.user.command.exit.code.not.found | An exit code number System Role: Source, Target | SSH Server (Beta) |
ssh.host | System Role: Source, Target | SSH Server (Beta) |
ssh.password | (Credential) Taken into account only if the authentication type includes pwd. That means any of the following:hana.jdbc.ssh.tunnel.auth.type f = pwd hana.jdbc.ssh.tunnel.auth.type = pwd+otp hana.jdbc.ssh.tunnel.auth.type = key+pwd hana.jdbc.ssh.tunnel.auth.type = key+pwd+otpSystem Role: Source, Target | SSH Server (Beta) |
ssh.port | Possible values: 22 System Role: Source, Target | SSH Server (Beta) |
ssh.private.key | (Credential) Taken into account only if the authentication type includes key. That means any of the following:hana.jdbc.ssh.tunnel.auth.type = key hana.jdbc.ssh.tunnel.auth.type = key+pwd hana.jdbc.ssh.tunnel.auth.type = key+otp hana.jdbc.ssh.tunnel.auth.type = key+pwd+otpSystem Role: Source, Target | SSH Server (Beta) |
ssh.private.key.type | The format of SSH private key. Possible values:ssh-rsa ssh-dsaDefault value: ssh-rsa System Role: Source, Target | SSH Server (Beta) |
ssh.read.groups.command | Path to the bash command you need to execute to read groups. System Role: Source | SSH Server (Beta) |
ssh.read.users.command | Path to the bash command you need to execute to read users. System Role: Source | SSH Server (Beta) |
ssh.totp.secret.key | (Credential) Taken into account only if the authentication type includes otp. That means any of the following:hana.jdbc.ssh.tunnel.auth.type = otp hana.jdbc.ssh.tunnel.auth.type = key+otp hana.jdbc.ssh.tunnel.auth.type = pwd+otp hana.jdbc.ssh.tunnel.auth.type = key+pwd+otpSystem Role: Source, Target | SSH Server (Beta) |
ssh.update.group.command | Path to the bash command you need to execute to update a group. System Role: Source, Target | SSH Server (Beta) |
ssh.update.group.command.exit.code.not.found | An exit code number System Role: Source, Target | SSH Server (Beta) |
ssh.update.user.command | Path to the bash command you need to execute to update a user. System Role: Source, Target | SSH Server (Beta) |
ssh.update.user.command.exit.code.not.found | An exit code number System Role: Source, Target | SSH Server (Beta) |
ssh.username | System Role: Source, Target | SSH Server (Beta) |
TrustAll | Use this property when you create a connectivity destination in SAP BTP cockpit with authentication type BasicAuthentication to configure your provisioning system. Use cases:If this property is not specified or set to false, you need to add a truststore certificate to check for SSL connections. You can either use the default JDK truststore, or provide a custom truststore certificate – if you use a custom domain instead of the default Identity Authentication one. For more information, see: Use Destination Certificates (Cockpit) Use Custom Domain in Identity AuthenticationIf the property is enabled (set to true), the server certificate will be ignored, thus – not checked for SSL connections.Remember For productive scenarios, we recommend that you do not use this property (or set it to false) because the SSL server certificate cannot be verified, and thus the server is not authenticated. Enable the property only for testing purposes.Possible values: true false Default value: false System Role: Source, Target, Proxy | All systems |
Type | Protocol type for making a connection Possible values:HTTP LDAP RFCSystem Role: Source, Target, Proxy | All systems |
uaa.origin | It denotes the origin attribute in the system transformation. The value of this property is the location of your Cloud Foundry identity provider. If not sure about the value, ask your Cloud Foundry system administrator. Possible values: Text/numeric string System Role: Source, Target, Proxy | Cloud Foundry UAA Server |
uaa.origin.filter.enabled | This flag property depends on uaa.origin. If the flag is set to true, the Identity Provisioning service will read only users whose identity provider is set as a value of uaa.origin. Possible values: true or falseIf set to true, the Identity Provisioning service will read only users whose identity provider is set as a value of uaa.origin. If set to false, the Identity Provisioning service will read all users, regardless of their origin. If set to true but the uaa.origin property is missing, the provisioning job will fail.System Role: Source, Proxy | Cloud Foundry UAA Server |
uaa.patch.response.with.resource | Use this property if you want to retrieve a group whose membership was modified. Note This property is usable only when you have configured membership modifications via Add/Remove Member UAA endpoints. That is, when the scim.support.patch.operation property is set to false. Possible values:true – the Identity Provisioning service will return the modified group via the GET /Groups endpoint of UAA. To learn how, see Retrieve. false – no modified groups will be returned by the service.System Role: Proxy | Cloud Foundry UAA Server |
URL | URL needed to make an HTTP(S) connection to an on-premise system or a cloud service Possible value: http(s)://<host>.<port> System Role: Source, Target, Proxy | All HTTP systems |
User | It represents: User name – used in standard destinations Client ID – used for access token retrieval in OAuth HTTP destinations Possible values: Text/numeric string System Role: Source, Target, Proxy | All HTTP systems |
workzone.content.type | This property makes a SAP Build Work Zone, advanced edition connector to send a specified value for the Content-Type HTTP header. This is needed because SAP Build Work Zone, advanced edition could potentially not implement the protocol in the specification, which states that a system must accept application/scim+json as a value of the Content-Type header. Possible values: For example: application/json Default value: application/scim+json System Role: Target, Proxy | SAP Build Work Zone, advanced edition |
workzone.group.filter | When specified, only those SAP Build Work Zone, advanced edition groups matching the filter expression will be read. Possible values: For example: displayName eq "ProjectTeam1" System Role: Source | SAP Build Work Zone, advanced edition |
workzone.group.unique.attribute | If the Identity Provisioning tries to create a group that already exists on the SAP Build Work Zone, advanced edition target system, the creation will fail. In this case, the existing group only needs to be updated. This group can be found via search, based on an attribute (default or specific). To make the search filter by a specific attribute, specify this attribute as a value for this property. Possible values: Default value (when not specified): displayName If the property is not specified, the search is done by the default attribute: displayName System Role: Target, Proxy | SAP Build Work Zone, advanced edition |
workzone.support.patch.operation | The default value of this property is false. But for SAP Build Work Zone, advanced edition proxy systems, this property appears during creation and its predefined value is true. That means, when the Identity Provisioning identifies a changed entity in the back-end system, it will execute the updates as PATCH requests instead of PUT. That is, only changes will be written in SAP Build Work Zone, advanced edition, instead of provisioning the whole entity data. Additional Information: There are different cases when an entity should be updated in the target system:In the source system, some of the entity attributes have been changed, or new attributes have been added.In the source system, a condition or a filter is set for this entity not to be read anymore.The whole entity has been deleted from the source system.In the last two cases, it's possible to keep the entity in the target system – it will not be deleted but only disabled. To do this, use the deleteEntity scope in the transformation of your target or proxy system. See: Transformation Expressions → deleteEntity. Possible values: true false Default value for proxy systems: true Default value for target systems: false System Role: Target, Proxy | SAP Build Work Zone, advanced edition |
workzone.user.filter | When specified, only those SAP Build Work Zone, advanced edition users matching the filter expression will be read. Possible values: For example: userName eq "SmithJ" System Role: Source | SAP Build Work Zone, advanced edition |
workzone.user.unique.attribute | When the Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists in SAP Build Work Zone, advanced edition. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). According to your use case, choose how to set up this property:Default behavior: This property is missing during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such а userName is not found, the creation of the conflicting user fails. Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Value = userName,emails[0].value. If the service finds an existing user with both these userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Possible values:userName emails[0].value userName,emails[0].value externalId, or another SCIM attribute, or a conjunction of SCIM attributesDefault value: userName System Role: Target, Proxy | SAP Build Work Zone, advanced edition |
X-ConsumerKey | Enter the Concur access token needed for the connection. System Role: Target, Proxy | SAP Concur |
xsuaa.group.prefix | This property distinguishes SAP BTP XS Advanced UAA (Cloud Foundry) groups by specific prefix. It is an optional property which does not appear by default at system creation. Example value: XSUAA_ You can use the example value or provide your own.When set in the source system, the prefix will be prepended to the name of the groups that are read from the SAP BTP XS Advanced UAA (Cloud Foundry) source system and will be provisioned to the target system with the following name pattern: XSUAA_<GroupDisplayName>. This way SAP BTP XS Advanced UAA (Cloud Foundry) groups in the target system will be distinguished from groups provisioned from other applications. If the property is not set, the SAP BTP XS Advanced UAA (Cloud Foundry) groups will be read and provisioned to the target system with their actual display names.When set in the target system, only groups containing the XSUAA_ prefix in their display name will be provisioned to SAP BTP XS Advanced UAA (Cloud Foundry). Groups without this prefix in the display name won't be provisioned. If the property is not set, all groups will be be provisioned to SAP BTP XS Advanced UAA (Cloud Foundry).System Role: Source and Target | SAP BTP XS Advanced UAA (Cloud Foundry) |
xsuaa.origin | It denotes the origin attribute in the system transformation. The value of this property is the location of your identity provider. You can find it in the cockpit – go to your Cloud Foundry subaccount, choose Trust Configuration and see the value under Origin Key. Possible values: Text/numeric string For example: myaccount-xsuaa.accounts.ondemand.com System Role: Source, Target, Proxy | SAP BTP XS Advanced UAA (Cloud Foundry) |
xsuaa.origin.filter.enabled | This flag property depends on xsuaa.origin. If the flag is set to true, the Identity Provisioning service will read only users whose identity provider is set as a value of xsuaa.origin. Possible values: true or falseIf set to true, the Identity Provisioning service will read only users whose identity provider is set as a value of xsuaa.origin. If set to false, the Identity Provisioning service will read all users, regardless of their origin. If set to true but the xsuaa.origin property is missing, the provisioning job will fail.System Role: Source, Proxy | SAP BTP XS Advanced UAA (Cloud Foundry) |
xsuaa.patch.group.members.above.threshold | Defines the threshold number of group members above which they are provisioned on batches with PATCH requests, and below which they are provisioned with PUT request. Setting this property allows you to avoid timeouts when updating groups with a large number of group members. Possible values: integer For example:PATCH requests: If you have a group with 700 members and you update the group by adding another 1200 members, setting this property to 900 results in the following: As 1900 (the target count of the members) is above the threshold number of 900, 2 PATCH requests will be sent to the XSUAA target system. The first request will add 900 group members and the second request will add 300 group members. The threshold number you set defines the maximum number of group members processed per batch.PUT request: If you have a group with 700 members and you update the group by adding another 100 members, setting this property to 900 results in the following: As 800 (the target count of the members) is below the threshold number of 900, 1 PUT request with 800 group members will be sent to the XSUAA target system to update the group.System Role: Target | SAP BTP XS Advanced UAA (Cloud Foundry) |
xsuaa.patch.response.with.resource | Use this property if you want to retrieve a group whose membership was modified. Note This property is usable only when you have configured membership modifications via Add/Remove Member UAA endpoints. That is, when the scim.support.patch.operation property is set to false. Possible values:true – the Identity Provisioning service will return the modified group via the GET /Groups endpoint of UAA. To learn how, see Retrieve. false – no modified groups will be returned by the service.System Role: Proxy | SAP BTP XS Advanced UAA (Cloud Foundry) |
xsuaa.user.unique.attribute | When Identity Provisioning attempts to provision a user for the first time, it may detect that such a user already exists on the target system. Thus, the service needs to retrieve the entityId of the existing user via filtering by user unique attribute(s). This property defines by which unique attribute(s) the existing user to be searched (resolved). If the service finds such a user on the target system via this filter, then the conflicting user will overwrite the existing one. If the service does not find such a user, the creation will fail. According to your use case, choose how to set up this property:Default behavior: This property is missing during system creation. Its default value is userName. That means, if the service finds an existing user by a userName, it updates this user with the data of the conflicting one. If a user with such а userName is not found, the creation of the conflicting user fails.Value = emails[0].value. If the service finds an existing user with such email, it updates this user with the data of the conflicting one. If a user with such email is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Value = userName,emails[0].value. If the service finds an existing user with both attributes: userName and email, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails.Value = userName,origin. If the service finds an existing user with both attributes: userName and origin, it updates this user with the data of the conflicting one. If such a user is not found, that means the conflict is due to another reason, so the creation of the conflicting user fails. Possible values: userName emails[0].value userName,emails[0].value userName,origin externalId, or another SCIM attribute, or a conjunction of SCIM attributes Default value: userName System Role: Target | SAP BTP XS Advanced UAA (Cloud Foundry) |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
30 | |
16 | |
8 | |
8 | |
8 | |
7 | |
7 | |
6 | |
6 | |
5 |