> 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).
> 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.
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.
> 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?")
> 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".
