Secured RMI/IIOP communication in between twi WebSphere application Servers

[dnvija...@gmail.com]

Hi,

I am trying to invoke a secured EJB (Session bean) deployed in a Websphere application server (say Server-B)
from another EJB, deployed in different WebSphere application Server (say Server-A). In Both servers, the Global security
is enabled and both the servers are using same LDAP server as User Registry.
The EJB Client (in Server-A) is configured to Run-As a role (say 'Admin') which has access to all the methods od the
Server EJB (in Server-B).

Now while invoking the Server EJB, I am getting following exception. From the exception stack tyrace,
it seems that the Security Credentials are not getting passed to Callere Application Server.

**********************************************************************************
NMSV0610I: A NamingException is being thrown from a javax.naming.Context implementation. Details follow:
Exception stack trace: javax.naming.NoPermissionException: NO_PERMISSION exception caught. Root exception is org.omg.CORBA.NO_PERMISSION:

Trace from server: 1198777258 at host mrbc2b4 >>
org.omg.CORBA.NO_PERMISSION: Subject is null. Authentication Failed. vmcid: 0x49424000 minor code: 300 completed: No
at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason.map_auth_fail_to_minor_code(PrincipalAuthFailReason.java:83)
at com.ibm.ISecurityLocalObjectBaseL13Impl.CSIServerRI.receive_request(CSIServerRI.java:2048)
**********************************************************************************

I guess the problem is to do with the CSIv2 Inbound and Outbound Authentication configuration in WebSphere Server.
Please could any one help me out if you have done the same previously?

You help would be much appreciated.

Environment Details:

Server (Both) - Websphere Application v 5.1
User Registry - IBm Directory Server (common for bothe servers)

[dnvijaykumar]

[Randy Schnier]

Are both servers part of the same WebSphere appserver cell? If not, you
will need to export the keys from Server-B's cell and import them into
Server-A's cell. Having both servers use the same user registry is not
sufficient by itself. Each cell has its own security server, and
communication between cells requires that the security servers have
access to each other's keys. The procedure for this is documented in
the WAS InfoCenter.

[dnvijaykumar]

Both the Servers are part of different cells.
does importing keys will override the exisitng ones?

[m.yase...@gmail.com]

I am facing a similar issue.<br />
My client is deployed on websphere portal 6 and ejb on underlying websphere application server. <br />
Please suggest as to what needs to be done in order to resolve the matter.<br />
Thanks in advance!<br />
<br />
**************************<br />
NMSV0610I: A NamingException is being thrown from a javax.naming.Context implementation. Details follow:<br />
Context implementation: com.ibm.ws.naming.jndicos.CNContextImpl<br />
Context method: lookupExt<br />
Context name: aug01/nodes/aug01/servers/server1<br />
Target name: INQUIRY_FACADE_JNDI<br />
Other data: ""<br />
Exception stack trace: javax.naming.NoPermissionException: NO_PERMISSION exception caught. Root exception is org.omg.CORBA.NO_PERMISSION: <br />
<br />
Trace from server: 1198777258 at host aug01wks150.xxx.com &gt;&gt;<br />
org.omg.CORBA.NO_PERMISSION: Subject is null. Authentication Failed. <br />
vmcid: 0x49424000 minor code: 300 completed: No<br />
<br />
at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason.map_auth_fail_to_minor_code(PrincipalAuthFailReason.java:83)<br />
**************************

[Paul Ilechko]

m.yase...@gmail.com wrote:
> Can anybody tell me what does "<b>org.omg.CORBA.NO_PERMISSION: Subject is null. Authentication Failed.</b>" mean?

Looks like you're trying to call a protected EJB but are not passing an
identity. Check your CSIv2 outbound propagation.

[m.yase...@gmail.com]

Can anybody tell me what does "<b>org.omg.CORBA.NO_PERMISSION: Subject is null. Authentication Failed.</b>" mean?

[jspe...@amig.com]

I pulled hair over this for weeks before getting it working. Even with no security on the ejb, once you turn on global security, the calling server must propagate it's identity via LTPA to the downstream server. This is configured using the CSIv2 security settings. the calling server must propagate identity and the downstream server must be configured to accept propagated identities from the upstream server.<br />
You must also sychronize the LTPA realm settings and the LTPA Keys between the servers.

[Paul Ilechko]

jspe...@amig.com wrote:
> I pulled hair over this for weeks before getting it working. Even with no security on the ejb, once you turn on global security, the calling server must propagate it's identity via LTPA to the downstream server. This is configured using the CSIv2 security settings. the calling server must propagate identity and the downstream server must be configured to accept propagated identities from the upstream server.<br />
> You must also sychronize the LTPA realm settings and the LTPA Keys between the servers.

Some of us think this is a bug ... you could try opening a PMR, but my
guess is you will get "working as designed" back from support.

[Paul Ilechko]

m.yase...@gmail.com wrote:
> <div class="jive-quote">Looks like you're trying to call a protected EJB but are not passing an <br/>
> identity. Check your CSIv2 outbound propagation.</div>
> <br />
> I have tried out the few changes with the CSIv2 inbound authentication settings.<br />
> But am still facing the same issue. Please help!!<br />
> Here are the settings for Authentication protocol in WAS<br />
> <br />

> Thanks in advance!!

What about Outbound on the sending side ?

[m.yase...@gmail.com]

<div class="jive-quote">Looks like you're trying to call a protected EJB but are not passing an <br/>
identity. Check your CSIv2 outbound propagation.</div>
<br />
I have tried out the few changes with the CSIv2 inbound authentication settings.<br />
But am still facing the same issue. Please help!!<br />
Here are the settings for Authentication protocol in WAS<br />
<br />

<b>CSIv2 inbound authentication</b> <br />
Basic authentication: Supported<br />
Client certificate authentication: Supported<br />
Identity assertion: checked<br />
Trusted servers: WebSphere_Portal<br />
Stateful sessions: checked<br />
Login configuration: RMI_INBOUND<br />
Security attribute propagation: checked<br />
<p />
<b>CSIv2 outbound authentication</b> <br />
Basic authentication: Supported<br />
Client certificate authentication: Never<br />
Identity assertion: <br />
Stateful sessions: checked<br />
Login configuration: RMI_INBOUND<br />
Custom outbound mapping <br />
Security attribute propagation <br />
Trusted target realms <br />
<br />
<b>CSIv2 inbound transport</b> <br />
Transport SSL-supported<br />
SSL settings: DefaultSSLSettings<br />
<br />
<b>CSIv2 outbound transport</b> <br />
Transport SSL-supported<br />
SSL settings: DefaultSSLSettings <br />

[m.yase...@gmail.com]

<div class="jive-quote">What about Outbound on the sending side ?</div>
<br />
This is exactly the question that struck to me when I first read about Inbound/Outbound settings.<br />
I have websphere portal 6 installed on my local, as we know portal cannot run without application server. The setup wizard at the time of setup asks us to provide the location of an existing instance of websphere application server otherwise it will install a fresh one.<br />
So I have both WPS 6 and WAS6 installed on my machine.<br />
(WAS admin console shows both <i>"<b>server1</b>"</i> and <i>"<b>WebSphere_Portal</b>"</i> servers in the <b>Servers &gt; Application servers</b> section)<br />
Now when I try to access an SLS EJB (deployed on WAS) from a portlet (deployed on WPS) I face the above mentioned issue. In this case my sending side is WPS and receiving end is WAS.

[m.yase...@gmail.com]

<div class="jive-quote"><span class="jive-quote-header">JSpencer wrote:</span><br />

I pulled hair over this for weeks before getting it working. Even with no security on the ejb, once you turn on global security, the calling server must propagate it's identity via LTPA to the downstream server. This is configured using the CSIv2 security settings. the calling server must propagate identity and the downstream server must be configured to accept propagated identities from the upstream server.<br/>

You must also sychronize the LTPA realm settings and the LTPA Keys between the servers.</div>
<br />
I am sure what you are saying is correct in cases where we have two different servers.<br />
But the fact is portal server cannot run without an app server, and it is on this underlying app server I have deployed my Stateless EJB. <br />
What is the problem if I make a call to this EJB from a portlet?<br />
Why portal server should propagate identity to its underlying app server?<br />
It even uses app server's authentication service for authenticating its users.<br />
Above all I am wondering where can I give outbound settings for portal server as because it has to use the underlying app server for making these settings.

[Paul Ilechko]

Do you have two separate cells? If so, are they sharing the same
registry? How you shared LTPA keys between them? And have you configured
Inbound and Outbound CSIv2 in both sides?

[Paul Ilechko]

You should not have to do anything with CSIv2 to call an EJB in the same
appserver process. I thought from your other post that you had a
Portal server on one WAS talking to an EJB in a different WAS install.

[Jeff Spencer]

My test environment consisted of a 5.1 portal server test environment with Global security using LDAP, and a standard WAS 5.1 server hosting the EJBs. As soon as global security isenabled on the EJB server, the CORBA NO_PERMISSION error occurs. After CSIv2 assertion/propagation setup on both sides is configured and the LTPA key is exported from the Portal WAS server and imported to the EJB server it all works.<br />
Try replacing the trusted servers entry with a "*". I could not get this working with a server name for this value. It is supposed to contain identity, not name.

[Jeff Spencer]

I don't think your EJB is running on the underlying server for portal. It appears to be running on server1 while portal is probably Websphere_portal. They are 2 separate appservers running on the same WAS install.

[m.yase...@gmail.com]

<div class="jive-quote"><span class="jive-quote-header">JSpencer wrote:</span><br />

My test environment consisted of a 5.1 portal server test environment with Global security using LDAP, and a standard WAS 5.1 server hosting the EJBs. As soon as global security isenabled on the EJB server, the CORBA NO_PERMISSION error occurs. After CSIv2 assertion/propagation setup on both sides is configured and the LTPA key is exported from the Portal WAS server and imported to the EJB server it all works.<br />

Try replacing the trusted servers entry with a "*". I could not get this working with a server name for this value. It is supposed to contain identity, not name.</div>
<br />
Surely I will try this couldn't work it out today.

[Jeff Spencer]

Are you using a full portal install or Portal UTE. What version?<br />
Portal install as an Enterprise Application. Your EJBs are installed as a separate Enterprise Application. If you look at the logs from thes 2 apps on startup you will see they are in separate containers.

[m.yase...@gmail.com]

<div class="jive-quote">You should not have to do anything with CSIv2 to call an EJB in the same <br />
appserver process. I thought from your other post that you had a <br />
Portal server on one WAS talking to an EJB in a different WAS install.</div>
<br />
Then why am I facing this problem? <img class="jive-emoticon" border="0" src="images/emoticons/sad.gif" alt=":("><br />
Please suggest!!

[m.yase...@gmail.com]

<div class="jive-quote">Do you have two separate cells? <br /> </div>
Yes<br />
<br />
<div class="jive-quote">If so, are they sharing the same registry? <br /> </div>
Yes<br />
<br />
<div class="jive-quote">How you shared LTPA keys between them? And have you configured <br />
Inbound and Outbound CSIv2 in both sides? <br /> </div>
I havent made any configuration changes. The portal gets automatically installed in the manner that it uses the application server for deployment of any ejb or web applications whereas portlets are deployed on portal server. This means portal server is not an app server in itself.

[m.yase...@gmail.com]

<div class="jive-quote"><span class="jive-quote-header">JSpencer wrote:</span><br />

Are you using a full portal install or Portal UTE. What version?<br/></div>
Full install version 6.0 <br />
<div class="jive-quote">Portal install as an Enterprise Application. Your EJBs are installed as a separate Enterprise Application. If you look at the logs from thes 2 apps on startup you will see they are in separate containers.</div>
Exactly!!

[Jeff Spencer]

Are you still stuck on this? If you call me at 5139475847 I will try to help.