RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-23 Thread Ignacio Coloma

Jan how I love you.

That fixed it. I was trying to write a repro case as Scott asked, but
haven't been able to get the same behaviour. I prepared a servlet that was
registered in jbosstest-web and reproduced my situation but I wasn't able to
get my same bug.

Your fix worked, instead. Thanks a lot.

 -Mensaje original-
 De: Jan Bartel [mailto:[EMAIL PROTECTED]]
 Enviado el: viernes, 22 de marzo de 2002 10:36
 Para: [EMAIL PROTECTED];
 [EMAIL PROTECTED]
 Asunto: Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]


 OK chaps, I'm going to have a shot at providing a solution to this.

 I think what is happening is that Jetty is only setting the Principal
 to null after it is finished handling a request, rather than both the
 Principal *and* the Credential. Therefore, when no user has been
 authenticated, both Principal and Credential will be null. However,
 after a user has been authenticated, there will be a thread with a null
 Principal but a still set Credential.

 Now I haven't fully traced back the intricacies of the security code,
 but I notice that there are a few tests like:
 if (username == null  password == null)
  use the unauthenticatedIdentity;

 I am assuming that maybe the username and password are obtained from the
 thread's SecurityAssociation.getPrincipal() and
 SecurityAssociation.getPassword().

 So, in short I've made sure we null out *both*
 SecurityAssociation.Principal and SecurityAssociation.Credential.

 Update your tree to get the new
 $JBOSSHOME/jetty/src/main/org/jboss/jetty/Jetty.java.

 If that doesn't fix it, then I definitely give up :-)

 Jan

 Scott M Stark wrote:

 I'm not following what you meant in your original post about
 I get an exception one of each 3 times...
 
 Hit refresh - ok
 Hit refresh - ok
 Hit refresh - Error 500
 
 The error is thrown on any non-authenticated browser when there is an
 authenticated one open. If you don't authenticate anyone (if you only
 
  browse
 
 the public zone) there is no error.
 
 
  That should not happen. Is the servlet accessing the ejb deployed in
  both the protected and unprotected areas? Try to reproduce the issue
  with a variation of the jbosstest-web.ear.
 
 
 MyAuthEntry {
 org.jboss.security.auth.spi.DatabaseServerLoginModule required
 dsJndiName=java:/CanplasticaDS
 principalsQuery=SELECT PASSWORD AS Password FROM USUARIO
 WHERE ID=?
 rolesQuery=SELECT ROLE AS Role, 'Roles' AS RoleGroup FROM
 ROLE WHERE
 USU_ID = ?
 unauthenticatedIdentity=nobody --
 ;
 };
 
 Also the nobody user has a principal record, because if not it
 also wasn't
 allowed to access the app.
 
  That should work then.
 
 
 
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
 



  Yahoo! Groups Sponsor -~--
 Tiny Wireless Camera under $80!
 Order Now! FREE VCR Commander!
 Click Here - Only 1 Day Left!
 http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/CefplB/TM
 -~-

 For the latest information about Jetty, please see
http://jetty.mortbay.org

To alter your subscription to this list goto
http://groups.yahoo.com/group/jetty-discuss

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/





___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-22 Thread Ignacio Coloma

 I'm not following what you meant in your original post about
 I get an exception one of each 3 times...

Hit refresh - ok
Hit refresh - ok
Hit refresh - Error 500

The error is thrown on any non-authenticated browser when there is an
authenticated one open. If you don't authenticate anyone (if you only browse
the public zone) there is no error.

 of the unchecked EJB permission seems to be incorrect. Any
 EJB given a method-permission requires an authenticated user.
 The method-permissions define the roles the authenticated users
 must have. A method-permission value of unchecked indicates that
 any authenticated user may access the EJB, but the user still must be
 authenticated. A servlet accessed via a URL that is not located under
 a security-constraint will access EJBs as an unauthenticated
 user(principal=null, credentials=null). Unless you have setup a
 security-domain that is configured to map unauthenticated users to
 a fixed principal name, any EJB call made by this servlet will fail with
 the exception you show.

MyAuthEntry {
org.jboss.security.auth.spi.DatabaseServerLoginModule required
dsJndiName=java:/CanplasticaDS
principalsQuery=SELECT PASSWORD AS Password FROM USUARIO WHERE ID=?
rolesQuery=SELECT ROLE AS Role, 'Roles' AS RoleGroup FROM ROLE WHERE
USU_ID = ?
unauthenticatedIdentity=nobody --
;
};

Also the nobody user has a principal record, because if not it also wasn't
allowed to access the app.


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-22 Thread Scott M Stark


  I'm not following what you meant in your original post about
  I get an exception one of each 3 times...

 Hit refresh - ok
 Hit refresh - ok
 Hit refresh - Error 500

 The error is thrown on any non-authenticated browser when there is an
 authenticated one open. If you don't authenticate anyone (if you only
browse
 the public zone) there is no error.

That should not happen. Is the servlet accessing the ejb deployed in
both the protected and unprotected areas? Try to reproduce the issue
with a variation of the jbosstest-web.ear.

 MyAuthEntry {
 org.jboss.security.auth.spi.DatabaseServerLoginModule required
 dsJndiName=java:/CanplasticaDS
 principalsQuery=SELECT PASSWORD AS Password FROM USUARIO WHERE ID=?
 rolesQuery=SELECT ROLE AS Role, 'Roles' AS RoleGroup FROM ROLE WHERE
 USU_ID = ?
 unauthenticatedIdentity=nobody --
 ;
 };

 Also the nobody user has a principal record, because if not it also wasn't
 allowed to access the app.
That should work then.



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-22 Thread Jan Bartel

OK chaps, I'm going to have a shot at providing a solution to this.

I think what is happening is that Jetty is only setting the Principal
to null after it is finished handling a request, rather than both the
Principal *and* the Credential. Therefore, when no user has been 
authenticated, both Principal and Credential will be null. However, 
after a user has been authenticated, there will be a thread with a null 
Principal but a still set Credential.

Now I haven't fully traced back the intricacies of the security code, 
but I notice that there are a few tests like:
if (username == null  password == null)
 use the unauthenticatedIdentity;

I am assuming that maybe the username and password are obtained from the 
thread's SecurityAssociation.getPrincipal() and
SecurityAssociation.getPassword().

So, in short I've made sure we null out *both* 
SecurityAssociation.Principal and SecurityAssociation.Credential.

Update your tree to get the new 
$JBOSSHOME/jetty/src/main/org/jboss/jetty/Jetty.java.

If that doesn't fix it, then I definitely give up :-)

Jan

Scott M Stark wrote:

I'm not following what you meant in your original post about
I get an exception one of each 3 times...

Hit refresh - ok
Hit refresh - ok
Hit refresh - Error 500

The error is thrown on any non-authenticated browser when there is an
authenticated one open. If you don't authenticate anyone (if you only

 browse
 
the public zone) there is no error.


 That should not happen. Is the servlet accessing the ejb deployed in
 both the protected and unprotected areas? Try to reproduce the issue
 with a variation of the jbosstest-web.ear.
 
 
MyAuthEntry {
org.jboss.security.auth.spi.DatabaseServerLoginModule required
dsJndiName=java:/CanplasticaDS
principalsQuery=SELECT PASSWORD AS Password FROM USUARIO WHERE ID=?
rolesQuery=SELECT ROLE AS Role, 'Roles' AS RoleGroup FROM ROLE WHERE
USU_ID = ?
unauthenticatedIdentity=nobody --
;
};

Also the nobody user has a principal record, because if not it also wasn't
allowed to access the app.

 That should work then.
 
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-22 Thread Scott M Stark

Clearing both the principal and credential is required to
indicate an unauthorized user. The existence of the non-null
credential and a null pricinpal will cause the problem seen by
Ignacio.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Jan Bartel [EMAIL PROTECTED]
To: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Sent: Friday, March 22, 2002 2:36 AM
Subject: Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]


 OK chaps, I'm going to have a shot at providing a solution to this.

 I think what is happening is that Jetty is only setting the Principal
 to null after it is finished handling a request, rather than both the
 Principal *and* the Credential. Therefore, when no user has been
 authenticated, both Principal and Credential will be null. However,
 after a user has been authenticated, there will be a thread with a null
 Principal but a still set Credential.

 Now I haven't fully traced back the intricacies of the security code,
 but I notice that there are a few tests like:
 if (username == null  password == null)
  use the unauthenticatedIdentity;

 I am assuming that maybe the username and password are obtained from the
 thread's SecurityAssociation.getPrincipal() and
 SecurityAssociation.getPassword().

 So, in short I've made sure we null out *both*
 SecurityAssociation.Principal and SecurityAssociation.Credential.

 Update your tree to get the new
 $JBOSSHOME/jetty/src/main/org/jboss/jetty/Jetty.java.

 If that doesn't fix it, then I definitely give up :-)

 Jan




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-22 Thread Juraj Vasko


I tested it and it seems to work well by now with my app.

Thanks for the quick fix

/lothar

On Thu, 21 Mar 2002, Jan Bartel wrote:

 I have checked in a fix for this problem, but I am afraid I am unable to
 test the fix at the moment. Could someone retest and let me know if the 
 fix is solid?
 
 You will need to update 
 $JBOSSHOME/jetty/src/main/org/jboss/jetty/security/JBossSecurityRealm.java
 
 
 Thanks
 
 Jan
 
 
 
  Hi,
  I noticed a weird behavior when more than one user is authenticated
  through Jetty with form login (haven't tried this with basic auth).
  The mechanism works well when only a single user is logged in. But when another 
  user logs in the first user is redirected to form login page upon his
  next request again. It seems from the logs that the first users password
  is lost or replaced with the one of the second user, but his username is
  preserved - the authentication fails with incorrect password upon the
  request and the user is redirected. For the second user all works well. 
  I'm using the current cvs snapshot.
  
  Any ideas?
  
  /lothar
  
  
  ___
  Jboss-development mailing list
  [EMAIL PROTECTED]
  https://lists.sourceforge.net/lists/listinfo/jboss-development
  
 
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-21 Thread Jan Bartel

I have checked in a fix for this problem, but I am afraid I am unable to
test the fix at the moment. Could someone retest and let me know if the 
fix is solid?

You will need to update 
$JBOSSHOME/jetty/src/main/org/jboss/jetty/security/JBossSecurityRealm.java


Thanks

Jan



 Hi,
 I noticed a weird behavior when more than one user is authenticated
 through Jetty with form login (haven't tried this with basic auth).
 The mechanism works well when only a single user is logged in. But when another 
 user logs in the first user is redirected to form login page upon his
 next request again. It seems from the logs that the first users password
 is lost or replaced with the one of the second user, but his username is
 preserved - the authentication fails with incorrect password upon the
 request and the user is redirected. For the second user all works well. 
 I'm using the current cvs snapshot.
 
 Any ideas?
 
 /lothar
 
 
 ___
 Jboss-development mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-development
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-21 Thread Jan Bartel
)
 at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715)
 at java.lang.Thread.run(Thread.java:484)
 
 
-Mensaje original-
De: jules [mailto:jules]En nombre de Jules Gosnell
Enviado el: jueves, 21 de marzo de 2002 0:47
Para: [EMAIL PROTECTED]
Asunto: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]



I guess that this is probably me, but just in case - does it ring any
bells ?

Jules



For the latest information about Jetty, please see
http://jetty.mortbay.org

To alter your subscription to this list goto
http://groups.yahoo.com/group/jetty-discuss

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



 
 
  Yahoo! Groups Sponsor -~--
 FIND OLD SCHOOL FRIENDS and OLD FLAMES
 Click here to start your search at Reunion.com today!
 http://us.click.yahoo.com/NFsLKA/Dn2DAA/ySSFAA/CefplB/TM
 -~-
 
 For the latest information about Jetty, please see http://jetty.mortbay.org
 
 To alter your subscription to this list goto 
http://groups.yahoo.com/group/jetty-discuss 
 
 Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
 
 



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-21 Thread Greg Wilkins
(HttpServer.java:744)
at org.jboss.jetty.Jetty.service(Jetty.java:530)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:743)
at
org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:916)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:758)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:145)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:287)
at org.mortbay.util.ThreadPool$JobRunner.run(ThreadPool.java:715)
at java.lang.Thread.run(Thread.java:484)



-Mensaje original-
De: jules [mailto:jules]En nombre de Jules Gosnell
Enviado el: jueves, 21 de marzo de 2002 0:47
Para: [EMAIL PROTECTED]
Asunto: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]



I guess that this is probably me, but just in case - does it ring any
bells ?

Jules



For the latest information about Jetty, please see
http://jetty.mortbay.org

To alter your subscription to this list goto
http://groups.yahoo.com/group/jetty-discuss

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/






For the latest information about Jetty, please see http://jetty.mortbay.org

To alter your subscription to this list goto 
http://groups.yahoo.com/group/jetty-discuss 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 


 
 
 
 
  Yahoo! Groups Sponsor -~--
 Tiny Wireless Camera under $80!
 Order Now! FREE VCR Commander!
 Click Here - Only 1 Day Left!
 http://us.click.yahoo.com/nuyOHD/7.PDAA/yigFAA/CefplB/TM
 -~-
 
 For the latest information about Jetty, please see http://jetty.mortbay.org
 
 To alter your subscription to this list goto 
http://groups.yahoo.com/group/jetty-discuss 
 
 Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 
 



-- 
Greg Wilkins[EMAIL PROTECTED]  GB  Phone: +44-(0)7092063462
Mort Bay Consulting Australia and UK.Mbl Phone: +61-(0)4 17786631
http://www.mortbay.com   AU  Phone: +61-(0)2 98107029


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-21 Thread Ignacio Coloma

Hi Jan :)

 (I'm cross posting this to jboss-dev and jetty-discuss)

 I think your current problem has in fact always been a problem with
 your webapp, but it has just been unmasked by a modification to the
 thread authentication stuff we did recently. What we did was to ensure
 that when a Jetty/JBoss thread has finished servicing a request, the
 user principal and credentials were disassociated with the thread -
 otherwise all subsquent work done by that thread in servicing another
 request would use that security information.

Yep, I know. I helped to catch that bug on. Modest help, anyway.

 So, in your case, what I think is happening is that your webapp has
 appeared to work in the past because the principal and credentials from
 the hit with basic authentication was remaining attached to the
 servicing thread, so the subsequent non-authenticated hit was in fact
 using them.

Not probable. My application shows a different menu depending on the
principal authenticated. When it's a nonauthenticated user the menu is the
public one. Salesman, customers, sysadmin and director also have their own.
That's why authentication failures are easy to get caught, they shout it out
loud (menus have different colours).

All my EJBs leave permissions open to everyone (access is only restricted on
the web tier), so even non-authenticated users should have no problem
accesing resources. Anyway, if I only open unathenticated browsers there is
no problem, it only arises when I open and authenticate one of them. The bug
arises then in the nonauthenticated browser.

I don't feel comfortable asking for help past this point. I have enough info
to get on by myself, so I'll give it a good try to see what's happening. If
nobody is complaining about it it must be, as Marc said, 90% my fault.

Thanks to everybody.



___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-21 Thread Ignacio Coloma

 Just to back up what Jan said

 If you want to access beans that have security constraints, then
 currently the URL must be one that has an authentication-constraint
 specified.

 The happenstance that a browser is actually sending basic authentication
 information to a non-authenticated URL is not enough to trigger a
 call to the JBoss authentication mechanisms.  You must have an
 authentication
 constraint.

 Do you see a need for it to be any different to this?

If (as is my case) I want the data processing to be different depending if
the access is being made by the 'default' user (configurable in auth.conf)
or by an authenticated user. If you want to put names to concepts, I want
the general public to see which services and items are being offered, but
not the prices. But if you are a customer, I want to show the prices out.

Maybe I'm misunderstanding my exception, but if I got it right, an bean
marked as unchecked/ is throwing a Authentication exception,
principal=null, something that should not happen.

At least, if it decides to happen, happen everytime, but not sometimes.

I insist that this could be my fault, sometimes has been, let me see it when
my work agenda lets me some time.


___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development



Re: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]

2002-03-21 Thread Scott M Stark

I'm not following what you meant in your original post about
I get an exception one of each 3 times..., but your understanding
of the unchecked EJB permission seems to be incorrect. Any
EJB given a method-permission requires an authenticated user.
The method-permissions define the roles the authenticated users
must have. A method-permission value of unchecked indicates that
any authenticated user may access the EJB, but the user still must be
authenticated. A servlet accessed via a URL that is not located under
a security-constraint will access EJBs as an unauthenticated
user(principal=null, credentials=null). Unless you have setup a
security-domain that is configured to map unauthenticated users to
a fixed principal name, any EJB call made by this servlet will fail with
the exception you show.


Scott Stark
Chief Technology Officer
JBoss Group, LLC

- Original Message -
From: Ignacio Coloma [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, March 21, 2002 5:01 PM
Subject: RE: [jetty-discuss] [Fwd: [JBoss-dev] Authentication with Jetty]


  Just to back up what Jan said
 
  If you want to access beans that have security constraints, then
  currently the URL must be one that has an authentication-constraint
  specified.
 
  The happenstance that a browser is actually sending basic authentication
  information to a non-authenticated URL is not enough to trigger a
  call to the JBoss authentication mechanisms.  You must have an
  authentication
  constraint.
 
  Do you see a need for it to be any different to this?

 If (as is my case) I want the data processing to be different depending if
 the access is being made by the 'default' user (configurable in auth.conf)
 or by an authenticated user. If you want to put names to concepts, I want
 the general public to see which services and items are being offered, but
 not the prices. But if you are a customer, I want to show the prices out.

 Maybe I'm misunderstanding my exception, but if I got it right, an bean
 marked as unchecked/ is throwing a Authentication exception,
 principal=null, something that should not happen.

 At least, if it decides to happen, happen everytime, but not sometimes.

 I insist that this could be my fault, sometimes has been, let me see it
when
 my work agenda lets me some time.




___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development