Oracle Identity Management Connector Overview

Oracle Identity Manager (OIM) is a complete Identity Governance system that automates access rights management, and provisions IT resources.  One important aspect of this system is the Identity Connectors that are used to integrate OIM with external, identity-aware applications.

New in OIM 11gR2 PS1 is the Identity Connector Framework (ICF) which is the foundation for both OIM and Oracle Waveset.

Identity Connectors perform several very important functions:

• On boarding accounts from trusted sources like SAP, Oracle E-Business Suite, & PeopleSoft HCM
• Managing users lifecycle in various Target systems through provisioning and recon operations
• Synchronizing entitlements from targets systems so that they are available in the OIM request catalog
• Fulfilling access grants and access revoke requests
• Some connectors may support Role Lifecycle Management
• Some connectors may support password sync from target to OIM

The Identity Connectors are broken down into several families:

The BMC Remedy Family

• BMC Remedy Ticket Management
• BMC Remedy User Management

The Microsoft Family

• Microsoft Active Directory
• Microsoft Active Directory Password Sync
• Microsoft Exchange

The Novell Family

• Novell eDirectory
• Novell GroupWise

The Oracle E-Business Suite Family

• Oracle e-Business Employee Reconciliation
• Oracle e-Business User Management

The PeopleSoft Family

• PeopleSoft Employee Reconciliation
• PeopleSoft User Management

The SAP Family

• SAP CUA
• SAP Employee Reconciliation
• SAP User Management

The UNIX Family

• UNIX SSH
• UNIX Telnet

As you can see, there are a large number of connectors that support apps from a variety of vendors to enable OIM to manage your business applications and resources.

Authorization Model in SOA Suite 11g

Figuring out how the authorization works in SOA Suite 11g between the WebLogic Console and Enterprise Manager can seem daunting. This blog post aims to clarify how the two parts work together and hopefully demonstrates that it is not as complicated as it may first appear.

In SOA Suite 11g there is one Authentication stack and 2 Authorization stacks:

1. Authentication is handled by WebLogic Server and is based on the order and control flags set for the Authentication Providers in the Security Realm.
2. Authorization is split between the Global Role definitions in WebLogic Server and the SOA Application Roles in Fusion Middleware Control (EM). WLS Roles govern the interactions in the WLS Console while the SOA Roles control permissions on SOA resources / activities. In most cases the users will need access to both.

Let's describe the authorization stacks independently:

In WLS there are Global Roles defined out of the box that apply to the WebLogic Console. For our purposes we will focus on the 'Admin' Global Role as it has a counterpart in EM and is representative of the other roles as well. In the standard domain this role has a single membership condition which is for the pre-configured Group 'Administrators'. This means that any user who is a member of a group called 'Administrators' will be granted the permissions of the 'Admin' Global Role in WLS. This is important because in order for a user to login to the WLS or EM consoles they must have permissions for at least one of the WLS Global Roles, either through a Group or individual association.

To access the WLS Roles:

1. Login to the WLS Console (http://host:port/console)
2. Select 'Security Realm' on the left
3. By default there is a single realm called 'myrealm'. Select it.
4. Select the 'Roles and Policies' tab
5. Expand 'Global Roles' in the list
6. Expand 'Roles'
7. The 'Admin' Role is at the top. To view the expression select 'View Role Conditions' on the right

In the default configuration the conditions should look like this:

 

In SOA EM we find several Application Roles available for the soa-infra application, one of which is 'SOAAdmin'. Out of the box this role has a single member, the 'Administrators' Group from WLS. Permissions provided by this role include composite deployment and instance management within EM, among other things. Only Users and Groups may be associated with the Application Roles in EM. This means that a user can be granted the permissions of the WLS 'Admin' Global Role explicitly in WLS but will NOT automatically have composite deployment privileges unless they are a member of the WLS 'Administrators' Group or have been explicitly added to the 'SOAAdmin' role in EM.

To access the EM soa-infra Roles:

1. Login in to EM (http://:/em)
2. Expand 'SOA' on the left
3. Right click on 'soa-infra'
4. Select 'Security' and then 'Application Roles'
5. Leave the text box blank and click the search arrow icon to the right
6. You get the full list of Application Roles for the soa-infra application. 'SOAADmin' is at the top
7. Select 'SOAAdmin' and then click the 'Edit' button
8. You can see the members of the role. By default there is only the 'Administrators' Group from WLS

Here's what it should look like:

 
(click image for full view)

The bridge between the two Authorization stacks is the system-jazn-data.xml file which can be found under/config/fmwconfig. By default this file stores references to all of the application deployments and the associated EM roles. Here is the partial entry for soa-infra:


   soa-infra
      
         
            SOAAdmin
            SOA Admin Role
            SOA application admin role, has full privilege for performing any
            operations including security related
            88293480FE7711E08F7531B0B4CEDB15
            oracle.security.jps.service.policystore.ApplicationRole
            
               
                  weblogic.security.principal.WLSGroupImpl
                  Administrators
               
         
      

Here we're only looking at the first role associated with the soa-infra application, 'SOAAdmin'. We also see the 'members' element specifying that the WebLogic 'Administrators' Group is associated. The 'class' entry indicates the type of object 'Administrators' is. If we were to add a User to the role in EM we would then see an additional 'member' entry with a User class type.

Please note that in a clustered environment we highly recommend that this information be moved to either DB or LDAP persistence using OID. More information on changing the configured persistence type can be found here.

All of this works very well in the standard domain using the Default Authenticator (Embedded LDAP). The 'Administrators' Group is already there, it's associated with the WLS 'Admin' Global Role and has been added to the 'SOAAdmin' Application Role in EM. If you're using a different Authentication Provider, however, you must configure these connections yourself. Let's go into more detail using Active Directory as the generic example.

Let's assume that the AD Authentication Provider is configured in WLS, is at the top of the Authenticators list and has its Control Flag set to 'REQUIRED'. You can see the users in the WLS console but none of them can login to the console or EM as themselves. This is because they are not yet associated with a Global Role in WLS and there are two options:

1. Create a Group in AD that these users will be added to and then add that Group to the WLS 'Admin' Global Role in the WLS Console. If you name the AD Group 'Administrators' then you will not have to add it to the Global Role conditions because it is already there.
2. Add the users individually to the WLS 'Admin' Global Role in the WLS Console

This will give the AD 'admin' users the ability to login to the WLS Console and EM.

Now when these users attempt to deploy a composite from either JDeveloper or EM they get an error saying that they must have permissions of 'SOAAdmin' or 'SOAOperator'. This is because the users are not yet granted the permissions on the soa-infra application through a default or custom Role in EM. 'SOAAdmin' and 'SOAOperator' are examples of default Roles that are immediately available. There are 2 options:

1. Add the AD Group to the existing 'SOAAdmin' or 'SOAOperator' Application Role in EM. If the AD Group was called 'Administrators' then they won't get the error in the first place because the supporting configuration is in place out of the box for the 'Administrators' Group.
2. Add the AD users individually to the SOAAdmin or SOAOperator Application Role in EM

This action bridges the gap between the 2 Authorization stacks and allows the full range of expected permissions. The below diagram may help to visualize the relationship:

 
(click image for full view)

In releases prior to 11.1.1.6 the explicit addition of the Group or Users to the Application Roles in EM is not required as long as they are associated with the WLS Global Role, along with the standard 'Administrators' or 'Operators' Group (Admin and Operator roles respectively). We discourage you from taking advantage of this as 11.1.1.6 changes the behavior, requiring that the Groups / Users be explicitly added to the EM Roles as described here.

Where and When should I use the Oracle Service Bus (OSB), Excellent paper by Guido Schmutz

How to Propagate an Oracle Service Bus Configuration

Overview of WebLogic Distributed JMS