I'm not aware of any standard way to do this, although I'm not fully up to speed on what all the security guys have been up to in terms of providing security hooks in the web tier (I'm in clustering). So, don't take my response as meaning there's no way (but I doubt it).
See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73020 for a good discussion on the security dev list of work on adding flexibility to the Tomcat authentication mechanism. That's for the future though.
Yes, I just started a thread about this.
I'm amazed that there's no standard J2EE way to provide your own authentication.
I would have thought that JBoss might provide a way for you to supply your I just found http://jcp.org/en/jsr/detail?id=196 but that's just at the review stage.
Do any JBoss people know when this will make it into a downloadable JBoss release? If it's available, how do we work it?
In fact, it gets worse.
To perform the athentication, I need parameters from the original URL.
The client will go to http://foo.com/myapp/index.jsp?cic=IBM&srv=bigblue&port=2332
(or sometyhing similar)
And the authentication needs the "cic" as the company code, and the "srv" and "port" (as host name and port number) to connect to the back end server to do the authentication. It also must register the connection to the server in the HttpSession for subsequent use.
username+password is inadequate!. We need access to the HttpRequest, and HttpSession!
It looks like we should be able to do this by using a custom Tomcat authenticator.
I'd probably extend org.jboss.web.tomcat.security.AuthenticatorBase to make use of its existing logic, but override
public boolean authenticate(Request request, Response response, LoginConfig config) throws IOException
OK, now how do we specify that that class should be used for FORM based logins?
OK, that won't work.
Any other ideas?
Your frustrations are overlapping with the current focus in the Security Arena at JBoss. In addition, to the link Brian provided, an area that fits your needs are:
Unless the AuthenticatorBase is retrofitted, you will not achieve what you want.
public Principal authenticate(Header headers, Map data);
To the Realm interface? Sounds good. How (under JBoss) would I instruct the embedded Tomcat to use my user-written Realm Object just for one webapp?
Would you then also add new javax.security.auth.callback.Callback implementations so that my user-written LoginModule (which extends org.jboss.security.auth.spi.AbstractServerLoginModule - is that correct???) can ask it's CallbackHandler for the Header array and the parameter Map?
Any timeframe on this more useful authentication ability being part of a downloadable JBoss?
Also, how does one log out?
After using the container's authentication to call through to my LoginModule, my web app's logout processing then doesn't have access to the LoginContext to call the logout() method.
I suppose my LoginModule can put it into my user principal during login.... DOH! just looked, the LoginModule has no access to the LoginContext that called it! How can I possibly log out?
Anyway... My user principal object (an application-specific Object which carries a lot of app-specific context) which goes into the "CallerPrincipal" Group of the Subject annoyingly has to extend org.jboss.security.SimplePrincipal.
Why should this be? Surely, it just needs to implement java.security.Principal? Why does JBoss check that it's an instance of org.jboss.security.SimplePrincipal?
How come nobody, not even the JBoss staff knew this unlikely-looking incantation?
If this is a standard part of a JACC-conforming container, then this gem of information should be made extremely prominent!
Well, there's still the problem if the web app not having access to the LoginContext created by the container's authentication process so that it can explicitly log out.
This is another glaring omission for which there must be a solution somewhere.
How does anyone ever log out of JAAS-secured web apps under JBoss?
Also, the questions about why the user principal has to be a org.jboss.security.SimplePrincipal. Why?
To logout, just invalidate the session. Every request the user is logged in and logged out, that is why they cache the credentials.
If you invalidate your session, the security associations will get disconnected from the client and then they will be "logged out".
Hope that makes sense.
That doesn't work.
I have debug statements in my LoginModule's logout() method, and they are not being executed.