> I think that SUN put those other implementations
> there for a reason. Blatantly igoring them in JBOSS
> means that JBOSS cannot be J2EE certified.
No, the EJB specification in no way, shape or form defines how the security context should be passed between the client and the server, or whether any type of callbacks should be propagated back to the client, or even if JAAS should be used in the first place to perform client authentication.
If you need support for additional JAAS callbacks, submit a patch.
> No, the EJB specification in no way, shape or form
> defines how the security context should be passed
> between the client and the server, or whether any
> type of callbacks should be propagated back to the
> client, or even if JAAS should be used in the first
> place to perform client authentication.
Ok. But I still think that the login process should be a separate 'first class citizen' operation and not just something you do when you notice a new principal in security interceptor.
> If you need support for additional JAAS callbacks,
> submit a patch.
Isn't that something Scott should do? ;-) I'm just too busy coding the app itself - there's definately no time for doing the 'server' too.
Besides this isn't as trivial as it seems. Putting all this extra info in invocation object (the easy solution) is not reasonable. You definately don't want to send it _every_ time you make a remote call.
The other option - separate login process requires changes at least in:
- security interceptor:
detect a login method invocation and extract the extra info from payload. (Placed there by the also modified ClientLoginModule)
- SimplePrincipal needs to be modified or extended by a new one which supports these extra fields that different login modules require.
- SecurityAssociationHandler (The principal and callback stuff)
- probably much more changes - the SimplePrincipal is all over the place and changing/extending it might have a substantial effect...
It seems that there is no reason to base strong projects using JBoss because the Security and JAAS possibilities are very important. For example we would like to do the following which is possible for WebLogic and other professional Application Servers, but for JBoss it is not true:
1. Two steps Authorization using 1st page for Username and Password, and 2nd page for additional clarifications depends of the concrete user. Just after the 2nd page you can to determine the rights (roles).
2. Hierarchy based security model which dynamicaly determine the user roles depending of some codnistions and/or hierarchy folder tree.
Scott? Are u listening? Are any of these features scheduled for Jboss 4?
> Isn't that something Scott should do? ;-)
I'm sure he will once he has received your development support check. Or if you plead to him *nicely*.
> I'm just too busy coding the app itself - there's definately
> no time for doing the 'server' too.
Uh huh. Aren't we all?
In the mean time you can have a look at the SRP login module to maybe gain some ideas how to build exchange protocols between the client and the server.
Juha, in no way I didn't mean to sound mean ;-). Ok I admit that I was a bit surprised by the way JAAS was implemented in JBoss - quite clean and effective but on the downside, almost impossible to extend. Thx for the SRP suggestion, maybe I'll take a look about that.
Right now the problem is solved by clients sending 'heartbeats' to server (at two minute intervals) which contain the local ip address + other stuff needed to distinguish different clients from each other. That way I also have the added benefit of being able to 'unregister' 'dead' clients fairly quickly from my own 'user management scheme'
Plus it's totally app server independent.
Since you are trying to make money with JBoss why not make more of it by adding new features that attract new customers?
> It seems that there is no reason to base strong
> projects using JBoss
Look it's fairly simple, really. If you still don't understand how the game works let me help you by listing your options:
1) sit and whine and get nothing done
2) start coding
3) beg someone to code it for you
4) pay someone to code it for you
5) buy weblogic
Is that clear? HTH
> Since you are trying to make money with JBoss why not
> make more of it by adding new features that attract
> new customers?
Maybe that business model would work, maybe not.
I'm thinking like this: you want a feature that falls outside the J2EE spec, you pay me to code it, I make money. ;-)