Security between two jvm using JNDI

[Former Member]

Hi ,

I want to access the UME service of the SAP J2EE Container using a stanalone client application.

So the client would be running on remote JVM.

Here we use the JNDI service to communicate between the client and server.

p.put(Context.INITIAL_CONTEXT_FACTORY,"com.sap.engine.services.jndi.InitialContextFactoryImpl");

p.put(Context.PROVIDER_URL, providerURL.trim());

p.put(Context.SECURITY_PRINCIPAL, securityPrinciple.trim());

p.put(Context.SECURITY_CREDENTIALS, securityCredentials.trim());

Context ctx = (Context) new InitialContext(p);

Object objRef = ctx.lookup(ejbName.trim());

I want to know that is the communication between the client and server secured in this scenario

Best Regards

Manoj

[Former Member · Accepted solution]

Normally JNDI has have different providers for communication.

->Lightweight Directory Access Protocol (LDAP)

->Common Object Request Broker Architecture (CORBA) Common Object Services (COS) name service

->Java Remote Method Invocation (RMI) Registry

It can be any one of this

regards

Vivek Nidhi

[Former Member · Accepted solution]

Hi Vivek,

Thanks for the response.

Imageine if RMI was used internally by the JNDI ,then is the communication secured.

When we pass the crendenatials to the initalcontext ,we pass the username and password.

Now is this data send as plain text to the JNDI port in case of SAP or is it encrypted by SAP.

UserName/Password

Client M/c -

---

> Remote SAP Server

JNDI

Best Regards

Manoj

[Former Member · Accepted solution]

Hi,

Java Remote Method Invocation by default does not support authenticated and encrypted transport.

That is, objects sent over the network are not encrypted.

A firewall can be used to secure a Java RMI application. Here, the firewall must allow access to specifically known ports. That is, these ports cannot be denied access by the firewall. SOCKS provides a partial solution to the use of RMI through firewalls in that it protects outgoing RMI calls, but incoming RMI calls as well as RMI call-backs are not protected.

This may be overcome by using bi-directional RMI implementation through the firewalls. However, it requires the use of specific settings that can relax the security or application level proxy servers, thus increasing the administrative overheads. Also, changing the security policy to allow bi directional RMI traffic should only be done with extreme care. A better solution towards securing RMI is by means of supporting authenticated and encrypted transport, so that a network attacker cannot alter data on communication. This can be achieved by running RMI on SSL.

regards

Vivek Nidhi