Custom CallbackHandler (_deep_ JBossSX architectural questio

[pharaohh]

I'm deep into the JBossSX architecture...after reading how it all works, I wrote a custom CallbackHandler implementation for a custom LoginModule implementation.

However, the only place I see in the docs for specifying what CallbackHandler implementation to use for my custom LoginModule is via an element in the

server//conf/jboss-service.xml file

for configuration of the JaasSecurityManagerService MBean via an mbean attribute element "CallbackHandlerClassName".

I did some digging through the source, and the org.jboss.security.plugins.JaasSecurityManager inspects, via introspection, its CallbackHandler implementation and expects it to have a "setSecurityInfo" Method to call.

My CallbackHandler does not have this method, as it is not required for my business logic.

I'm assuming (hopefully) that the
org.jboss.security.auth.callback.SecurityAssociationHandler class (which does have a setSecurityInfo method) wraps my custom CallbackHandler implementation as a proxy and the JaasSecurityManager operates via this proxy. This would ensure JAAS compatibility and is really the only proper solution...otherwise developers would have to write to a JBoss api and therefore prevent portability for their custom LoginModules and CallbackHandlers.

If my assumption is correct, then I can specify my custom callback handler as a fully qualified class name to the
JaasSecurityManagerService Mbean attribute "CallbackHandlerClassName" as desired, and be on my merry way.

If my assumption is incorrect, then my implementation will not work with JBoss.

Can someone please verify my assumption?

Also, I'm curious...to avoid having to mess with the server//conf/jboss-service.xml file, why can't this be an element somewhere in the jboss.xml file for an ear file? This would eliminate the need to edit the core service.xml file and allow ear-level configuration.

Thanks for any replies,

Les

[xibin]

Any answers yet? I am researching the same issue, from jbossmq's authentication.

[bjornbak]

Hi

Did you find a solution?

I'm not a JBossSX expert actually I'm a JBossSX newbie...

But in the payed JBossBook-3.2.1 chapter 8 is an example of how to create a sar embedded in the ejb-jar which override the main server-config.

I've followed this example to use my own LoginModule, but I too need to create a custom CallbackHandler..

/Christian

[pharaohh]

No, unfortunately, no JBoss developers replied. The stuff to which I referred is pretty deep in JBossSX architecture, and the only person I know of at the moment who works on that stuff is Scott Stark. Scott is a terribly busy guy, so he probably hasn't had time to address the question (or even know if it exists).

Basically, this is what I did for my solution. The best part is, it is completely ear-deployable and is portable across any app server (so you don't have to mess with app-server specific xml files).

I wrote my own LoginModule(s), CallbackHandler(s) and LoginContext. I configure the LoginContext via xml files using an incredibly powerful yet very simple open source framework called the Spring Framework (http://www.springframework.org). Spring allows me to do any application-specific configuration outside the bounds of any app server, and its incredibly lightweight, following the Inversion of Control design pattern (meaning you don't have to code to Spring-specific classes or interfaces, you just code your objects as JavaBeans and integrate into Spring via XML).

Unfortunately this custom configuration approach did take a little more development time, but this guarantees my solution is portable to any app server (My company is contract based, and the app server can change at any time, so this is very important for me).

If you still want to try the JBoss-specific approach, I would recommend specifying your custom CallbackHandler (as I suggested in my initial post) and just see if it works. If it doesn't work, then you know you'll have to write a custom implementation. I have a strong feeling though that JBoss _does_ wrap your callback handler implemenation to enable portability. However, I can't be sure, as I didn't test it myself. I found my other solution valuable enough such that going the JBoss-specific route was no longer important to me.

[pharaohh]

Sorry, I posted the link incorrectly.

It is http://www.springframework.org

Also, something that may help you:

The only reason I initially wanted to write a custom CallbackHandler was because I wanted to retrieve more information than just a Principal/Credential pair (in my case, a username/password pair). I also wanted the time of the login attempt, so I could test to see if they've attempted to log-in too many times within a given period. If so, then I could lock the account for security reasons.

However, after a couple of months of digging deep, and through my own understanding after seeing this work in practice, I've come to the conclusion that what I was initially trying to do was a _bad_ idea. I was extending JAAS logins to be more than what they are intended for. That is, I was trying to converge authorization (how many times they can log in) and authentication (checking to see if you are who you really say you are).

LoginModules should _only_ be concerned with authentication (you are who you say you are by providing a principal/credential pair). And they should only be concerned with a single pair, never anything extra, like what I was attempting. If you need to validate against multiple pairs, you always create a login module for each pair, and tell the LoginContext what login modules to use via xml configuration.

Any extra stuff outside of pure authentication (principal/credential pair verification) needs to be handled outside of the LoginContext domain. For example, I used an rdbms to maintain state between login attempts, and this was done via a StatelessSessionBean, not via the LoginContext, LoginModules, or CallbackHandlers.

This way, my login stuff does only what it was intended for. My business logic (state between logins, timestamps, etc) are handled via EJB's, which is where business logic should reside anyway. Don't mix the two ;)

If you stick to this principal, JBossSX framework will probably do what you want it to do without much effort at all (unless you want pure portability, like I need).

phar