Search This Blog

Wednesday 30 July 2008

Enable Remote Clients To Access OAS 10.1.3.x Server-Side JNDI Context From Deployed Applications

In order for remote clients to access a OAS 10.1.3.x JNDI Server-Side context they must authenticate with the server prior to doing a look up. Here is how to enable such access from a remote J2SE client and what setup steps are required to achieve this for deployed applications, thus avoiding using privileged users such as oc4jadmin.

This example is based on JAZN-XML security provider at the instance level.

1. Log into Application Server Console (ASC).
2. Click on your container you wish to use.
3. Click on administration link.
4. Click on the icon for the security task with a description as follows -> "Configure security providers, create/delete/view users and roles".

Here we will just use "Instance" level security which will enable this user we create to be used by all applications within this instance.

5. Click on the button "Instance Level Security".
6. Click on the link "Realms".
7. You will see a column called "Users" which will have an amount of users, simple click on the amount to go to the next screen.
8. Click on the "Create" button.
9. Enter the following.

Name - test
Password - test123
Confirm Password - test123
Shuttle Across "users" to the "Selected Roles" Area

Note: You can create your own role but you must make sure you set the check box "Grant RMI Login Permission". We are using the "users" role as that has been done already for us.

10. Press OK.

So the user we want to use will be "test" with a password as "test123", with this in place we now must grant access to the JNDI context to the correct group so that remote users which are part of this group can access the JNDI resource. This is done as shown below within a deployment descriptor for each deployed application which contains JNDI objects such as a Data Source or an EJB. The file is placed within a META-INF directory of an EAR file.

orion-application.xml


<?xml version = '1.0' encoding = 'windows-1252'?>
<orion-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-application-10_0.xsd">
<namespace-access>
<read-access>
<namespace-resource root="">
<security-role-mapping>
<group name="users" />
</security-role-mapping>
</namespace-resource>
</read-access>
<write-access>
<namespace-resource root="">
<security-role-mapping>
<group name="users" />
</security-role-mapping>
</namespace-resource>
</write-access>
</namespace-access>
</orion-application>


As you can see the namespace-access has been setup to allow users which are part of the role "users" access to the JNDI Server-Side context for the deployed application.

So with a deployment descriptor added to my application named "pastest" and deployed, I can then perform a JNDI look up of resources within that application as the user "test" as shown below.

private Context getInitialContext() throws NamingException
{
Hashtable env = new Hashtable();
// Standalone OC4J connection details
env.put( Context.INITIAL_CONTEXT_FACTORY,
"oracle.j2ee.rmi.RMIInitialContextFactory" );
env.put( Context.SECURITY_PRINCIPAL, "test" );
env.put( Context.SECURITY_CREDENTIALS, "test123" );
env.put(Context.PROVIDER_URL, "ormi://localhost:23791/pastest");

return new InitialContext( env );
}


For more information see the documentation below.

Oracle® Containers for J2EE Security Guide
10g (10.1.3.1.0)
Part Number B28957-01
http://download.oracle.com/docs/cd/B31017_01/web.1013/b28957/loginmod.htm#BABIICGC

1 comment:

Anonymous said...

Just wanted to say that, if you're trying to reach JNDI on OAS without tying it to a specific application, the OPMN URL you specified looks more like

opmn:ormi://<hostname>:6003:<instance>/

And instead of modifying the orion-application.xml deployed with the specific application, you will have to modify

<OC4J_HOME>/j2ee/home/config/system-application.xml

which is in actuality a system-level orion-application.xml file, complete with <namespace-access> tags and everything.

Just add a <namespace-access><read-access><namespace-resource root=""><security-role-mapping><group name="users"/>... to the this file, and then any instance-level user in the users group will be able to do JNDI lookups, etc.