Jean-Baptiste Nizet wrote:
> > > Four: if, for any of the above reasons, I end up with a proprietary form-based
> > > authentication, not declarative, how do I set the user principal by myself?
> > The specs does not define a way to do that, yet.
> That really sucks, IMO.
Yes, yes it does. Egregiously. Just to make you feel better, our
systems' users must be capable of enrolling themselves (someone used the
term "enroll"; I like that much better than register!). When they do
so, a requirement we have is that their information must be stored in
the same database as the other objects in the system (so that, for
example, an order can be joined with the person who initiated it). We
are simply praying at this point that whatever application server we go
with will have a (non-standard, obviously) way of allowing us to (a)
indicate to the servlet container that lo and behold Joe has just
enrolled and so by God all further traffic associated with this session
should be tagged with his user ID, and (b) indicate to the EJB server
(hopefully automatically, through (a), that lo and behold the very same
Joe in the servlet authentication realm is the very same Joe that should
be set as the caller principal. I have no idea yet if any servers
actually do this in a flexible manner that does not require us to do
something idiotic like store Joe in an LDAP directory AND on the
database. I'd be curious to compare notes with you if and when you come
up with your own solution to this.
> So if you want to have security in your web server AND in your
> EJB server, you're forced to use either a non-customizable form-based mechanism which
> seems not to be secure enough,
Consider hashing or otherwise trivially encrypting the session ID
number. If half of it, for example, thinking off the top of my head, is
a checksum for the other half, then it's a little harder to guess.
> either SSL with client authentication, which requires a
> lot more work, a certificate for each client, etc. Since the container must have a
>way
> to associate a Principal to the current thread, it should not be too hard to add a
> method to allow the code itself to do that.
That's what we're hoping for. If this turns out not to be the case in
the major application servers, I'm going to be committed. :-) Now why
they couldn't have just added this to the specification I don't know.
I'm sure there must have been a good reason. Course, it would have to
be a REALLY GOOD reason.
> This is also necessary if you want to
> access a bean from your servlet with the user identity, and another bean with an
> administrator's identity. Hope JAAS will solve this.
You and me both. In any event, any nice standards-based solution to
this whole problem is probably at least a year away given all the
specification groups and such that have to talk to each other and make
compromises. Sigh.
Cheers,
Laird
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
