In the last part I went through the painful but easy when you know how process to set up ODI 11g Studio and repository to use external authentication through Microsoft Active Directory.
To be complete I thought I would cover setting up external authentication for the standalone agent which I go through today and then in the next part the J2EE agent and ODI console.
If you are considering setting up external authentication for a standalone agent then if you haven’t already make sure you read through the last part as there will be an assumption that you have configured the jps-config.xml file and generated the cwallet.sso file.
So let us see what the ODI documentation states about setting up the external authentication.
Standalone Agent
The configuration to connect and use the identity store is contained in an OPSS Configuration File called jps-config.xml file. Refer to the Oracle Fusion Middleware Application Security Guide for more information.
Copy this file in the ODI_HOME/agent/bin/ directory. The agent and the command line scripts will authenticate against the configured identity store.
So once again in its usual vagueness the documentation does not provide much detailed information but after already configuring the Studio you get the idea that you need to configure a jps-config.xml and place it in the agent/bin
Before I go through the process I created a user in the AD to be used for the standalone agent called odi_agent, created the user in the Studio and then I configured the jps-config file and generated the cwallet.sso file based on the process in the last blog.
I generated the files in the <ODI_HOME>\oracledi\agent\bin directory.
The next step is to update the odiparams script to enter the connection information and agent user credentials.
The master repository encoded password was generated using the encode utility.
The ODI_SUPERVISOR variable was set to the AD user odi_agent.
The supervisor password was generated using the encode utility again.
If you look at the ODI_JAVA_OPTIONS variable you can see that there is a reference to the jps-config.xml file, the configuration assumes that the file is located in the same directory, if say you have the agent and the Studio on the same machine and want to use one instance of the file and wallet then you can update and add the full path to point to one location.
That’s pretty much all you need to do and you can start up the agent and all is good,well….
2012-04-03 20:40:44.920 ERROR odi.core.security.internal.ODIJpsHelper.createSubject Get exception. User:odi_agent. Execption msg is:oracle.security.jps.JpsRuntimeException: java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=JPS,keyName=msad.ldap.credentials read) at oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModule.initializeLM(IdStoreLoginModule.java:663)
Unfortunately I was hit by the above error which didn’t fill me with joy.
I then added the additional parameters to the ODI_JAVA_OPTIONS variable in the odiparams script to turn on debugging.
"-Djps.auth.debug=true" "-Djps.auth.debug.verbose=true"
A large amount of errors were generated and it looks like the issue relates to java permissions on all the related packaged jars.
I decided to leave it there as there is the following bug on Oracle Support.
Bug 13255270: 'ACCESS DENIED...' ERROR WHEN STARING ODI STANDALONE AGENT WITH EXTERNAL AUTHENT
UPDATE : 25th April 2012
The bug in Oracle Support has been updated and I also got an anonymous comment on this blog entry from I assume the same person that has updated the bug.
I have removed my workaround as it was only temporary until a solution was available, hopefully the ODI documentation will be improved to reflect this.
First create a file called server.policy in the <ODI_HOME>\oracledi\agent\bin directory.
grant codeBase "file:${ODI_HOME}/../../-" {
permission oracle.security.jps.service.credstore.CredentialAccessPermission "context=SYSTEM,mapName=*,keyName=*", "read";
};
paste the above grant statement into the file.
grant codeBase "file:${ODI_HOME}/../../-" {
permission oracle.security.jps.service.credstore.CredentialAccessPermission "context=SYSTEM,mapName=JPS,keyName= msad.ldap.credentials", "read";
};
It is also possible to use the mapName and KeyName that are being used in the cwallet.sso file.
Edit odiparams.bat/sh and make sure ODI_HOME is set as an absolute path.
This could also be achieved by setting ODI_HOME as an environment variable instead of editing the file.
Also add the line
set ODI_ADDITIONAL_JAVA_OPTIONS=%ODI_ADDITIONAL_JAVA_OPTIONS% "-DODI_HOME=%ODI_HOME%"
The agent now starts up without any issues authenticating with the AD account.
Now if you want to take it one stage further and use OPMN to manage the agent and on windows create as a service then you could have a look at a previous blog I wrote on setting it up.
If you are going to use OPMN and go down the route outlined in the Oracle support document 1274484.1 or the equivalent Oracle by Example and install FMW 11g WebTier Utilities then
• You don’t need to install WebTier Utilities 11.1.1.2 as 11.1.1.6 can be used and is available from here
• When installing you don’t need to select Oracle Web Cache and can just select Oracle HTTP Server which will then install OPMN.
There are also a few things to watch out for when configuring OPMN to manage the agent with external authentication.
The configuration uses a template file in the agent\bin directory called odi_opmn_standaloneagent_template.xml
It is possible the usage of “./jps-config.xml” may be an issue when starting up the agent through OPMN as an error will be generated saying the file can’t be found, in this case the full path to jps-config.xml can be entered.
The configuration also defaults to a user name of SUPERVISOR so if you are using a different user for external authentication this will need to updated.
The changes can be made directly to the template file before adding the agent to OPMN or after adding the agent and updating opmn.xml which will be created in
<INSTANCE_HOME>\config\OPMN\opmn
Any changes to opmn.xml will require a full restart of OPMN.
Next time I will cover the steps to use external authentication with the J2EE agent and ODI console.
To be complete I thought I would cover setting up external authentication for the standalone agent which I go through today and then in the next part the J2EE agent and ODI console.
If you are considering setting up external authentication for a standalone agent then if you haven’t already make sure you read through the last part as there will be an assumption that you have configured the jps-config.xml file and generated the cwallet.sso file.
So let us see what the ODI documentation states about setting up the external authentication.
Standalone Agent
The configuration to connect and use the identity store is contained in an OPSS Configuration File called jps-config.xml file. Refer to the Oracle Fusion Middleware Application Security Guide for more information.
Copy this file in the ODI_HOME/agent/bin/ directory. The agent and the command line scripts will authenticate against the configured identity store.
So once again in its usual vagueness the documentation does not provide much detailed information but after already configuring the Studio you get the idea that you need to configure a jps-config.xml and place it in the agent/bin
Before I go through the process I created a user in the AD to be used for the standalone agent called odi_agent, created the user in the Studio and then I configured the jps-config file and generated the cwallet.sso file based on the process in the last blog.
I generated the files in the <ODI_HOME>\oracledi\agent\bin directory.
The next step is to update the odiparams script to enter the connection information and agent user credentials.
The master repository encoded password was generated using the encode utility.
The ODI_SUPERVISOR variable was set to the AD user odi_agent.
The supervisor password was generated using the encode utility again.
If you look at the ODI_JAVA_OPTIONS variable you can see that there is a reference to the jps-config.xml file, the configuration assumes that the file is located in the same directory, if say you have the agent and the Studio on the same machine and want to use one instance of the file and wallet then you can update and add the full path to point to one location.
That’s pretty much all you need to do and you can start up the agent and all is good,well….
2012-04-03 20:40:44.920 ERROR odi.core.security.internal.ODIJpsHelper.createSubject Get exception. User:odi_agent. Execption msg is:oracle.security.jps.JpsRuntimeException: java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=JPS,keyName=msad.ldap.credentials read) at oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModule.initializeLM(IdStoreLoginModule.java:663)
Unfortunately I was hit by the above error which didn’t fill me with joy.
I then added the additional parameters to the ODI_JAVA_OPTIONS variable in the odiparams script to turn on debugging.
"-Djps.auth.debug=true" "-Djps.auth.debug.verbose=true"
A large amount of errors were generated and it looks like the issue relates to java permissions on all the related packaged jars.
I decided to leave it there as there is the following bug on Oracle Support.
Bug 13255270: 'ACCESS DENIED...' ERROR WHEN STARING ODI STANDALONE AGENT WITH EXTERNAL AUTHENT
UPDATE : 25th April 2012
The bug in Oracle Support has been updated and I also got an anonymous comment on this blog entry from I assume the same person that has updated the bug.
I have removed my workaround as it was only temporary until a solution was available, hopefully the ODI documentation will be improved to reflect this.
First create a file called server.policy in the <ODI_HOME>\oracledi\agent\bin directory.
grant codeBase "file:${ODI_HOME}/../../-" {
permission oracle.security.jps.service.credstore.CredentialAccessPermission "context=SYSTEM,mapName=*,keyName=*", "read";
};
paste the above grant statement into the file.
grant codeBase "file:${ODI_HOME}/../../-" {
permission oracle.security.jps.service.credstore.CredentialAccessPermission "context=SYSTEM,mapName=JPS,keyName= msad.ldap.credentials", "read";
};
It is also possible to use the mapName and KeyName that are being used in the cwallet.sso file.
Edit odiparams.bat/sh and make sure ODI_HOME is set as an absolute path.
This could also be achieved by setting ODI_HOME as an environment variable instead of editing the file.
Also add the line
set ODI_ADDITIONAL_JAVA_OPTIONS=%ODI_ADDITIONAL_JAVA_OPTIONS% "-DODI_HOME=%ODI_HOME%"
The agent now starts up without any issues authenticating with the AD account.
Now if you want to take it one stage further and use OPMN to manage the agent and on windows create as a service then you could have a look at a previous blog I wrote on setting it up.
If you are going to use OPMN and go down the route outlined in the Oracle support document 1274484.1 or the equivalent Oracle by Example and install FMW 11g WebTier Utilities then
• You don’t need to install WebTier Utilities 11.1.1.2 as 11.1.1.6 can be used and is available from here
• When installing you don’t need to select Oracle Web Cache and can just select Oracle HTTP Server which will then install OPMN.
There are also a few things to watch out for when configuring OPMN to manage the agent with external authentication.
The configuration uses a template file in the agent\bin directory called odi_opmn_standaloneagent_template.xml
It is possible the usage of “./jps-config.xml” may be an issue when starting up the agent through OPMN as an error will be generated saying the file can’t be found, in this case the full path to jps-config.xml can be entered.
The configuration also defaults to a user name of SUPERVISOR so if you are using a different user for external authentication this will need to updated.
The changes can be made directly to the template file before adding the agent to OPMN or after adding the agent and updating opmn.xml which will be created in
<INSTANCE_HOME>\config\OPMN\opmn
Any changes to opmn.xml will require a full restart of OPMN.
Next time I will cover the steps to use external authentication with the J2EE agent and ODI console.
No comments:
Post a Comment
Note: only a member of this blog may post a comment.