EJB -call from WAS 5 server without, to a WAS 6 server with global security

walter....@logicacmg.com

unread,

Apr 8, 2008, 4:22:32 AM4/8/08

to

Hi, 
 
I am trying to call an EJB method on a WAS6 server with global security from a WAS5 server without global security. I followed the <a class="jive-link-external" href="http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/csec_programlog.html">Programmatic login example</a>, which works fine from a pure java command-line client. I made a servlet and tried the same within the WAS5 container, but now it fails. 
 
I specified the SecurityServer in the sas.client.props file (which has no use I suspect...): 
 
System.setProperty("com.ibm.CORBA.ConfigURL", 
"file:/C:/WasProfiles/Was6/properties/sas.client.props"); 
 
I performed an InitialContext and default lookup prior to logging in, to initialize ORB security and for the bootstrap host/port to be determined for SecurityServer lookup: 
 
final Properties env = new Properties(); 
env.setProperty(Context.INITIAL_CONTEXT_FACTORY, 
INITIAL_CONTEXT_FACTORY); 
env.setProperty(Context.PROVIDER_URL, PROVIDER_URL); 
final Context ctx = new InitialContext(env); 
 
I use the folowing code to login: 
 
LoginContext lc = null; 
Subject subject = null; 
try { 
lc = new LoginContext("WSLogin", new WSCallbackHandlerImpl( 
+ "user", "password"));+ 
lc.login(); 
subject = lc.getSubject(); 
} catch (LoginException e) { 
e.printStackTrace(writer); 
} 
if (subject.getPrincipals().isEmpty()) { 
writer.println("No principals found!"); 
} 
 
But the subject returned after the login does not contain any principals as it did in the command-line version. 
 
Is it possible to get a valid subject in his scenario using the WAS6 server as the security server? Or is is impossible as long as I don't use global security on the WAS5 server? 
 
Tanks, 
 
Walter

Paul Ilechko

unread,

Apr 8, 2008, 9:13:28 AM4/8/08

to

You're logging in to the WAS 5 server, not to the WAS 6 server, by the
looks of it. You need to explicitly login to the remote server, just as
you would from a client. The WAS 5 server is not secured, and so will
not pass any credentials to the remote server.

Walter de Boer

unread,

Apr 9, 2008, 3:08:25 AM4/9/08

to

Paul, 
 
Thanks for your answer. I can confirm that an attempt is made to log on to the WAS5 server instead of the WAS6 server which is required. But how do I make it go to the WAS6 server? Note, the WAS6 server does not provide a web interface with a login-page. It is just a back-office system which provides some EJB's. That is why I tried the programmatic login example. 
 
As I understand from the IBM documentation, I have to "perform an InitialContext and default lookup prior to logging in, to initialize ORB security and for the bootstrap host/port to be determined for SecurityServer lookup". The PROVIDER_URL in the code-example contains a valid reference to the WAS6 server/port, so I would assume a login is done on the WAS6 server. In the command-line client this is the case, but in the servlet it is not. What is the difference? 
 
Walter

Paul Ilechko

unread,

Apr 9, 2008, 9:08:19 AM4/9/08

to

After the login, before you check for principals, do a
WSSubject.doAs(lc.getSubject()), instead of subject = lc.getSubject()

Walter de Boer

unread,

Apr 10, 2008, 3:44:04 AM4/10/08

to

Unfortunately this does not work. I need 2 parameters for WSSubject.doAs(), a Subject and a PrivilegedAction. 
 
When I check the <a class="jive-link-external" href="http://www.ibm.com/developerworks/websphere/library/techarticles/0702_kovari/0702_kovari.html">login scenarios</a> described by Peter Kovari, there is no scenario with a server without global security talking to a server with global security. I suspect that I need to turn on global security on both servers an let them talk through CSIv2 to make it work. I don't see any way around it....

peter....@uk.ibm.com

unread,

Apr 10, 2008, 5:45:48 AM4/10/08

to

Hi, 
I have not tried the scenario you described between the V5 and V6 versions of WebSphere sendng server being without global security enabled. I got a few pointers and ideas that may help you if you are willing to try: 
 
<ul class="jive-dash">
<li>I suspect that something is not right on the sending side as you have not got the subject expected.</li>
</ul>
Try to do a test using Paul's recommendation with the doAs and provide a PrivilegedAction implementation. In the implementation fetch the currently used subject and explore the object there. You can find the code attached to my article about how to implement this test - check the server-side login part for the code snippets. 
 
<ul class="jive-dash">
<li>Need to look at the error message (I assume there is one) from the target (WASv6) server's log (or trace even better) and look for the reasons of failure. You may have useful error messages on the sending server side as well. BTW, send us the error messages if you can, if it is too long, just e-mail me directly.
<ul class="jive-dash">
<li>It is possible that you have a Java version mismatch problem as RMI/IIOP with CSIv2 is quite sensitive to the different version levels of Java, however the fact that the client container code worked (I assume the client was running in a WASv5 environment) suggests that Java levels are working fine with each other.</li>
<li>There could be many other reasons why the communication fails, without looking at the log, it is difficult to tell what is failing.</li>
</ul>
</li>
</ul>
 
<ul class="jive-dash">
<li>Check a few configuration details
<ul class="jive-dash">
<li>make sure that the target server trusts the sending server - there is a section about this configuration in my article.</li>
<li>make sure that the encryption configurations are correct on both sides (i.e. both server supports the same encryption mechanisms) If you left those to default, then they should just work.</li>
</ul>
</li>
</ul>
 
<ul class="jive-dash">
<li>I have read the followup comments in this thread, and I think there are a few things that may need clarification.
<ul class="jive-dash">
<li>Logging in to/on/for the target server does not involve any pre-invocation communication between the parties. The login information has to be built/created and sent together with the invocation. (It is like travelling with your passport (subject) and the visa (principal) in it; you will not know if you pass the border until you get there and they check the passport and the visa)</li>
<li>You should be able to create a Subject for the invocation with all the right info (i.e. security realm (for the target server), principal (based on the identity), credentials (password))</li>
<li>As for the password, I assume from the code you chose to perform an login (with uid, password) rather than identity assertion (trusted user, trusted password, effective user). This should be the simpler solution compared to identity assertion or other custom logins (e.g. attribute propagation); this should work.</li>
</ul>
</li>
</ul>

Walter de Boer

unread,

Apr 10, 2008, 4:45:18 PM4/10/08

to

Peter, 
 
Thanks for your answer. 
 
First of all, would like to use identity assertion. But I am under the impression that I have to enable Global Security on the sending server as well for this to work. Are you telling me that CSIv2 is also used when Global Security is not enabled? I did not enable Global Security on the sending server, because this effects other applications on the server. 
 
I will take a look at it again on monday and I will supply the information from the log-files then. 
 
Walter

Paul Ilechko

unread,

Apr 11, 2008, 8:24:17 AM4/11/08

to

Enabling global security should not affect applications. If they have no
constraints defined, nothing should change. However, by *not* enabling
it, anyone can get to your admin console and make system changes, which
is really not a good thing.

Walter de Boer

unread,

Apr 15, 2008, 7:21:59 AM4/15/08

to

Unfortunately the application server is not under my control, so enabling global security on the WAS5 server is not an option. I am still wondering if CSIv2 is being used, if one of the servers has global security disabled.

Walter de Boer

unread,

Apr 15, 2008, 8:14:37 AM4/15/08

to

CSIv2 inbound authentication. (I composed something like cn=server1,dc=hostname,dc=domain,dc=com for the server ID. I hope this is correct). I didn't do anything for encryption configurations.

As for Java version mismatch problems, the sending server also is a V6 actually in my test scenario. It will be a V5 server in the end, but this should not be a problem now.

I am not sure how to create a Subject for the invocation with all the right info. Is there another way than using a LoginContext? I would expect that lc.login(); is performing a login on the target server, since I "performed an InitialContext and default lookup prior to logging in" first, as described in the programmatic login example. However I think a login is performed on the sending server and since Global Security is not enabled there, I get a subject with no principals. (I tried a login with a wrong user name and password also and I get the same result). I also checked logs and trace after the lc.login, and I noticed that nothing was recorded on the target server.

I am calling the EJB method in a PrivilegedAction, as shown in the programmatic login example:

// create action to access the protected bean method

java.security.PrivilegedAction createDossierId = new java.security.PrivilegedAction() {

public Object run() {

Long id = null;

try {

Object obj = ctx

.lookup(CONTEXT_ROOT

+ "ejb/.../.../DossierServiceRemoteHome");

DossierServiceRemoteHome home = (DossierServiceRemoteHome) PortableRemoteObject

.narrow(obj, DossierServiceRemoteHome.class);

DossierServiceRemote dossierServiceRemote = home.create();

id = dossierServiceRemote.createDossierId();

} catch (... ) {

...

}

return id;

}

};

// invoke the secure action using the created subject

Long id = (Long) com.ibm.websphere.security.auth.WSSubject

.doAs(subject, createDossierId);

The SystemOut.log on the target server contains the following lines:

4/15/08 13:20:59:657 CEST 00000061 RoleBasedAuth A SECJ0305I: The role-based authorization check failed

for admin-authz operation Server:getName. The user UNAUTHENTICATED (unique ID: UNAUTHENTICATED) was not

granted any of the following required roles: administrator, operator, configurator, monitor.

4/15/08 13:40:59:844 CEST 00000069 RoleBasedAuth E SECJ0306E: No received or invocation credential

exist on the thread. The Role based authorization check will not have an accessId of the caller to

check. The parameters are: access check method getName on resource Server and module Server. The stack

trace is java.lang.Exception: Invocation and received credentials are both null

at com.ibm.ws.security.role.RoleBasedAuthorizerImpl.checkAccess(RoleBasedAuthorize rImpl.java:251)

at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1799)

at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1706)

at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1636)

at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1609)

at com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:590)
at com.ibm.ws.management.connector.AdminServiceDelegator.getAttribute(AdminService Delegator.java:117)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.ja va(Compiled Code))

at java.lang.reflect.Method.invoke(Method.java(Compiled Code))

at com.ibm.ws.management.connector.soap.SOAPConnector.invoke(SOAPConnector.java:34 5)

at com.ibm.ws.management.connector.soap.SOAPConnector.service(SOAPConnector.java:2 10)

at com.ibm.ws.management.connector.soap.SOAPConnection.handleRequest(SOAPConnectio n.java:55)

at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:680)

at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:484)

at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java(Compiled Code))

.

4/15/08 13:40:59:860 CEST 00000069 RoleBasedAuth A SECJ0305I: The role-based authorization check failed for admin-authz operation Server:getName. The user UNAUTHENTICATED (unique ID: UNAUTHENTICATED) was not granted any of the following required roles: administrator, operator, configurator, monitor.

At the client-side I receive the following stack-trace:

javax.naming.NamingException: Error during resolve. Root exception is org.omg.CORBA.NO_IMPLEMENT: No

available target vmcid: 0x49421000 minor code: 40 completed: No

at com.ibm.ws.cluster.router.selection.SelectionManager.getTarget(SelectionManager .java:264)

at com.ibm.ws.cluster.router.selection.WLMClientForCommonRouterImpl.

getNextTarget(WLMClientForCommonRouterImpl.java:221)

at com.ibm.ws.wlm.client.WLMClient.getNextTarget(WLMClient.java:187)

at com.ibm.rmi.corba.ClientDelegate._createRequest_WLM(ClientDelegate.java:1990)

org.omg.CORBA.NO_PERMISSION: java.rmi.AccessException: ; nested exception is:

com.ibm.websphere.csi.CSIAccessException: SECJ0053E: Authorization failed for /UNAUTHENTICATED

while invoking (Home)ejb/com/xxxx/xxxx/xxxx/ejb/DossierServiceRemoteHome create:2

securityName: /UNAUTHENTICATED;accessID: UNAUTHENTICATED is not granted any of the required roles:

AeosUser vmcid: 0x0 minor code: 0 completed: No

at com.ibm.ws.security.core.SecurityCollaborator.performAuthorization(SecurityColl aborator.java:490)

at com.ibm.ws.security.core.EJSSecurityCollaborator.preInvoke(EJSSecurityCollabora tor.java:193)

at com.ibm.ejs.container.EJSContainer.preInvokeForStatelessSessionCreate(EJSContai ner.java:3601)

at com.ibm.ejs.container.EJSContainer.preInvoke(EJSContainer.java:2813)

at com.xxxx.xxxx.xxxx.ejb.EJSRemoteStatelessDossierServiceHome_9d61e50f.create(Unk nown Source)

at com.xxxx.xxxx.xxxx.ejb._EJSRemoteStatelessDossierServiceHome_9d61e50f_Tie.

create(_EJSRemoteStatelessDossierServiceHome_9d61e50f_Tie.java:161)

at com.xxxx.xxxx.xxxx.ejb._EJSRemoteStatelessDossierServiceHome_9d61e50f_Tie.

_invoke(_EJSRemoteStatelessDossierServiceHome_9d61e50f_Tie.java:86)

at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:610 )

at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:463)

at com.ibm.rmi.iiop.ORB.process(ORB.java:439)

at com.ibm.CORBA.iiop.ORB.process(ORB.java:1737)

at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2260)

at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:65)

at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:95)