2 Creating an Application By Using the Generic REST Connector
Learn about onboarding applications using the connector.
You can onboard an application for your target system into Oracle Identity Governance from the connector package by creating a Target application or an Authoritative application. To do so, you must log in to Identity Self Service and then choose the Applications box on the Manage tab.
2.1 Prerequisites for Creating an Application
Learn about process flow for onboarding applications using the connector and the prerequisites for doing so.
2.1.1 Process Flow for Creating an Application By Using the Connector
From Oracle Identity Governance release 12.2.1.3.0 onward, connector deployment is handled using the application onboarding capability of Identity Self Service.
Figure 2-1 is a flowchart depicting high-level steps for creating an application in Oracle Identity Governance by using the connector installation package.
Figure 2-1 Overall Flow of the Process for Creating an Application By Using the Connector
2.2 Navigating to the Create Application Screen
To navigate to the Create Application screen, you must log in to Identity Self Service and then choose the Applications box on the Manage tab.
- Log in to Identity Self Service either by using the System Administration account or an account with the ApplicationInstanceAdministrator admin role.
- On the Applications page, click the Create menu on the toolbar, and then select one of the following options:
- Target - to create a Target application.
- Authoritative - to create an Authoritative application.
2.3 Understanding and Updating the Basic Information
Learn about the configuration-related details that you must enter on the Basic Information page. The connector uses these details to establish a connection with the target system and while performing reconciliation or provisioning operations.
Creating an application (whether Target or Authoritative) involves providing relevant details of the application such as connectivity information, schema details, and so on. On the Basic Information page, you provide various details of application that you wish to onboard. For example, you select the connector bundle, enter the name of the application to be created, and enter connection-related parameters that the connector uses to connect Oracle Identity Governance with your target system and perform connector operations.
This following topic discuss parameters on the various sections of the Basic Information page in detail and the process for specifying values for these parameters:
2.3.1 Basic Configuration Parameters
These are the connection-related parameters that Oracle Identity Governance requires to connect to the REST-based target system.
Table 2-1 Basic Configuration Parameters
| Parameter | Mandatory? | Description |
|---|---|---|
|
authenticationType |
Yes |
Enter the type of authentication used by your target system. The following are the possible values for this parameter:
Default value: Note: If you are using a value other than the default value, client_credentials, then ensure to add the parameters corresponding to the authentication type that your target system is using. |
|
host |
Yes |
Host name or IP address of the computer hosting the target system. Sample value: |
|
port |
Yes |
Port number at which the target system is listening. Sample value: |
|
authenticationServerUrl |
No |
Enter the URL of the authorization server that authenticates the client (by validating the client ID and client secret), and if valid, issues an access token. Sample value: |
|
clientId |
No |
Enter the client identifier (a unique string) issued by the authorization server to the client during the registration process. Sample value: |
|
clientSecret |
No |
Enter the value used to authenticate the identity of your client application. Sample value: |
|
Connector Server Name |
No |
If you have deployed the Generic REST connector in the Connector Server, then enter the name of the IT resource for the Connector Server. |
|
proxyHost |
No |
Name of the proxy host used to connect to an external target system. Sample value: |
|
proxyPort |
No |
Proxy port number Sample value: |
|
proxyUser |
No |
Proxy user name of the target system user account that Oracle Identity Manager uses to connect to the target system. |
|
proxyScheme |
No |
|
|
proxyPassword |
No |
Password of the proxy user ID of the target system user account that Oracle Identity Governance uses to connect to the target system. |
|
sslEnabled |
No |
If the target system requires SSL connectivity, then set the value of this parameter
to Default value: |
|
uriPlaceHolder |
No |
Enter the key-value pair for replacing place holders in the relURIs. The URI place holder consists of values which are repeated in every relative URL. Values must be comma separated. For example, tenant ID and API version values are a part of every request URL. Therefore, we replace it with a key-value pair. Sample value: |
2.3.2 Advanced Settings Parameters
These are the configuration-related entries that the connector uses during reconciliation and provisioning operations.
Table 2-2 Advanced Settings Parameters
| Parameter | Mandatory? | Description |
|---|---|---|
|
Bundle Name |
Yes |
This parameter holds the name of the connector class. Default value: |
|
Bundle Version |
Yes |
This parameter holds the version of the connector bundle class. Default value: |
|
Connector Name |
Yes |
This parameter holds the name of the connector bundle package. Default value: |
|
relURIs |
Yes |
Enter the relative URLs for all operations of each object class. Enter a value for this parameter in one of the following formats:
Sample value:
Note: Depending on the target system, you can perform pagination by using either offset value or page count. Below are sample values for both options.
To support pagination using page size we have introduced one
configurable attribute page increment as same as page offset. It
should we specified in rel URI as
Page increment attribute count starts from 1 and increment by one
till it reaches last page. For example, Since PAGE_SIZE is a configurable parameter, let’s consider it to be 100. Then the request URI looks as below:
Here every page has 100 users and it continues to bring the data till the last page. If the target system has 1000 accounts, then 10 calls will be triggered. To support pagination using OFFSET Is configurable attribute page
offset. It should we specified in rel URI as
Page offset attribute count starts from 0 and increment by page size
till it reaches last page. For example,
Since PAGE_SIZE is a configurable parameter, let’s consider it to be 100. Then the request URI looks as below:
Here every page has 100 users and it continues to bring the data till the last page. If the target system has 1000 accounts, then 10 calls will be triggered. |
|
opTypes |
No |
Enter the HTTP operation type for each object class that is to be managed by the connector. Values must be comma separated and in the following format: In this format, OBJ_CLASS is the connector object class, OPERATION is the connector operation (for example, CreateOp, UpdateOp, or SearchOp), and HTTP_OPERATION is the HTTP operation (for example, GET, PUT, or POST). Sample value: |
|
nameAttributes |
Yes |
Enter the name attribute for all object classes that are handled by the connector. This value specifies the mapping between the _NAME_ connector attribute and the corresponding target system attribute for each object class that the connector handles. Format: Sample value: Note: All values in this parameter must be comma separated. |
|
uidAttributes |
Yes |
Enter the __UID__ attribute for each object class that the connector handles. A __UID__ attribute is a target system attribute that uniquely identifies an account in the target system. This target system attribute name must be unique and need not be autogenerated. Format: Sample value: In this format, OBJ_CLASS is the connector object class and ATTR_NAME is the name of the attribute that uniquely identifies an account in the target system. Note: All values in this parameter must be comma separated. |
|
statusAttributes |
No |
Enter the name of the target system attribute that holds the status for each object class this connector handles. Format: Sample value: Note: All values in this parameter must be comma separated. |
|
passwordAttribute |
No |
Enter the name of the target system attribute that is mapped to the __PASSWORD__ attribute of the connector in OIM. |
|
pageSize |
No |
The number of resources/users that appears on a page for a search operation. Deafult value: 100 |
|
pageTokenAttribute |
No |
The attribute in response payload that denotes the next page token. Deafult value:
|
|
pageTokenRegex |
No |
This attribute is used in the URL while reconciliation to support pagination. Deafult value: |
|
Any Incremental Recon Attribute Type |
No |
By default, during incremental reconciliation, Oracle Identity Governance accepts
timestamp information sent from the target system only in Long
datatype format. Setting the value of this parameter to
Deafult value: |
|
jsonResourcesTag |
Yes, if you are implementing custom parsers |
Enter the JSON tag value that is used for parsing a response payload. The connector will consider the value that you enter in this parameter as an unwanted outer tag while parsing responses. You can skip entering a value for this parameter if there is no unwanted outer tag in your response payload. Enter a value for this parameter in the following format: OBJ_CLASS=OUTER_ATTR_NAME In this format, OBJ_CLASS is the name of the object class for which a response payload is being parsed. OUTER_ATTR_NAME is the name of the outer tag in the response payload. For example, consider the following JSON value for a User object:Because the name of the object class for a User object is __ACCOUNT__, for the given example, the value of the jsonResourcesTag parameter is Note: You must enter a value for this parameter only if the data from your target system is in JSON format. For more than one JSON tag, the values must be comma separated. |
|
httpHeaderContentType |
Yes |
This parameter holds the content type expected by the target system in the header. Default value: |
|
httpHeaderAccept |
Yes |
This parameter holds the accept type expected by the target system in the header. Default value: |
|
specialAttributeTargetFormat |
No |
Enter the format in which a special attribute is present in the target system. Attributes in an object class that can be managed only through a separate rest endpoint rather than the same endpoint of the base object class are referred to as special attributes. Format: In this example, TARGET_FORMAT is the format in the format of the special attribute in the target system. For example, consider the following target endpoint value: In this example, the alias attribute is present as aliases.alias in the target system endpoint. Therefore, you must set the value of this parameter to Sample value: |
|
specialAttributeHandling |
No |
Enter the list of special attributes whose values must be sent to the target system in separate calls, one at a time. If you do not specify a value for this parameter, then the connector will send all values for a given special attribute in a single call. Format: Note: All values in this parameter must be comma separated. Sample value: |
|
customPayload |
No |
Enter a comma-separated list of request payload formats for target system attributes that do not adhere to the standard JSON format. Format: Note: If you must pass the unique ID or Name attribute of the user as part of
a custom payload, then represent it as Sample value: |
|
targetObjectIdentifier |
No |
Enter the name of the attribute used for identifying the required target object during reconciliation. Format: |
|
statusEnableValue |
No |
This entry holds the name attribute for all target values indicating
the status as |
|
statusDisableValue |
No |
This entry holds the name attribute for all target values indicating
the status as |
2.3.3 Authentication Parameters
Authentication parameters are used by the target system to authenticate an application. The set of parameters for which you must specify values depends on the value that you enter for the authenticationType parameter of the Basic Configuration section.
The authenticationType parameter holds the type of authentication used by your target system. The connector supports the following types of authentication:
-
HTTP Basic Authentication
-
OAuth 2.0 JWT
-
OAuth 2.0 Client Credentials
-
OAuth 2.0 Resource Owner Password
-
Manually input access token
If your target system uses an authentication type other than the ones listed above, then you must write your own implementation which requires development effort. By default, the UI includes parameters for the OAuth 2.0 Client Credentials authentication type. For any other authentication type, you must create and add the corresponding parameters in the Advanced Settings section.
The following are the possible values for the authenticationType parameter:
- For HTTP Basic Authentication: basic
- For OAuth 2.0 JWT: jwt
- For OAuth 2.0 Client Credentials: client_credentials
- For OAuth 2.0 Resource Owner Password: password
- For manual input of access token: other
- For custom authentication implementation: custom
Note:
This section provides information about parameters for all authentication types. Enter values only for parameters corresponding to the authentication type you specify.HTTP Basic Authentication
Table 2-3 HTTP Basic Authentication Parameters
| Parameter | Description |
|---|---|
|
username |
Enter the user name or user ID of the account that Oracle Identity Governance must use to connect to and access the target system during reconciliation and provisioning operations. Sample value: |
|
password |
Enter the password of the account that Oracle Identity Governance must use to connect to and access the target system during reconciliation and provisioning operations. Sample value: |
OAuth 2.0 JWT
Table 2-4 OAuth 2.0 JWT Parameters
| Parameter | Description |
|---|---|
|
aud |
Enter the intended audience of the JWT. The value can either be a URI or token endpoint URL of the authorization server. Sample value: |
|
iss |
Enter a value that uniquely identifies the entity that issued the JWT. Sample value: |
|
scope |
Enter the scope of the access token being issued. Sample value: |
|
sub |
Enter a value that identifies the principal to which the JWT is being issued. Sample value: |
|
privateKeyLocation |
Enter the absolute path to the private key used to sign the access token. Sample value: |
|
privateKeySecret |
Enter the secret key for the private key that is being used to sign the access token. |
|
tokenLifespan |
Enter the life span of the access token in milliseconds. Sample value: |
|
signatureAlgorithm |
Enter the algorithm used for signing the access token. Sample value: |
|
privateKeyFormat |
Enter the format of the private key used to sign the access token. Sample value: |
OAuth 2.0 Client Credentials
Note:
B default, these parameters are available in the Basic Configuration section. Therefore, there is no need to add them manually.Table 2-5 OAuth2.0 Client Credentials Parameters
| Parameter | Description |
|---|---|
|
clientId |
Enter the client identifier (a unique string) issued by the authorization server to the client during the registration process. Sample value: |
|
clientSecret |
Enter the value used to authenticate the identity of your client application. Sample value: |
|
authenticationServerURL |
Enter the URL of the authorization server that authenticates the client (by validating the client ID and client secret), and if valid, issues an access token. Sample value: |
OAuth 2.0 Resource Owner Password
Table 2-6 OAuth 2.0 Resource Owner Password Parameters
| Parameter | Description |
|---|---|
|
username |
Enter the user name or user ID of the resource owner. Sample value: |
|
password |
Enter the password of the resource owner. Sample value: |
|
clientId |
Enter the client identifier issued to the client during the registration process. Sample value: Note: This is an optional parameter. |
|
clientSecret |
Enter the client secret used to authenticate the identity of the client application. Sample value: Note: This is an optional parameter. |
|
authenticationServerUrl |
Enter the URL of the authorization server (token endpoint) that authenticates the client (by validating client ID and client secret) and the resource owner credentials, if valid, issues an access token. Sample value: |
Manual Input of Access Tokens
This section discusses the parameter for which you must enter a value when the authenticationType parameter is set to other.
In this authentication mechanism, the connector expects the value of the access
token to be directly passed through the customAuthHeaders
parameter. The customAuthHeaders parameter must hold the access
token value that must be passed through an HTTP authorization header, for example,
access_token=<value>.
Custom Authentication
This section discusses the parameter for which you must enter a value when the authenticationType parameter is set to custom.
If you have implemented custom authentication, then you must enter a value for the
customAuthClassName parameter.
The customAuthClassName parameter
must hold the name of the class implementing the
custom authentication logic that you created while
performing the procedure described in Implementing Custom Authentication.
2.3.4 Providing Basic Information
You must provide configuration-related details on the Basic Information page. The connector uses these details while performing reconciliation.
- On the Basic Information page, ensure that the Connector Package option is selected.
- From the Select Bundle drop-down list, select Generic REST Connector 12.2.1.3.0.
- Enter the Application Name, Display Name, and Description for the application.
- In the Basic Configuration section, enter values for parameters as required. If you set the value of the
authenticationTypeparameter to a value other than the default value (client_credentials), then you must add and enter values for the corresponding authentication attributes in the Advanced Settings section. For example, if you set the value of theauthenticationTypeparameter to basic (for basic HTTP authentication), then this type of authentication requires a username and password. As there are no such attributes available in the UI, you must manually add them as follows: - In the Advanced Settings section, enter values for the parameters as required.
- Click Next to proceed to the Schema page.
See Also:
Authentication Parameters for the list of supported authentication types and their corresponding parameters2.4 Understanding and Updating the Schema Page
Use the Schema page to add or update attributes to help the connector understand the underlying structure of your target system.
2.4.1 Understanding the Schema Page for a Target Application
The Schema page for a Target application displays the default schema that maps Oracle Identity Governance attributes with corresponding target system attributes. The connector uses these mappings during reconciliation and provisioning operations.
The table under the REST User section displays a basic set of user-specific attribute mappings between Oracle Identity Governance and the target system. The table also lists the data type for a given attribute and specifies whether it is mandatory for reconciliation and whether it is a matching key field for fetching records during reconciliation. By default, the Schema page displays mappings for the __UID__, __NAME__, and __ENABLE__ connector attributes with the corresponding Oracle Identity Governance attributes. If required, you can edit the default attribute mappings.
The Schema page also provides a child form for the Group object class by default. Similar to the table in the REST User section, you can use this table to specify Group attribute mappings, data type for a given attribute, whether it is a key field for reconciliation, and so on. You can
As the connector is unaware of the target system schema, you must manually add and map your target system attributes with corresponding Oracle Identity Governance attributes. as described in Creating a Target Application of Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.
2.4.2 Understanding the Schema Page for an Authoritative Application
The Schema page for an Authoritative application displays the default schema that maps Oracle Identity Governance attributes with corresponding target system attributes. The connector uses these mappings during reconciliation runs.
The table under the REST Trusted section displays a basic set of user-specific attribute mappings between Oracle Identity Governance and the target system. The table also lists the data type for a given attribute and specifies whether it is mandatory for reconciliation and whether it is a matching key field for fetching records during reconciliation. By default, the Schema page displays mappings for the __UID__, __NAME__, and __ENABLE__ connector attributes with the corresponding Oracle Identity Governance attributes. If required, you can edit the default attribute mappings.
The schema page lists the default set of user-specific attribute mappings between the reconciliation fields in Oracle Identity Governance and target system attributes. The table also lists the data type for a given attribute and specifies whether it is a mandatory attribute for reconciliation.
If required, you can edit these attributes mappings by adding new attributes or deleting existing attributes on the Schema page as described in Creating an Authoritative Application in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.
The Organization Name, Xellerate Type, and Role identity attributes are mandatory fields on the OIG User form that cannot be left blank during reconciliation. As your target system might not contain corresponding attributes for the Organization Name, Xellerate Type, and Role identity attributes, they have been mapped to attributes in Oracle identity Governance. In addition, the connector provides default values (as listed in the “Default Value for Identity Display Name” column of Table 2-7) that it can use during reconciliation. For example, the default target attribute value for the Organization Name attribute is Xellerate Users. This implies that the connector reconciles all target system user accounts into the Xellerate Users organization in Oracle Identity Governance. Similarly, the default attribute value for Xellerate Type attribute is End-User, which implies that all reconciled user records are marked as end users.
Table 2-7 REST Trusted User Account Schema Attributes for an Authoritative Application
| Identity Display Name | Target Attribute | Data Type | Mandatory Reconciliation Property? | Recon Field? | Default Value for Identity Display Name |
|---|---|---|---|---|---|
|
User Login |
__NAME__ |
String |
No |
Yes |
NA |
|
REST User GUID |
__UID__ |
String |
No |
Yes |
NA |
|
Status |
__ENABLE__ |
String |
No |
Yes |
NA |
|
Last Name |
String |
No |
Yes |
NA |
|
|
Xellerate Type |
String |
No |
Yes |
End-User |
|
|
Role |
String |
No |
Yes |
Full-Time |
|
|
Organization Name |
String |
No |
Yes |
Xellerate Users |
The following is EloquaAppsUserSchema.properties, a sample schema file propery used in the Eloqua target system:
#Schema file for Eloqua
#List of fields
FieldNames=id,login,name,firstName,Active,lastName,senderDisplayName,emailAddress
#Unique ID Attribute
UidAttribute=id
#Account Name attribute
NameAttribute=login
#Account Status Attribute and Mapping
StatusAttribute=Active
Active.True=Enabled
Active.False=DisabledThe following is GenericRestConfiguration.groovy, a sample groovy file:
/*
* Run like:
* In Windows: GenericRestGenerator.cmd ..\resources\GenericRestConfiguration.groovy trusted
* In Linux/Unix: sh GenericRestGenerator.sh ../resources/GenericRestConfiguration.groovy trusted
*/
trusted {
/*
* ITResource name
*/
itResourceDefName='resttrust2' // This will be used as a base name for all metadata across the connector
// itResourceName="$itResourceDefName" //the same as itResourceDefName by default
/*
* Output files
*/
// connectorDir="../$itResourceDefName" // output dir of the connector, is the same as it resource name by default
// xmlFile='GenericRest-ConnectorConfig.xml' // name of the dm xml of the connector
// configFile='GenericRest-CI.xml' // name of the config xml
// propertiesFile='GenericRest-generator.properties' // name of the resources/properties file
// version='11.1.1.6.0' // connector version
/*
* Trusted/Target mode
* For trusted, we will not create forms, dataobjects and event handlers
* For target, we will create all above metadata
*/
trusted=true // Flag to denote if the mode is trusted or not
/*
* Location of the generic rest bundle jar
*/
bundleJar='../lib/org.identityconnectors.genericrest-12.3.0.jar'
/*
* The Configuration used to run the generic rest bundle mentioned above, get the schema from below mentioned schemaFile, which is required for generating metadata
*/
config = [
'schemaFile' : '../schema/EloquaAppsUserSchema.properties',
'authenticationType' : '',
'username' : '',
'password' : '',
'host' : '',
'port' : '',
'proxyHost' : '',
'proxyPort' : '',
'proxyUser' : '',
'proxyPassword' : '',
'sslEnabled' : '',
'relURIs' : '',
'nameAttributes' : '',
'uidAttributes' : '',
'opTypes' : '',
'jsonResourcesTag' : '',
'httpHeaderContentType' : '',
'httpHeaderAccept' : '',
'customPayload' : '',
'statusAttributes' : '',
'specialAttributeTargetFormat' : '',
'specialAttributeHandling' : '',
'statusEnableValue' : '',
'statusDisableValue' : '',
'passwordAttribute' : ''
]
/**
* Provide the attribute list that need to be handled as Date on process form
* Make sure these fields datatype in schema should be long
* dateAttributeList is not a mandatory field
**/
//dateAttributeList = ["JoiningDate"]
/**
* Alias are used to map the OIM User Form attributes with the Connector Attributes.
* The Format is of 'Connector Attribute':'OIM User Form Attribute'
* Mandatory alias shouldn't be removed. Customer can update these mandatory attributes but should not be removed
* Customer can add other aliases to the OIM User form fields
**/
// Mapping is mandatory for attributes User Login, Last Name,Organization, Xellerate Type and Role. One can modify the required mappings but shouldn't delete them.
//UID field is not required in trusted but if customer wanted to add UID field then one can map it to a valid OIM User Form Label
alias = ['__NAME__':'User Login', 'lastName':'Last Name','Organization':'Organization Name', 'Employee Type':'Xellerate Type', 'Role':'Role']
//Extend the aliases to include more connector attributes for trusted by mapping
alias += ['__ENABLE__':'Status', 'emailAddress':'Email']
}
/*
* Run like:
* In Windows: GenericRestGenerator.cmd ..\resources\GenericRestConfiguration.groovy target
* In Linux/Unix: sh GenericRestGenerator.sh ../resources/GenericRestConfiguration.groovy target
*/
target {
/*
* ITResource name
*/
itResourceDefName='restci2' // This will be used as a base name for all metadata across the connector
// itResourceName="$itResourceDefName" //the same as itResourceDefName by default
/**
* Give the name of the Application Instance that need to be generated. By default Application Instance name is taken as itResourceDefName
* Application Instance is not a mandatory field
**/
//applicationInstanceName="$itResourceDefName"
/*
* Output files
*/
// connectorDir="../$itResourceDefName" // output dir of the connector, is the same as it resource name by default
// xmlFile='GenericRest-ConnectorConfig.xml' // name of the dm xml of the connector
// configFile='GenericRest-CI.xml' // name of the config xml
// propertiesFile='GenericRest-generator.properties' // name of the resources/properties file
// version='11.1.1.6.0' // connector version
/*
* Location of the generic rest bundle jar
*/
bundleJar='../lib/org.identityconnectors.genericrest-12.3.0.jar'
/*
* The Configuration used to run the generic rest bundle mentioned above, and get the schema from the below mentioned schemaFile, which is required for generating metadata
*/
config = [
'schemaFile' : '../schema/GoogleAppsUserSchema.properties',
'authenticationType' : '',
'username' : '',
'password' : '',
'host' : '',
'port' : '',
'proxyHost' : '',
'proxyPort' : '',
'proxyUser' : '',
'proxyPassword' : '',
'sslEnabled' : '',
'relURIs' : '',
'nameAttributes' : '',
'uidAttributes' : '',
'opTypes' : '',
'jsonResourcesTag' : '',
'httpHeaderContentType' : '',
'httpHeaderAccept' : '',
'customPayload' : '',
'statusAttributes' : '',
'specialAttributeTargetFormat' : '',
'specialAttributeHandling' : '',
'statusEnableValue' : '',
'statusDisableValue' : '',
'passwordAttribute' : ''
]
/**
* Lookup List is the list of attributes for which we need to create lookups and map those fields as lookup in form.
* For Main Process Form Fields and a Multivalued field the format is
* lookupAttributeList=["FieldName"]
* For Embedded Multi Valued field the format is
* lookupAttributeList=["ObjectClassName.SubFieldName"]
* lookups will be generated with the FieldNames in format Lookup.${ITResource}.${FieldName}
*
* lookupList is not a mandatory field
*/
//lookupAttributeList=['Currency']
/* entitlementAttributeList is the list of fully Qualified field names to which entitlements need to be tagged.
* If you require entitlements for a multi valued attribute which is embedded then the format should be as
* entitlementAttributeList=["${ObjectClass}.SubFieldName"]
* If the attribute is just a MultiValued then the format is
* entitlementAttributeList=["MultiValuedFieldName"]
*
* entitlementAttributeList is not a mandatory attribute
*/
entitlementAttributeList=['__GROUPS__.id']
/**
* Provide the attribute list that need to be handled as Date on process form
* Make sure these fields datatype in schema should be long
* dateAttributeList is not a mandatory field
**/
//dateAttributeList = ["JoiningDate"]
/*
* Target attribute to user fields alias
*/
//Mandatory alias
alias = ['__UID__':'id', '__NAME__':'login']
//Optional aliases if any (Can also be used to give short names for lengthy attribute names)
//alias += ['Generic Rest Target':'GENREST', 'Family Name':'Last name']
/*
* Generate prepopulate adapters
*/
prepopulate = ['__UID__':'User Login']
}2.4.3 Updating the Schema Page
Update the Schema page to review and update the attribute mappings between Oracle Identity Governance and target system.
- On the Schema page, review the default mapping provided by the connector.
- If you are creating a Target application, then:
- If you are creating an Authoritative application, then for the Last Name attribute in the Identity Display Name column, enter the corresponding target system attribute name in the Target Attribute column. Then, specify the reconciliation properties in columns such as Mandatory, Recon Field, and so on. Repeat this for any other attributes that you need to update. If required, add new attributes by clicking Add Attribute.
- Click Next to proceed to the Settings page.
2.5 Updating Settings
Review the default provisioning and reconciliation settings for the application being created, and customize it if required.
2.5.1 Correlation Rules, Responses, and Situations
Learn about the predefined rules, responses and situations for Target and Authoritative applications. The connector uses these rules and responses for performing reconciliation.
2.5.1.1 Correlation Rules, Responses, and Situations for a Target Application
When you create a Target application, the connector uses correlation rules to determine the identity to which Oracle Identity Governance must assign a resource.
Predefined Identity Correlation Rules
By default, the Generic REST connector provides a simple correlation rule when you create a Target application. The connector uses this correlation rule to compare the entries in Oracle Identity Governance repository and the target system repository, determine the difference between the two repositories, and apply the latest changes to Oracle Identity Governance.
Table 2-8 lists the default simple correlation rule for a REST-based target system. If required, you can edit the default correlation rule or add new rules. You can create complex correlation rules also. For more information about adding or editing simple or complex correlation rules, see Updating Identity Correlation Rule in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.
Table 2-8 Predefined Identity Correlation Rule for a Target Application
| Target Attribute | Element Operator | Identity Attribute | Case Sensitive? |
|---|---|---|---|
|
__NAME__ |
Equals |
User Login |
No |
-
__NAME__ is a single-valued attribute on the target system that identifies the user account.
-
User Login is the field on the OIM User form.
Predefined Situations and Responses
The connector provides a default set of situations and responses when you create a Target application. These situations and responses specify the action that Oracle Identity Governance must take based on the result of a reconciliation event.
Table 2-9 lists the default situations and responses for this connector. If required, you can edit these default situations and responses or add new ones. For more information about adding or editing situations and responses, see Updating Situations and Responses in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.
Table 2-9 Predefined Situations and Responses for a Target Application
| Situation | Response |
|---|---|
|
No Matches Found |
None |
|
One Entity Match Found |
Establish Link |
|
One Process Match Found |
Establish Link |
2.5.1.2 Correlation Rules, Responses, and Situations for an Authoritative Application
When you create an Authoritative application, the connector uses correlation rules to determine the identity that must be reconciled into Oracle Identity Governance.
Predefined Identity Correlation Rules
By default, the Generic REST connector provides a simple correlation rule when you create an Authoritative application. The connector uses this correlation rule to compare the entries in Oracle Identity Governance repository and the target system repository, determine the difference between the two repositories, and apply the latest changes to Oracle Identity Governance.
Table 2-10 lists the default simple correlation rule for an authoritative application. If required, you can edit the default correlation rule or add new rules. You can create complex correlation rules also. For more information about adding or editing simple or complex correlation rules, see Updating Identity Correlation Rule in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.
Table 2-10 Predefined Identity Correlation Rule for an Authoritative Application
| Target Attribute | Element Operator | Identity Attribute | Case Sensitive? |
|---|---|---|---|
|
__UID__ |
Equals |
REST User GUID |
No |
|
__NAME__ |
Equals |
User Login |
No |
The identity correlation rule for an Authoritative application is as follows:
(__UID__ Equals REST User GUID) OR (__NAME__ Equals User Login)
-
__UID__ is an attribute on the target system that uniquely identifies the user account.
-
REST User GUID is the unique identifier of the resource assigned to the OIG User.
-
__NAME__ is a single-valued attribute on the target system that identifies the user account.
-
User Login is the field on the OIG User form.
Both the rule components are joined using the OR logical operator.
Predefined Situations and Responses
The connector provides a default set of situations and responses when you create an Authoritative application. These situations and responses specify the action that Oracle Identity Governance must take based on the result of a reconciliation event.
Table 2-11 lists the default situations and responses for an authoritative application. If required, you can edit these default situations and responses or add new ones. For more information about adding or editing situations and responses, see Updating Situations and Responses in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.
Table 2-11 Predefined Situations and Responses for an Authoritative Application
| Situation | Response |
|---|---|
|
No Matches Found |
Create User |
|
One Entity Match Found |
Establish Link |
|
One Process Match Found |
Establish Link |
2.5.2 Reconciliation Jobs
Apart from reviewing the provisioning, reconciliation, and organization settings for your application and customizing them if required, you must specify values for the mandatory parameters of the reconciliation jobs.
The Settings page provides a preview of all settings related to provisioning, reconciliation, and organizations. You can review these settings and customize them if required. On the Reconciliation tab of the Settings page, expand the Reconciliation Jobs section to view the reconciliation jobs that the connector automatically creates after you create a Target or an Authoritative application. At this point, you can delete any reconciliation job that you do not want to use. If required, you can also edit the reconciliation jobs or create custom reconciliation jobs to meet your requirements. For information about editing these predefined jobs or creating new ones, see Updating Reconciliation Jobs in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.
Note:
Ensure that you enter values for the mandatory parameters (marked by the asterisk (*) symbol) of all the reconciliation jobs and then click Apply.
By default, jobs for user, delete user, and entitlement reconciliation are available for use after you create your application.
User Reconciliation Jobs
-
REST Application Target User Reconciliation: Use this reconciliation job to reconcile user data from a Target application.
-
REST Application Trusted User Reconciliation: Use this reconciliation job to reconcile user data from an Authoritative application.
The parameters for both these jobs are the same.
Table 2-12 Parameters of the User Reconciliation Jobs
| Parameter | Description |
|---|---|
|
Application Name |
Name of the application you created for your target system. This value is the same as the value that you provided for the Application Name field while creating your application. Do not modify this value. |
|
Filter |
Enter the expression for filtering records that the scheduled job must reconcile. Sample value: |
|
Incremental Recon Attribute |
Name of the target system attribute that holds the timestamp at which the user record was modified. |
|
Object Type |
Type of object you want to reconcile. Default value: |
|
Latest Token |
The parameter holds the value of the target system attribute that is specified as the value of the Incremental Recon Attribute parameter. The Latest Token parameter is used for internal purposes. By default, this value is empty. Note: Do not enter a value for this attribute. The reconciliation engine automatically enters a value in this attribute. |
|
Scheduled Task Name |
Name of the scheduled job. Note: For the scheduled job included with this connector, you must not change the value of this attribute. However, if you create a new job or create a copy of the job, then enter the unique name for that scheduled job as the value of this attribute. |
Delete User Reconciliation Jobs
-
REST Application Target User Delete Reconciliation: Use this reconciliation job to reconcile data about deleted user accounts from a Target application.
-
REST Application Trusted User Delete Reconciliation: Use this reconciliation job to reconcile data about deleted user accounts from an Authoritative application.
The parameters for both these jobs are the same.
Table 2-13 Parameters of the Delete User Reconciliation Jobs
| Parameter | Description |
|---|---|
|
Application Name |
Name of the application you created for your target system. This value is the same as the value that you provided for the Application Name field while creating your target application. Do not modify this value. |
|
Object Type |
Type of object you want to reconcile. Default value: |
|
Scheduled Task Name |
Name of the scheduled job. Note: For the scheduled job included with this connector, you must not change the value of this attribute. However, if you create a new job or create a copy of the job, then enter the unique name for that scheduled job as the value of this attribute. |
Reconciliation Jobs for Entitlements
Depending on the child forms (of Lookup type) that you use or added on the Schema page, the corresponding reconciliation jobs for entitlements are displayed. For example, if you use the Groups child form on the Schema page, then the REST Application Group Lookup Reconciliation job is available for reconciling entitlements.
These reconciliation jobs are available only for a Target application. The parameters for all such reconciliation jobs are the same.
Table 2-14 Parameters of the Reconciliation Jobs for Entitlements
| Parameter | Description |
|---|---|
|
Application Name |
Name of the application you created for your target system. This value is the same as the value that you provided for the Application Name field while creating your target application. Do not modify this value. |
|
Lookup Name |
This parameter holds the name of the lookup definition that maps each lookup definition with the data source from which values must be fetched. Depending on the reconciliation job you are using, the default values is as follows:
For example, for the Groups entitlement job, the default value is |
|
Object Type |
Enter the type of object whose values must be synchronized. For example, for reconciling Groups entitlement, enter __GROUPS__. Note: Do not change the value of this attribute. |
|
Code Key Attribute |
Enter the name of the connector or target system attribute that is used to populate the Code Key column of the lookup definition (specified as the value of the Lookup Name attribute). Default value: Note: Do not change the value of this attribute. |
|
Decode Attribute |
Enter the name of the connector or target system attribute that is used to populate the Decode column of the lookup definition (specified as the value of the Lookup Name attribute). Default value: |