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.
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://<adminserver>: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
<MIDDLEWARE_HOME>\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://<adminserver>: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
<MIDDLEWARE_HOME>\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
<MIDDLEWARE_HOME>\user_projects\domains\<Domain Name>\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.
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://<adminserver>: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
<MIDDLEWARE_HOME>\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://<adminserver>: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
<MIDDLEWARE_HOME>\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
<MIDDLEWARE_HOME>\user_projects\domains\<Domain Name>\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.
