In Glassfish v2 I secure my JNDI lookups by enabling the "IIOP Client Authentication" checkbox in the admin console under the ORB node.
In my standalone client I then perform a "ProgrammaticLogin", which then allows me to do JNDI lookups.
In Glassfish v3 however, I get this error if want to do any JNDI lookups in the same setup:
18.08.2010 14:31:10 com.sun.enterprise.transaction.JavaEETransactionManagerSimplified
initDelegates INFO: Using
com.sun.enterprise.transaction.jts.JavaEETransactionManagerJTSDelegate
as the delegate
org.omg.CORBA.NO_PERMISSION:
----------BEGIN server-side stack trace----------
org.omg.CORBA.NO_PERMISSION:
vmcid: 0x0
minor code: 0
completed: No
I am pretty sure the "ProgrammaticLogin" works in general, since it allows me to do remote method calls on my secured EJB's (using @RolesAllowed
but if the IIOP Client Auth is turned off).
The user I login with is a simple user that I created for the "file" realm.
Any ideas, why the ProgrammticLogin fails to work in Glassfish v3 for authorizing JNDI lookups?
Or what is the correct way to authenticate with the ORB from a standalone client; for this purpose?
If the GlassFish Server instance on which the application client is deployed participates in a cluster, the ACC finds all currently active IIOP endpoints in the cluster automatically. However, a client should have at least two endpoints specified for bootstrapping purposes, in case one of the endpoints has failed.
During application client module deployment, the GlassFish Server generates a single facade JAR for the application client. The appclient script supports splash screens inside the application client JAR only if you launch an application client facade or appclient client JAR.
This typically occurs when the client refers to an EJB component that requires authorization or when annotations in the client’s main class trigger injection which, in turn, requires contact with the GlassFish Server’s naming service. To authenticate the end user, the ACC prompts for any required information, such as a username and password.
JMS resources are supported only in the full GlassFish Server, not in the Web Profile. See Using the Java Message Service. The Application Client Container (ACC) includes a set of Java classes, libraries, and other files that are required for and distributed with Java client programs that execute in their own Java Virtual Machine (JVM).
Did you make sure appserv-rt.jar is on your classpath? It is part of every glassfish3 installation e.g. at my installation it is located here:
/opt/glassfish3/glassfish/lib
This is very important. It contains some client java classes especially: AppclientIIOPInterceptorFactory.
These add a SecClientRequestInterceptor to the ORB which cares that the username and password is added to the GIOP request sent to the server.
It took me about two days of scanning the source code of glassfish and sniffing the corba packages on the wire with wireshark until I found this.
An example how to secure a bean and write a real Java EE client can be found here: http://download.oracle.com/docs/cd/E19798-01/821-1841/bnbzk/index.html
Hope this helps Manuel
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With