Re: [Resin-interest] Remote programmatic authentication

2009-03-24 Thread Scott Ferguson

On Mar 21, 2009, at 11:49 AM, Jeff Schnitzer wrote:

 I have only spent a little while browsing through the Resin code, so
 apologies in advance if I'm misunderstanding something.  I'd love to
 see something like:

 AbstractLogin.authenticate(HttpServletRequest request, Principal user,
 String credential) throws LoginException

 I just need any method that takes a user and password, checks it
 against the normal authentication SPI, and (if successful) registers
 the credentials to the container.

 I don't think I would need to customize the Login class.  I wouldn't
 be using any of the j2ee standard auth mechanisms, just programmatic
 authentication, so I'm guessing I could have a BasicLogin and just
 never use it.  As long as I can call the auth method from my normal
 webapp I'll be fine.

Right.  That's a logical thing to add.  The bug report is 
http://bugs.caucho.com/view.php?id=3412 
.

I'm not sure yet if it belongs in Login.  It might.



 BTW we are porting the opensource SubEthaMail over to Resin right now
 (http://subetha.tigris.org/).  If we succeed, you might want to use it
 for this mailing list!

Very cool!  We can take a look when it's ready.

-- Scott



 Jeff

 On Fri, Mar 20, 2009 at 10:15 AM, Scott Ferguson f...@caucho.com  
 wrote:

 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=24253seqNum=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



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


Re: [Resin-interest] Remote programmatic authentication

2009-03-24 Thread Daniel Lopez
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=24253seqNum=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

Re: [Resin-interest] Remote programmatic authentication

2009-03-20 Thread Scott Ferguson

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=24253seqNum=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


Re: [Resin-interest] Remote programmatic authentication

2009-03-20 Thread Scott Ferguson

On Mar 19, 2009, at 2:08 PM, Jeff Schnitzer wrote:

 First of all, I'd just like to say wow, I'm happy to re-discover Resin
 - I recall using it briefly in 2002 and I'm impressed with what you've
 been doing since.  It's a sharp contrast to the progress of JBoss,
 which has sadly become a complete wreck in the last few years.  The
 web beans stuff is fantastic and you're way ahead of the game.

FYI, everyone who is excited about JSR-299 (WebBeans/Java DI/CanDI)  
should lobby Sun and the JCP in favor of the CanDI spec.  There's an  
internal political game from members of the EJB/JavaEE group trying to  
weaken CanDI, mostly because they believe EJB is the true JavaEE  
component model, and see CanDI as some kind of competition.  (It's  
not, really.  CanDI strengthens EJB if you want to use EJB, but it  
doesn't require EJB.  I think doesn't require EJB  gives them  
heartburn.)

-- Scott



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


Re: [Resin-interest] Remote programmatic authentication

2009-03-20 Thread Aaron Freeman

What's the best way to lobby them?  I love the new IoC stuff.

-Aaron

On Mar 19, 2009, at 2:08 PM, Jeff Schnitzer wrote:

  

First of all, I'd just like to say wow, I'm happy to re-discover Resin
- I recall using it briefly in 2002 and I'm impressed with what you've
been doing since.  It's a sharp contrast to the progress of JBoss,
which has sadly become a complete wreck in the last few years.  The
web beans stuff is fantastic and you're way ahead of the game.



FYI, everyone who is excited about JSR-299 (WebBeans/Java DI/CanDI)  
should lobby Sun and the JCP in favor of the CanDI spec.  There's an  
internal political game from members of the EJB/JavaEE group trying to  
weaken CanDI, mostly because they believe EJB is the true JavaEE  
component model, and see CanDI as some kind of competition.  (It's  
not, really.  CanDI strengthens EJB if you want to use EJB, but it  
doesn't require EJB.  I think doesn't require EJB  gives them  
heartburn.)


-- Scott



___
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


Re: [Resin-interest] Remote programmatic authentication

2009-03-19 Thread Jeff Schnitzer
Answering my own question #1, I found the
HessionProxyFactory.setUser() and setPassword() methods.  Great.

#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?

Thanks,
Jeff

On Thu, Mar 19, 2009 at 2:08 PM, Jeff Schnitzer j...@infohazard.org wrote:
 First of all, I'd just like to say wow, I'm happy to re-discover Resin
 - I recall using it briefly in 2002 and I'm impressed with what you've
 been doing since.  It's a sharp contrast to the progress of JBoss,
 which has sadly become a complete wreck in the last few years.  The
 web beans stuff is fantastic and you're way ahead of the game.

 I've read most of the docs now and I'm a bit confused about how you
 authenticate to the container in two different scenarios:

 #1) A remote caller using hessian, either from another Resin instance
 (using DI) or from a standalone client.  I presume at a protocol level
 this involves basic or digest auth, but I don't see the API hooks.

 #2) Within the container, how do you authenticate programmatically?
 Ie, not using login forms or basic auth.  This is the common case of a
 signup form; after the user has filled out their chosen username and
 password I want to authenticate them to the container without forcing
 them to re-enter the credentials.

 Thanks,
 Jeff



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


Re: [Resin-interest] Remote programmatic authentication

2009-03-19 Thread Aaron Freeman

 #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=24253seqNum=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


Re: [Resin-interest] Remote programmatic authentication

2009-03-19 Thread Jeff Schnitzer
Thanks, but that is not what I'm looking for.  The document describes
building an authentication source and using automatic authentication
(aka web.xml security constraints).

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
needs.

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=24253seqNum=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


Re: [Resin-interest] Remote programmatic authentication

2009-03-19 Thread Aaron Freeman



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.

  
Ah, well I haven't used it before but there is a JdbcAuthenticator that 
has a cookie-auth-query and cookie-auth-update to let you 
automatically log someone in using a persistent cookie.  It's still not 
what you are describing below, but may suffice to solve automatic logins 
if that's the end goal.


Here is a link to some details on the JdbcAuthenticator: 
https://www.gopay.com.cn/resin-doc/security/authentication.xtp


That link might be out of date though, depending on which version of 
Resin you are using.


Sorry if this is still on the wrong track .. I'll let the gurus give you 
the answer.


- Aaron

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=24253seqNum=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