Oracle VM Site Review - Oracle VM Health Check
view counter

External authentication with Microsoft Active Directory in ODI 11g – Part 3

Thanks to John Goodwin for this story
Previously I went through setting up the Studio to use to external authentication and then the standalone alone agent, to be complete I briefly want to go over the process to enable authentication for the J2EE components so that means the agent and console.
Oracle VM Site Review - Oracle VM Health Check
view counter

I am not going to go through the process of extending the WebLogic domain to deploy the agent and console as this is covered in detail here, it might be also worth looking at integrating the console with Enterprise Manager and the process to do so can be found here.

Do make sure if that you have added the credential store entries so the J2EE components can connect to the ODI repositories, in the documentation and OBE it gives an example on how to do it using the WLST (WebLogic scripting tool) but it can also be achieved if Enterprise Manager has been enabled by…

Starting up the WebLogic admin server and going to http://:7001/em

 Select the domain and right click Security > Credentials

Select Create Map and add the map name of oracle.odi.credmap

Select the map and click Create Key, the Key is SUPERVISOR and then enter the username and password for a supervisor account in ODI, if the password changes at any point then the Key can be edited and the password updated.

This updates the cwallet.sso file located at
\user_projects\domains\ODI_DOMAIN\config\fmwconfig

This got me thinking as in the first two parts I used the odi credtool to create the cwallet.sso and wondered whether I could also use enterprise manager as an alternative, I copied the cwallet.sso file I configured previously to the fmwconfig folder.

The answer is yes and it also means you could use one cwallet.sso instead of having multiple copies; the file could possibly be located on a shared location where all the ODI components can access it by updating the path in the jps-config.xml file.

Anyway back to configuring the J2EE components for external authentication, if you look at the ODI documentation then you will see the following information on how to configure.

Java EE Components
Oracle Data Integrator components deployed in a container (Java EE Agent, Oracle Data Integrator Console) do not require a specific configuration. They use the configuration of their container.

See "Configuring OAM Identity Assertion for SSO with Oracle Access Manager 10g" in the Oracle Fusion Middleware Application Security Guide for more information on OPSS configuration in a Java EE context.

As usual the documentation is a bit vague and transports you off to yet another document which personally I think confuses the matter. Basically what the statement means is that the J2EE components will use the external authentication that has been configured in WebLogic.

Now if you have configured external authentication in WebLogic before then you will know what to do, for those that have never configured here is a summary of the process.

I am going to use the same Microsoft Active Directory that I used in the previous external authentication blogs.

To configure WebLogic log into the admin console e.g. 
http://:7001/console

Select Security Realms

Select the default realm called myrealm

Select the Providers tab

Select New to add a new provider

Provide a name for the AD and from the large list of types of authentication providers choose “ActiveDirectoryAuthenticator” and click OK

The provider will be added to list

I selected reorder and placed the newly added AD as the first in the list to authenticate against.

Select the AD provider

You will notice there is an option to set a Control Flag, this determines the login sequence if there is more than one authentication provider.

This needs to be set to SUFFICIENT or the login using the AD accounts will not work.

“A SUFFICIENT value specifies this LoginModule need not succeed. If it does succeed, control is returned to the application. If it fails and other Authentication providers are configured, authentication proceeds down the LoginModule list.”

Select the “Provider Specific” tab to enter the AD details

Enter the hostname of the AD, the port and the principal which is the full distinguished name of the user to connect to the AD with which is my case is cn=supervisor,cn=users,DC=epmmsad,DC=com

In the users section I updated the following.

User Base DN : where the users are located in the AD e.g. cn=users,DC=epmmsad,DC=com

User From Name Filter : As I want to use the sAMAccountName as the user attribute I updated to (&(sAMAccountName=%u)(objectclass=user))

User Name Attribute: set to sAMAccountName

Enable : Use Retrieved User Name as Principal

The rest of the sections I left as default, the WebLogic admin server requires restarting to take account of these changes.

The details of the AD configuration are contained in
\user_projects\domains\ODI_DOMAIN\config\config,xml

Once the server has restarted log in and go to the User and Groups section under myrealm and if the AD was correctly configured you should see users from the AD. If you don’t see the users then check the AdminServer.log in
\user_projects\domains\\servers\AdminServer\logs

The J2EE agent and should now be using external authentication.

The agent tested successfully.

To test the console I created a user called odi_user in the AD

Within the security area in the Studio I added the AD user and provisioned them.

I was then able to log into the ODI console with the external user.

So over the three parts this completes the process of configuring all the ODI components to use external authentication, this means the Studio, console, standalone and J2EE agents are all enabled to authenticate against an Active Directory.

Read the entire article at its source

view counter