It looks like several of us are all working on the same problem and having the
same difficulties. I have seen many partial answers and many partial code
examples and I have read just about everything there is on this topic yet I
cannot get it to work either.
As I understand that there are 2 ways for getting a Java client in another JVM
to authenticate so that it can access public, secured methods of an EJB running
on JBoss. 1) use the LoginContext way OR 2) use the slick, but not
J2EE-standard, JNDI way. It appears in either case, the path is treacherous
notwithstanding all the effort that has gone into trying to produce a very
simple, complete, durable, useful, and correct example of each technique.
The LoginContext way:
The LoginContext way is technically the "proper" JAAS way to do the login. You
need two primary lines of code
LoginContext lc = new LoginContext(String clientLoginModuleName,new
UsernamePasswordHandler(String username, char[] password));
| lc.login();
Those lines being a bit generic, here are the real ones I'm using. They are
based on the exact same security domain configuration as the "jmx-console"
domain that ships with JBoss:
LoginContext lc = new LoginContext("spoonware",new
UsernamePasswordHandler("admin","admin".toCharArray()));
| lc.login();
The new LoginContext() is expecting to be told the name of the client login
module and the username/password credentials in a CallbackHandler of some sort.
(There have been several different ones presented in several examples but I
still can't get them working which continues to suggest that I've got something
configured incorrectly or not at all on the client.)
With a little new LoginContext() and a login() method call, the examples say
that you should get logged in. Or do they? It seems that you don't really get
logged in. Instead, your credentials get associated with the thread your
program is running on. Any subsequent calls you make to an EJB will present
those credentials so that the security-domain configured for that EJB will be
consulted to see if those credentials match the user.properties file. If so, a
Principal is created (I think) and its roles are granted and off the client
goes on its merry way interacting with the EJBs to the limit of its access.
The JNDI way:
Not being much of a Java programmer to begin with, I look for the
"configuration-oriented" approach to avoid writing code. Although the JNDI
approach is not J2EE spec, it's handy and at the moment I'd be happy with ANY
method of authentication that works and I'll stand on ceremony later. By
studying this approach I have found that the following code example should work
but does not.
In my client code, I have the following:
Properties props = new Properties();
| props.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jboss.security.jndi.LoginInitialContextFactory");
| props.put(Context.PROVIDER_URL, "localhost:1099");
| props.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
| props.put(Context.SECURITY_PRINCIPAL,"admin");
| props.put(Context.SECURITY_CREDENTIALS,"admin");
| props.put(Context.SECURITY_PROTOCOL,"client-login");
| Context ctx = new InitialContext(props);
One important point that is easy to overlook is that the name of the
INITIAL_CONTEXT_FACTORY changes when you are trying to use the JNDI approach to
logging in. It changes from org.jnp.interfaces.NamingContextFactory to
org.jboss.security.jndi.LoginInitialContextFactory
(This point is not trivial either as the LoginInitialContextFactory is not in
any of the jboss client JARs but is found in the server JARs in jbosssx.jar.
It would have taken you some time to find it....)
My test environment is strong:
I believe that the environment I am working in is valid for this experiment. I
have an ejb-jar deployed with 4 entity beans. I have a separate web-app with
JSPs that correspond to the 4 beans so that I can add, update, delete, and
display data from these 4 beans. Each pair of beans is in a relationship. For
2 months I have been using these beans from the JSPs and from a Lotus Notes
client running Notes agents written in Java. Everything works great. I even
got the beans and the JSPs working under a single security domain I called
"spoonware". That domain is configured in the server's login-config.xml file
as follows:
<application-policy name = "spoonware">
| <authentication>
| <login-module
code="org.jboss.security.auth.spi.UsersRolesLoginModule"
| flag = "required" >
| <module-option name =
"unauthenticatedIdentity">guest</module-option>
| </login-module>
| </authentication>
| </application-policy>
There are two files, roles.properties and users.properties in the
WEB-INF\classes folder in the WAR for the web app with the JSPs. These files
have the name=password and name=roles settings to establish who the users are
and what their passwords are, etc. For the web app and the secured EJBs, those
users and roles work perfectly.
So, I am convinced that the spoonware domain works correctly for EJBs and Web
Apps. It will probably also work for my Lotus Notes apps once I can get logged
in.
Now it gets difficult:
Regardless if one uses either of the two approaches to logging in, there is
still something very important going on configuration-wise on the client that
nobody's talking about. (Maybe they are but I'm not finding what they are
saying.) That word you use in the SECURITY_PROTOCOL field is really
important!! It must related to some configuration by the same name, probably
in the auth.conf file for the client BUT, I don't know where that file should
go or how to get my Lotus Notes JVM to read it.
The example client code in the JAAS How To shows the LoginContext thing as
follows. I've left out the entire example to focus on the LoginContext part:
try
| {
| AppCallbackHandler handler = new AppCallbackHandler(name,
password);
| LoginContext lc = new LoginContext("TestClient", handler);
| System.out.println("Created LoginContext");
| lc.login();
| }
| catch (LoginException le)
| {
| System.out.println("Login failed");
| le.printStackTrace();
| }
It's got some high-zook CallbackHandler but it's just a a CallbackHandler. In
this example, however, the name of the client login module is "TestClient". I
can't find the word "TestClient" anywhere else in the entire JAAS HowTo so it's
hard to tell exactly what that word refers to. (I really tried it. You know
the little dog thing that searches in WinXP? It looks inside the files ifyou
tell it to and there was no other reference to the word "TestClient", so we
guess again..)
Here's where I need help:
What am I missing?
What's up with the auth.conf file?
Where does it go?
How do I tell my JVM to look for it and use it?
On the server in the login-config.xml file, there is the following
application-policy declaration. When I put "client-login" as the first
argument to my new LoginContext() OR when I use it as the value for the
SECURITY_PROTOCOL field in the JNDI properties, does my Java client do anything
at all with this server-based declaration? Probably not because the client JVM
probably needs the auth.conf file.
<application-policy name = "client-login">
| <authentication>
| <login-module code = "org.jboss.security.ClientLoginModule"
| flag = "required">
| </login-module>
| </authentication>
| </application-policy>
So, if I have an auth.conf file like the one below, does give meaning to the
expression "client-login"?
client-login {
| org.jboss.security.ClientLoginModule required;
| };
And, if this is the final piece, where does it go? <JAVA_HOME> somewhere? In
the jvm\lib\lib directory with the jndi.properties file? In the
jvm\lib\security directory with the java.security and java.policy files?
Or does it go somewhere else? Or does it not really matter and I'm missing the
boat entirely some other way?
See how treacherous it is?
Spoon
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3860994#3860994
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3860994
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
JBoss-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-user
