While on that topic... I have been "fighting" through the years, since
version 3.2, to get the servlet spec. to improve the security part but
well, not very successfully one could say. I guess not being famous or
working for a mega-vendor does not help :).
Bitching at forums and blogs (sending feedback to the servlet spec
feedback email was like throwing it to the trash can) I've managed to
get some attention lately,
so if some of you that think along the same lines would also to say
something, we might get "the small voices" to the be heard if we push
together. So feel free to add your feedback, please, so at least they
cannot say any longer that "users do not complain so it must be
nothing needs to change".
On a side node, what we did long ago was to separate the security
settings from the business logic and also divide it in two parts:
.- The security model specifies the relationship between roles and
users and if a user is authenticated or not.
.- The security policy specifies which roles are required to perform a
request, this can be done per-request-on-the-fly so the same URL can
have different requirements depending on the parameters, something on
the session, the context, the date... the weather ;)... whatever.
The security engine asks both entities and decides (it can decide
first if a user is logged in or not, and knowing which roles are
required for that specific request, deny or accept the request,
redirect to the login page...). Some information is passed to the
business logic in case it is required for something (usually the
username) and some more complex checkings can be done, but in many
applications that is more than enough.
That also allows us to re-use the security model between applications,
sharing the security policy is not that common as it tends to be
app-specific, and be able to deploy the applications on any container.
In any case, I wish it was part of the spec. so I did not have to
maintain the code myself, and we cannot make use of isUserInRole()
etc., but in any case it's worked for us since 1998, so I think we
already made the ROI positive :).
S'està citant Scott Ferguson <f...@caucho.com>:
> On Mar 19, 2009, at 8:30 PM, Jeff Schnitzer wrote:
>> The problem is, j2ee automatic authentication is nearly useless.
>> It doesn't allow for autologin cookies nor does it allow me to sign up
>> new users - they would have to then log in again. It blows my mind
>> that a decade later the servlet spec hasn't addressed these simple
> Yep. Almost as bizarre as not having multipart/mime (upload) support.
> Resin 4.0 has refactored Resin's login/authentication (because our old
> model really didn't make much sense.)
> The new Login handles servlet/http interaction and the Authenticator
> handles pure user/credentials (the old model mixed the two concepts
> into the old ServletAuthenticator.) So, the capabilities you're
> looking for would be added to a Login class. I don't know if you're
> looking for customizing the Login, or if you want a more general
> capability in our AbstractLogin.
> Since the new configuration uses Java DI, your application can grab
> the login. The configuration looks like:
> And then you could use
> @Current AbstractLogin _login;
> @Current BasicLogin _login;
> (At present, the Login interface itself wouldn't be useful from a
> programmatic standpoint, while we could add methods to AbstractLogin.)
> -- Scott
>> I need a way, in my web app, to programmatically say to the container
>> "authenticate as this user/pass". Then these credentials will be used
>> for further calls into the EJB tier or for responding to
>> HttpServletRequest.isUserInRole() calls. Of course at the SPI level
>> these will end up calling into my Resin Authenticator.
>> This is a pretty common problem, there must be a Resin way to do it.
>> In JBoss5, it looks like this:
>> SecurityClient securityClient =
>> securityClient.setSimple("user", "password");
>> On Thu, Mar 19, 2009 at 7:38 PM, Aaron Freeman <aaron.free...@layerz.com
>> > wrote:
>>>> #2 is still a mystery to me. I'm in a servlet, how do I
>>>> programmatically tell the container to "log me in" with a username
>>> This page has a good overview of how to do it:
>>> So you set up your security constraints in your resin.xml and
>>> a custom authenticator inside the login-config. The create your
>>> authenticator by AbstractAuthenticator.
>>> Note the code in the example is referencing:
>>> com.caucho.server.http.AbstractAuthenticator but I think you want to
>>> extend com.caucho.server.AbstractAuthenticator instead, as I think
>>> .http. version is deprecated.
>>> - Aaron
>>> resin-interest mailing list
>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list