Yesterday I discovered an extremely neat feature of Business Process Explorer: The "view process state" function. It displays a SVG graphics resembling the business process diagram designed in the Websphere Integration Developer. What's more - it also marks the current state of the business process instance. That's useful if you'd like to know where your process hangs (if yours ever hangs indeed...).
However today I encountered some trouble viewing these graphics. Not only the "view process state" function produced errors but also the "view structure" function with process templates. In Firefox, a yellow field occurred saying there was an error in the underlying XML. On the server console, the following error message was visible:
java.security.AccessControlException: Access denied (java.lang.RuntimePermission exitVM)
If you should run into the same trouble, here's one tip: restart your server in 'Run' mode instead of 'debug" mode! Funny but true, the SVG export does not work in debug mode...
Best regards,
Matthias
Wednesday, February 13, 2008
Switching the Websphere log language
The fact that IBM translated all their log messages into German is actually very nice of them. However, I'm not really pleased with it because you won't find anything on the web when searching for German error messages. Hence, reverting to Englisch messages would be desirable but as it seems there's no switch in the Websphere admin console saying "change log language"...
So here's a kind of brutal but effective approach to change the log language of a Websphere Application Server:
Matthias
So here's a kind of brutal but effective approach to change the log language of a Websphere Application Server:
- In the admin console navigate to your server.
- In the section "Server Infrastructure", expand the node "Java and Process Management" and click "Process Definition".
- In the section "Additional Properties", click "Java Virtual Machine".
- To the "Generic JVM arguments", add the following argument: "-Duser.language=US"
Matthias
Thursday, February 7, 2008
Accessing secured EJBs on Websphere 6.1 from a standalone ("thin") client
Trying to access a secured EJB on Websphere can give you a hard time, especially if you want do so in a standalone Java client. It's not just a simple matter of creating an InitalContext with appropriate security credentials and hoping that the server will propagate the security context to the EJB container.
Basically, I wanted to access the HumanTaskManager deployed on a Websphere Process Server 6.1 instance from a standalone Java client in order to simulate task completion without human intervention.
The HumanTaskManager is implemented as a 2.1 Enterprise Java Bean. To access and use it you have to follow the standard procedure outlined below:
java.rmi.AccessException: CORBA NO_PERMISSION 0x0 No; nested exception is:
org.omg.CORBA.NO_PERMISSION:
>> SERVER (id=4773e3aa, host=XXX.highq-it.de) TRACE START:
>> org.omg.CORBA.NO_PERMISSION: java.rmi.AccessException: ; nested exception is:
com.ibm.websphere.csi.CSIAccessException: SECJ0053E: Authentifizierung für /UNAUTHENTICATED beim Aufrufen von (Bean)com/ibm/task/api/HumanTaskManagerHome query(java.lang.String,java.lang.String,java.lang.String,java.lang.Integer,java.util.TimeZone):1 securityName: /UNAUTHENTICATED;accessID: UNAUTHENTICATED is not granted any of the required roles: TaskAPIUser fehlgeschlagen
An odyssee through the depths of the world wide web began before I had finally gathered the information to get the client to work. To make a long story short: You have to write a programmatic login using JAAS and set the authenticated subject as default subject on the current thread. Furthermore, you have to ensure that your program has the correct Java Runtime, i.e. the correct libraries available and is configured appropriately using JVM arguments.
My method that performs the JAAS login looks as follows:
public void login(String userName, String password) throws LoginException, WSSecurityException, NamingException {
InitialContext ctx = getInitialContext(); // standard procedure
ctx.lookup("");
lc = new LoginContext("WSLogin",
new WSCallbackHandlerImpl(userName, password));
lc.login();
subject = lc.getSubject();
WSSubject.setRunAsSubject(subject);
}
The InitialContext can be created in the standard way, using the correct InitialContextFactory (normally com.ibm.websphere.naming.WsnInitialContextFactory) and provider url (in my case corbaloc:iiop:localhost:2809).
The default lookup ctx.lookup("") is performed so that the target security realm and bootstrap host/port is determined automatically for SecurityServer lookup (see example in http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/tsec_pacs.html).
The line WSSubject.setRunAsSubject(subject); sets the previously authenticated subject as the J2EE "run as" identitity on the current thread meaning that all subsequent J2EE calls in the same thread will use this subject for authorization checks.
To get the login process to work, I also included the libraries of the target server runtime in the classpath of the Java program. For more information on how to include only client-specific libraries, please use the above URL as a starting point. Since I am using the Websphere Integration Developer, the easiest way to ensure the correct runtime environment was to add the System JRE of the Websphere Process Server on which the target EJB is running.
Furthermore, the following JVM args had to be added to the program:
-Djava.security.auth.login.config=\pf\wps\properties\wsjaas_client.conf -Dcom.ibm.CORBA.ConfigURL=file:\pf\wps\properties\sas.client.props
This is to pass the information of the used login and SSL/CSI configuration to the program. See http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0221.html?Open and http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/tsec_j2clogin.html for more information on this.
At this point, I encountered another exception which made me getting a bit frustrated in the end:
Forwarded IOR failed with: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET Exception=com.ibm.websphere.ssl.SSLException: Missing SSL client config properties.
Finally, a note on http://www-1.ibm.com/support/docview.wss?uid=swg21238509 made me feel easy. In Websphere 6.1, it is also necessary to pass the location of a file called ssl.client.props to the JVM:
-Dcom.ibm.SSL.ConfigURL=file:pf\wps\properties\ssl.client.props
Hope this helps...
Matthias
PS: Yet another helpful piece of information: In the IBM techdocs, a standlalone Java client is refererred to as "thin client".
Basically, I wanted to access the HumanTaskManager deployed on a Websphere Process Server 6.1 instance from a standalone Java client in order to simulate task completion without human intervention.
The HumanTaskManager is implemented as a 2.1 Enterprise Java Bean. To access and use it you have to follow the standard procedure outlined below:
- Create a JNDI InitialContext.
- Look up the EJB Home.
- Invoke one of the create() methods on the EJB home to create an instance of the target EJB.
- Invoke the desired business methods on the previously created EJB instance.
java.rmi.AccessException: CORBA NO_PERMISSION 0x0 No; nested exception is:
org.omg.CORBA.NO_PERMISSION:
>> SERVER (id=4773e3aa, host=XXX.highq-it.de) TRACE START:
>> org.omg.CORBA.NO_PERMISSION: java.rmi.AccessException: ; nested exception is:
com.ibm.websphere.csi.CSIAccessException: SECJ0053E: Authentifizierung für /UNAUTHENTICATED beim Aufrufen von (Bean)com/ibm/task/api/HumanTaskManagerHome query(java.lang.String,java.lang.String,java.lang.String,java.lang.Integer,java.util.TimeZone):1 securityName: /UNAUTHENTICATED;accessID: UNAUTHENTICATED is not granted any of the required roles: TaskAPIUser fehlgeschlagen
An odyssee through the depths of the world wide web began before I had finally gathered the information to get the client to work. To make a long story short: You have to write a programmatic login using JAAS and set the authenticated subject as default subject on the current thread. Furthermore, you have to ensure that your program has the correct Java Runtime, i.e. the correct libraries available and is configured appropriately using JVM arguments.
My method that performs the JAAS login looks as follows:
public void login(String userName, String password) throws LoginException, WSSecurityException, NamingException {
InitialContext ctx = getInitialContext(); // standard procedure
ctx.lookup("");
lc = new LoginContext("WSLogin",
new WSCallbackHandlerImpl(userName, password));
lc.login();
subject = lc.getSubject();
WSSubject.setRunAsSubject(subject);
}
The InitialContext can be created in the standard way, using the correct InitialContextFactory (normally com.ibm.websphere.naming.WsnInitialContextFactory) and provider url (in my case corbaloc:iiop:localhost:2809).
The default lookup ctx.lookup("") is performed so that the target security realm and bootstrap host/port is determined automatically for SecurityServer lookup (see example in http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/tsec_pacs.html).
The line WSSubject.setRunAsSubject(subject); sets the previously authenticated subject as the J2EE "run as" identitity on the current thread meaning that all subsequent J2EE calls in the same thread will use this subject for authorization checks.
To get the login process to work, I also included the libraries of the target server runtime in the classpath of the Java program. For more information on how to include only client-specific libraries, please use the above URL as a starting point. Since I am using the Websphere Integration Developer, the easiest way to ensure the correct runtime environment was to add the System JRE of the Websphere Process Server on which the target EJB is running.
Furthermore, the following JVM args had to be added to the program:
-Djava.security.auth.login.config=
This is to pass the information of the used login and SSL/CSI configuration to the program. See http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0221.html?Open and http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.base.doc/info/aes/ae/tsec_j2clogin.html for more information on this.
At this point, I encountered another exception which made me getting a bit frustrated in the end:
Forwarded IOR failed with: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET Exception=com.ibm.websphere.ssl.SSLException: Missing SSL client config properties.
Finally, a note on http://www-1.ibm.com/support/docview.wss?uid=swg21238509 made me feel easy. In Websphere 6.1, it is also necessary to pass the location of a file called ssl.client.props to the JVM:
-Dcom.ibm.SSL.ConfigURL=file:
Hope this helps...
Matthias
PS: Yet another helpful piece of information: In the IBM techdocs, a standlalone Java client is refererred to as "thin client".
Subscribe to:
Posts (Atom)