-
1. Re: Custom CallbackHandler (_deep_ JBossSX architectural que
xibin Sep 29, 2003 6:06 PM (in response to pharaohh)Any answers yet? I am researching the same issue, from jbossmq's authentication.
-
2. Re: Custom CallbackHandler (_deep_ JBossSX architectural que
bjornbak Oct 10, 2003 3:02 AM (in response to pharaohh)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 -
3. Re: Custom CallbackHandler (_deep_ JBossSX architectural que
pharaohh Oct 10, 2003 6:06 AM (in response to 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. -
4. Re: Custom CallbackHandler (_deep_ JBossSX architectural que
pharaohh Oct 10, 2003 6:27 AM (in response to 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