Wednesday Feb 04, 2015

OIM11gR2PS2: Disconnected System Resource status based on manual fulfillment outcome

When an OIM disconnected system application is provisioned to a user, a manual fulfillment activity is generated and can be viewed in the inbox. This task indicates the person has to complete the provisioning activity manually on the target system and mark the status in OIM. The task to outcomes possible:

  1. Complete
  2. Reject  

When the activity is in pending for completion, the resource/account status is 'Provisioning'. Depending on the outcome from SOA, OIM account status is set.

  1. If the fulfillment person has completed the task and clicked 'Complete' in OIM, the resource status changes to 'Provisioned' from 'Provisioning'. 
  2. If the fulfillment person decides to reject and clicked 'Reject' in OIM, the resource status remains in 'Provisioning' status. This status at this point is not apt. A meaningful status at this point could be 'Cancelled' , 'Rejected' or 'Revoked'.
[Note:For a full view, open the image in a new tab]

While OIM supports custom object status, it is a bit tricky to induce the new status into the object life cycle. Hence, it is simpler to set the object status as 'Revoked' than any other. In the following section lets understand what has to be done to achieve this.

Notice that OIM Provisioning process definition of a disconnected system is auto generated and has the following tasks(Has many other tasks, but list shows what we are interested in):

  1.  ManualProvisioningStart
  2. ManualProvisiongEnd 

The ManualProvisioningStart process task is invoked when the resource is provisioned to the user as this is the process task marked as 'Required For Completion'. This will invoke a SOA composite 'DisconnectedProvisioning' and create a human task. The process task is completed successfully and a manual task is pending for approval. This doesn't have any impact on the resource/account status

 When an action is taken on the pending human task, the process task ManualProvisiongEnd is triggered. This task is responsible for setting the object status. The OOB setting in the Responses of this process task is shown here:

 On the 'Task to Object Status Mapping', the status 'X' is mapped to 'None' OOB. This has to be mapped to 'Revoked' for the object status to be set as 'Rejected' when the fulfillment person Rejects the task. The following screenshot illustrates this configuration change:

 This is a very simple change doesn't require any downtime. Even if the manual fulfillment human task has an expiry setting, this approach works !!

Monday Jun 23, 2014

OIM11gR2: SOA composite for Request Approval Process

The Oracle Identity Manager version consider is OIM11g R2 Base.[Read More]

Monday Apr 28, 2014

OIM11gR2: How to handle child data in a custom ICF connector

This blog entry explains how to perform child table operations in custom ICF connector code.This blog does not explains in detail about how to write ICF connectors. This is just to help set up and perform child table operations through ICF.  

We will only discuss here what APIs to use to perform child table operations in your custom ICF code. Second section of this blog entry will discuss a typical requirement of setting up reconciliation for a resource with multi-column child table through custom ICF. 

SECTION 1 - Child table operation APIs in custom ICF connector

We may want to perform different provisioning operations such as add, remove, update on a child table through our custom ICF code.  

Operation Add/ Remove operations on child table:

To perform child table operations in custom ICF connector, you need to implement UpdateAttributeValuesOp interface in your connector code. The methods addAttributeValues & removeAttributeValues deal with adding and removing child table data.

addAttributeValues(objectClass, uid, attributes, operationOptions);

removeAttributeValues(objectClass, uid, attributes, operationOptions);

Here one should note that, UpdateOp is used for updating only Parent form attributes. To handle parent form updates & child form creation/updation/deletion we have to implement both the interfaces i.e., UpdateOp and UpdateAttributeValuesOp.

UpdateOp interface:  http://docs.oracle.com/cd/E37115_01/apirefs.1112/e28160/org/identityconnectors/framework/spi/operations/UpdateOp.html

UpdateAttributeValuesOp interface: http://docs.oracle.com/cd/E37115_01/apirefs.1112/e28160/org/identityconnectors/framework/spi/operations/UpdateAttributeValuesOp.html

Update operations on child table:

1)     You may have a question as to "How is update to childtable data handled in ICF"? This is how it works :-

        When child table row is updated, OIM triggers removeAttributeValues(oldValue) followed by addAttributeValues(newValue) in the connector.

  Now how do we pass values to following methods:

public String addChildTableValue(String objectType, String childTableName, long childPrimaryKey)

public String removeChildTableValue(String objectType, String childTableName, Integer taskInstanceKey)

 Here, objectType will be User, ChildTableName should be the name of child table process form of your implementation and refer below images for mapping childPrimaryKey and taskInstanceKey:

 childPrimaryKey Mapping


taskInstanceKey Mapping

Using above information you can perform different provisioning operations on child table through custom ICF connector code.

SECTION 2:  Setting up reconciliation for Multi-column child table in custom ICF connector

We often see requirements where multi-column child data has to be processed using custom ICF. We had a requirement where we were required to reconcile a resource with more than one column in its child form.

 We could not find enough information about how to achieve this in any of the blogs/ product documentation or even training docs. Training guide, though talks about Flat file custom ICF with child table, but that only is for child tables which have single column. 

 Handling multi-column child table in custom ICF is different from how you would see for single-column in lab guides or product documentation ( Developer guide: http://docs.oracle.com/cd/E37115_01/dev.1112/e27150/icf_integration.htm). 

Below is what was done in our case:

Requirement: To Provision and Reconcile multi column child table data using custom ICF

Below is how the parent and child form data looked in our case:



Child table Data Reconciliation Implementation:

 The recon lookup for our implementation was set up as below:

  1. Recon Lookup :


 2.  Apart from implementing  addAttributeValues & removeAttributeValues methods in your code, you also need to have executeQuery(), schema(), getEmbeddedObjAttributeInfo() and addAttrInObjClass() methods in your custom ICF code.

Below is the code snippet of different methods that we implemented for child table:

Here,  APPS = ‘apps’ and APPLICATIONS = ‘Applications’  (from lookup entry above) in the code below.

‘Applications’ and ‘UserName’ in getEmbeddedObjAttributeInfo method are the child table columns

   3.  Below is the snippet from executeQuery method for child table data wrapping

Here too,  APPS = ‘apps’ and APPLICATIONS = ‘Applications’  (from lookup entry above) in the code below.

4.  Below is how we had set up Reconciliation Field Mapping in Process Definition:


Friday Apr 25, 2014

OIM11gR2PS2 New Features

  • Access Policy Harvesting for Reconciled Accounts

  • Dynamic Organization Membership

  • Hierarchical Entitlements

  • Catalog Auditing

  • Archiving/Purge Support for Entities

  • Draft Request Support

  • Additional Information in Requests

  • Account and Entitlement Dependency Handling

  • Entitlement Form Support

  • Sunrise/Sunset of Accounts and Entitlements

  • Flexible Certification

  • Improved Diagnostic Console via Oracle Enterprise Manager

  • Enable Taskflows for Customization

  • FVC Utility Enhancements

  • BI Publisher Certification for IBM WebSphere Application Server

Wednesday Mar 26, 2014

OIM11gR2PS2 OPSS Upgrade: Internal Exception: java.sql.SQLException: ORA-12801: error signaled in parallel query server

[Read More]

OIM11gR2: Uninstall connector utility

Unlike earlier version of OIM, you can now uninstall a connecter that is installed using a connector bundle or created on an environment directly.

Note: Before deleting a connector, navigate to Resource Object and click Create Reconciliation profile before deleting connector. Otherwise you see the connector delete is unsuccessful.

The following are the steps involved in uninstalling a connector:

 1. Set up the properties file with appropriate information. Location: $OIM_HOME/bin/ConnectorUninstall.properties

2. Execute the uninstall script. Location: $OIM_HOME/bin/uninstallConnector.bat or uninstallConnector.sh

Almost all the properties on the ConnectorUninstall.properties file are explained in the OOB file. The focus here would be on ObjectType and ObjectValues properties.

If the connector is installed using a connector bundle and you wanted to uninstall it, ignore these properties.  If a connector is installed using Deployment Manager --> Import then these properties are helpful.

By providing ObjectType=Resource and ObjectValue=<Name of RO>, a few of the important connector components can be deleted.

If a connector is uninstalled using the Resource Object Name and it is value, the objects like Process Definition, Process Form, IT Resource, Application Instance are deleted. Note that the request dataset is not deleted.

OIM11gR2 : Fetch Human Task comments using SOA API

From OIM11gR2, in order to get the human task comments one should use SOA API instead of OIM Request API.

The Task Id or Task Number can be obtained from OIM request tables which can be used to uniquely identify the human task.

Refer the link to know human task operations using SOA API: http://docs.oracle.com/cd/E25178_01/fusionapps.1111/e15524/uc_manage_tasks.htm

Tuesday Jun 11, 2013

OIM11gR2: ADF: Frequently used EL expressions

Category

Usage

EL [Expression Language]

User

Get the current user’s attribute value by passing the attribute name

#{oimcontext.currentUser['ATTRIBUTE_NAME']}

User

Similarly get the value for a UDF

#{oimcontext.currentUser['UDF_NAME']}

User

Gets the roles assigned to current user. Returns list of RoleEntity objects. It is a Java Bean having name, description, key, and displayName properties

#{oimcontext.currentUser.roles}

User

Return true if user is a system administrator

#{oimcontext.currentUser.roles['SYSTEM ADMINISTRATORS'] ne null}
 
User

Returns true if user is assigned with admin role

'OrclOIMSystemAdministrator'

#{oimcontext.currentUser.adminRoles['OrclOIMSystemAdministrator'] ne null}
 
User

Returns user key

#{oimcontext.currentUser.usr_key}
 
User

Returns user key

#{oimcontext.currentUser['usr_key']}
 
User

Returns user login

#{oimcontext.currentUser['User Login']}
 
Request

Returns current operation. Possible values: CREATE/MODIFY

#{pageFlowScope.requestFormContext.operation}
 
Request

Returns true if the current operation is Modify

#{pageFlowScope.requestFormContext.operation eq 'MODIFY'}
 
Request

Return the current action type. Possible values: APPROVAL/ FULFILL/ REQUEST/ VIEW/ SUMMARY.

On all approval pages/ approver view the value is APPROVAL

For Manual fulfillment page the value is FULFILL

#{pageFlowScope.requestFormContext.actionType}
 
Request

Returns true if the action type is Request i.e. the user is about to submit the request

#{pageFlowScope.requestFormContext.actionType eq 'REQUEST'}
 
Request

Returns true if the request is bulk

#{pageFlowScope.requestFormContext.bulk}
 
Request

Returns beneficiaries user ids[user login values]

#{pageFlowScope.requestFormContext.beneficiaryIds}
 
Request

Returns keys for cart items

#{pageFlowScope.requestFormContext.cartItemIds}
 
Request

Returns the type of item added to request. Possible values: ROLE/ ENTITLEMENT/ APP_INSTANCE/ USER.

#{pageFlowScope.requestFormContext.requestEntityType}
 
Request

Returns true if added item is Application Instance

#{pageFlowScope.requestFormContext.requestEntityType eq 'APP_INSTANCE'}
 
Request

Returns application instance key for the item added

#{pageFlowScope.requestFormContext.requestEntitySubType}
 
Request

Returns provisioned instance key for a modify type request

#{pageFlowScope.requestFormContext.instanceKey}
 
General

Invoke a method present on backing bean

#{backingBean.<Bean Name>.<bean method>}
General

To show a field disabled on all FULFILL and APPROVAL pages

disabled="#{pageFlowScope.requestFormContext.actionType ne 'REQUEST'}"

Monday May 20, 2013

OIM11gR2: Issue with (request form prepop Vs process form prepop)

Background

Pre-Populating known information on a request form during a provisioning operation is a very common need. OIM11g R2 supports request form pre-population using plug-in concept. The plug-in point is "oracle.iam.request.plugins.PrePopulationAdapter". A sample entry in plug-in.xml is shown here:

<plugin pluginclass="PrePopulateUserLogin" version="1.0" name="PrePopulateUserLogin">
   <metadata name="PrePopulationAdapater">
    <value>PrepopTestApp::User Login|FileTransfer::Account Login</value>
   </metadata>
  </plugin>

Issue

The class  PrePopulateUserLogin is used maintain the logic to fetch and return the value of User Login.

The returned value is populated on the attributes mentioned in the <value> element of the above seen snippet. They are 'user Login' field on the 'PrepopTestApp' application and 'Account Login' on 'FileTransfer' application.

In case the plugin class couldn't fetch a value for User Login and it is programmed in such a way that a blank/empty string is returned. In this scenario doing this may look smooth and robust enough. However, this is an issue if you also have a logic to pre-populate the same attribute using a pre-populate adapter attached on the process form.

Flow

 The User Login is returned blank by the request form pre-populate code. The request is submitted with a blank User Login value. Say the request had gone through required approvals.

The process form pre-populate adapter gets triggered because the 'User Name' attribute is blank. Any OIM developer can state that, once the pre-populate adapter is triggered and returns a value, the value is populated on the process form. Surprisingly, this doesn't happen in this case.

The adapter is triggered and a value is returned, but the form is not populated. In case your User Name attribute is mandatory on the process form, you account stands in provisioning state and you can see from the Resource History that 'System Validation' is pending. Try this out!!!

Solution

At least I felt that it is a good discovery. The solution is simple.

In your request form pre-population logic if you don't find a value to return, return null instead of blank string

Case1:   If we do this, the process form pre-pop triggers but will not a set a value . The weird thing is since it is triggered, it should set the value fetched, but it doesn’t.
if (attrValue!=null)
      return attrValue;
    else
      return "";
Case2: The process form pre-populate gets triggered and sets a value
if (attrValue!=null)
      return attrValue;
    else
      return null;

Conclusion

This means, for request form pre-populate we should return null, if the source attribute value is either blank/null. 




Friday Apr 12, 2013

OIM11gR2PS1 (11.1.2.1) Database Schema Documentation Now Available

For anyone who is interested to know more about the OIM11gR2 database schema, OIM11gR2 DB Data Model and the Data dictionary, refer the following document on https://support.oracle.com

Oracle Identity Manager 11gR2PS1 (11.1.2.1) Database Schema Documentation [ID 1541858.1]


About

OIM11gR2 Blog by NA-TAG Offshore IDAM team

Search

Categories
Archives
« March 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today