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,
http://weblogs.java.net/blog/sekhar/archive/2009/03/weblogic_to_gla.html
http://forums.java.net/jive/message.jspa?messageID=337626#337626
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!
D.

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.
>
> Correct.
>
>> 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
>> needs.
>
> 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:
>
>    <sec:BasicLogin/>
>
> And then you could use
>
>    @Current AbstractLogin _login;
>
> Or
>
>    @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 =
>> SecurityClientFactory.getSecurityClient();
>> securityClient.setSimple("user", "password");
>> securityClient.login();
>>
>> Thanks,
>> Jeff
>>
>> 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
>>>> and
>>>> password?
>>>>
>>> This page has a good overview of how to do it:
>>>
>>> http://www.informit.com/articles/article.aspx?p=24253&seqNum=7
>>>
>>> So you set up your security constraints in your resin.xml and
>>> reference
>>> a custom authenticator inside the login-config.  The create your
>>> custom
>>> 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
>>> the
>>> .http. version is deprecated.
>>>
>>> - Aaron
>>>
>>>
>>> _______________________________________________
>>> resin-interest mailing list
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>>>
>>
>>
>> _______________________________________________
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>
>
>
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest
>



----------------------------------------------------------------





_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest

Reply via email to