Thanks for your reply. See comments below.
Assaf Arkin wrote:
> > First, where will the server look for the user name and password? How is it
> > configurable? I would like to be able to use a custom table, or a session bean
> > which will do the work for me, or a LDAP server, or <insert what you want here>.
>
> Up to the server, and most will use a text file (aka realm file).
>
> Looking up using a custom table or LDAP is possible.
>
> > Second, what will the cookie used as session ID (or appended string if URL
> > rewriting is used) contain? IMO, it should at least be a long secure random
> > number, else anybody could easily guess a session ID and access a protected
> > resource. Is it possible to configure the content of the cookie (it could
> > contain encrypted user-related info, for example)?
>
> A serial number with absolutely no meaning.
>
> It's long enough so you don't get to users with the same session, but
> it's guessable. Stealing a cookie is, well, like stealing a cookie. Too
> easy. Any effort you do to come up with really random and creative ids,
> is outdone in five minutes by someone intercepting the HTTP connection.
>
> If you can about a secure connection, always use SSL (or more).
>
OK, I should have mentioned that I planned to use SSL. But even with SSL, isn't it
quite easy for a hacker to connect to my web site, perform the SSL handshake, guess a
valid serial number and include it as a cookie in the following requests? If the
serial numbers are easily guessable, whatever password constraint you enforce,
accessing protected resources is a piece of cake, isn't it?
>
> > Third, for subsequent requests, the container will intercept the session ID and
> > try to map a session with this ID. Is this process configurable? Suppose I want
>
> Yes. I mean, it will use the session ID on subsequent requests.
>
> > to check that the request comes from the same IP address as before. Suppose also
>
> There is no such thing. For users behind a proxy/firewall the request
> might be coming from a different IP each time. In addition, for users
> behind proxy/firewall the whole company might be represented by a single
> IP address.
>
OK, here again, I chose a bad example. I know that checking the IP address is not a
good idea. But it would be nice if I could customize the way the serial number is
generated, or renew it after x requests from that user.
>
> Once again, if you want even limited security use SSL. Anything else
> cannot be trusted.
>
> > 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? This
> > is necessary, because I still want to know the roles this principal is
> > associated with; I still want to pass this principal to the EJB calls, etc.
>
> The specs does not define a way to do that, yet.
>
That really sucks, IMO. 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, 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. 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.
>
> > Five: if I still want to use the declarative form-based authentication, but also
> > want the users to be able to enroll themselves (choose a user ID and password),
> > how can I insert a new user in the user database and map him to some roles?
>
> The specs definitely does not define that. You need to use some
> proprietary mechanism to add/remove users which is compatible with what
> you use to authenticate them.
>
> (I know. It sucks big time. You are not the first to say "well, how do I
> update this thing?")
>
Good not to feel alone :-)
Thanks again.
JB.
>
> > The authentication part, though enhanced in the latest specs, is still full of
> > big holes, unless I missed a big part. So if you could tell me what you think,
> > or what you know from different products, this would be nice.
>
> It's more like a doughnut :-)
>
> arkin
>
> >
> > Thanks.
> > JB.
> >
> > --
> > Jean-Baptiste Nizet
> > [EMAIL PROTECTED]
> >
> > R&D Engineer, S1 Belgium
> > Excelsiorlaan 87
> > B-1930 Zaventem
> > +32 2 714 45 42
> >
> > ===========================================================================
> > 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".
>
> ===========================================================================
> 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".
--
Jean-Baptiste Nizet
[EMAIL PROTECTED]
R&D Engineer, S1 Belgium
Excelsiorlaan 87
B-1930 Zaventem
+32 2 714 45 42
===========================================================================
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".
