OIM Connectors


OIM Connectors
BMC Remedy Ticket Management
BMC Remedy User Management
CA ACF2 Advanced
CA Top Secret Advanced
Database Applications Table
Database User Management
Flat File
Generic REST
Generic Script
GoogleApps
IBM Lotus Notes/Domino
IBM OS/400 Advanced
IBM RACF Advanced
IBM RACF Standard
JDEdwards EnterpriseOne
Microsoft Active Directory User Management
Microsoft Active Directory Password Synchronization
Microsoft Exchange
Microsoft Windows
Novell eDirectory
Novell GroupWise
Oracle CRM OnDemand
Oracle e-Business Employee Reconciliation
Oracle e-Business User Management
Oracle Internet Directory
Oracle Retail Warehouse Management System
PeopleSoft Campus Solutions
PeopleSoft Employee Reconciliation
PeopleSoft User Management
RSA Authentication Manager
RSA ClearTrust
SAP Employee Reconciliation
SAP User Management Engine
SAP User Management
Siebel User Management
Sun Java System Directory
UNIX
WebServices

--------------------------------------------------------------------------------
OIM Generic Script Connector
In order to use the Generic Script Connector you need to first define the schema of the target system. This is a mandatory step. This will provide the connector to understand the schema/structure of data at the target system database. See section 2.1.1 Understanding the Schema File Format and 2.1.2. Creating a Schema File.        LINK to OIM Generic Script Connector guide.
The schema is defined using a properties file. This file contains the details of the datatypes, mandatory attributes, uid attribute that is used in target system. This schema file (properties file) consists of name-value pairs.

You must perform below steps to create the .properties file
Create  the .properties file (section 2.1.1)
You must create the schema.properties file on the host computer where you run the metadata generation utility
Put entries in the schema file for below Account qualifiers (ones that are mandatory are required)

Account qualifiers for attributes in target system. Use these Account qualifiers to define the schema of the target system
FieldNames             (Mandatory)
UidAttribute            (Mandatory)
NameAttribute         (Mandatory)
PasswordAttribute   (Optional)

FieldNames is a comma separated list of attributes that the connector must fetch from the target system.
In addition to above schema.properties you also need a resource.properties file on the host running the OIM (see section 2.2)

The schema file is used as an input to the metadata generation utility. It is necessary to
create a schema.properties file to help the connector understand the target system
schema. Before running the metadata generation utility, you must populate the schema
file in the specified format.
The schema file is a properties file and consists of name-value pairs. By default, the
metadata generation utility generates metadata for an __ACCOUNT__ object class that
is used to manage Users, groups, and organizations. If you want to generate metadata
for an object class other than __ACCOUNT__, then include the following entry in the
schema file:

Follow the below 3 Steps for using this Generic connector
1) Generating the connector
Understanding the schema of your target system is one of the important aspects in generating the connector. You must create a schema file describing the attributes of your target system to help the connector know your target system. The Generic Scripting connector includes a groovy file  (section 2.3.3 Configuring the Groovy File) in which you can specify information about your target system. This information is used by the metadata generator, one of the deployment utilities shipped with the connector, to generate the connector based on the target system schema.  In other words, when you run the metadata generator on the groovy file, the connector package is generated. This package contains an XML file that contains definitions for connector components such as adapters, process tasks, scheduled tasks, lookup definitions, and IT resource. Connector operations such as provisioning and reconciliation are performed using these connector components.
2) Installing and configuring the connector
In this stage, you install the generated connector by running the connector installer and then perform configuration tasks such as configuring the IT resource,enabling logging and so on.
3) Using the connector
In this stage, you start using the connector to perform connector operations such as reconciliation and provisioning
--------------------------------------------------------------------------------
OIM DBAT Connector
Oracle Identity Manager provides connectors to end systems to managing user provisioning tasks. eg Active Directory connector, Siebel User Management connector, SAP connectors, DBAT etc. The DBAT connector is Database Application Table connector used to exchange user data between a database and Oracle Identity Manager.

Here is a typical usage scenario for using DBAT connector
Example Inc. has some database-driven custom applications. These applications do not have any APIs for identity administration. The company wants to manage the lifecycle of users in these custom applications by using a centralized identity management system such as OIM. The DBAT connector is one of the solutions to this business problem. Example Inc. can use this connector to enable the exchange of user data between the database and Oracle Identity Manager.

Understanding Target System Discovery in the DBAT Connector
Target systems are identity-aware applications such as databases, Microsoft Active Directory, Siebel and so on that can be managed by Oracle Identity Manager connectors. In general, there are two broad categories of target systems for which Oracle Identity Manager connectors exist:
■ Predefined target systems: These are target systems that have a static schema and the connector is aware of this schema. This means that connectors for such target systems are shipped with preconfigured metadata or connector artifacts such as IT resource definition, process forms, resource objects, and so on.
■ Discovered target systems: These are target systems for which the schema is not known in advance. For example, a flat file does not have a fixed schema. Each target system can have a totally different schema. The connector is not initially aware of the schema that it is supposed to integrate with and the attributes available. The DBAT connector is a connector for a discovered target system.

Connectors for discovered target systems are not shipped with any artifacts. They are shipped only with a set of deployment utilities that help in discovering the schema and then generating the artifacts.
Discovery is the process of identifying the underlying schema of your database. You can discover the schema of your database by configuring a groovy file and running the DBAT Generator. This is discussed later in the guide
                                                       Connector Architecture

The target system can be database tables from any one of the following RDBMSs:
■ IBM DB2 Version 9.x, 10.x
■ Microsoft SQL Server 2005, 2008, 2012, 2014
■ MySQL 5.x
■ Oracle Database 10g, 11g, 12c as either single database or Oracle RAC implementation
■ Sybase Adaptive Server Enterprise 15.x
------------------------------------------------------------------------------------------------

Comments

Post a Comment

Popular posts from this blog

VMware fix for Invalid manifest and ova file import failed errors

Image
Recently we got a OVA file for a virtual machine. The vendor instructions were to import the ova file in vmware Workstation, Player for Windows/Linux, Fusion for Mac, and VirtualBox as well.  The instructions were to take the available package and launch the VM with VMware workstation. The package contained  Module.mf, Module.ovf and Module-disk.vmdk and a Module.ova file. The .mf and .ovf file were 2 KB each whereas the vmdk was several gigs. The package also contained a Module.ova file which was several gigs as well. OVF           Open Virtualization Format MF             Manifest file VMDK       Virtual Machine Disk OVA           Open Virtualization Appliance The ovf file is a xml file that contains metadata for the ovf package The mf file contains the SHA1 hash codes of all files in the package The vmdk file is the disk image of the virtual machine,  VMware Workstation or VirtualBox. (vmdk format was originally developed by VMware and is an open format now). All of
Read more

SOAPUI - import certificate

Image
Note: SoapUI has two versions, one is open source and second Professional version. The open source can be download here . (confirmed link 12/19/2018). SSL Handshake issue:   There is an Issue in SoapUI version 5.3.0 (and 5.2.0 version) with SSL handshake error. It was resolved by updating below in vmoptions file ( refer here ). However, the error that shows up while trying to load wsdl is "Error loading WSDL" as below The fix is to Enable TLS 1.2 protocol for SOAP/REST calls in SoapUI, by ammending the vmoptions file to add the directive for TLS as (-Dsoapui.https.protocols=TLSv1.2). Refer here . Update: Version 5.5.0 does not have this issue. If you are on 5.3.0 better upgrade to 5.5.0 which is available now (Feb 2019). I had above issue as well as another issue reaching to https endpoint. Upgrade to 5.5.0 resolved issue. Select "Check for updates" under the Help menu and you will get option for upgrade. Select upgrade current version and accept all defaul
Read more

Session Timeout in Oracle Access Manager

Image
Session Timeout in Oracle Access Manager (OAM) The session lifetime and Idle timeout entries control how long a user's session is valid. In OAM, a user session is an object which represents an authenticated user. This object is stored in the server memory and if Database session persistence is enabled, this object is stored or available in the database. Each session is unique and is identified by both a userid and Session ID (session identifier), see screenshot below "OAM User Session Management".  A valid session means a user has been authenticated with OAM. A session can have following three states: 1) active 2) inactive 3) expired When a session is created it is in active state and is available as an object in the OAM. After a set time - idle timeout, the session moves or transitions to inactive state. And finally after the Session Lifetime time, the session is marked as expired. Expired sessions are removed from server memory. Read more about Session Lifetime
Read more