DIGEST Authentication question

[Alexander Fishchuk]

Hi guys.
I'm having trouble setting up DIGEST authentication for single webapp in 
Tomcat 5.0.27.

does anyone have done it successfully
I'd appreciate some guidance in this area

Alex

authentication question

[Don Hill]

Hi,

I am trying to get application to authenticate so that the credentials
are carried into all subsequent request, what I have a persistence
realm that holds all the user/pasword and other info, I have a custom
login screen that we are using for all appservers websphere,weblogic
.. these other appserver have a API that allows me to login and
authenticate the user, I want to do the same thing with tomcat 4.x,
5.x without using the web.xml security constraints, does anyone know a
way that I can authenticate a user, I will be using the DataSource
Realm that will be mapped to my persistence store. I have tried to use
ServerFactory to try and get the services and the realm but haven't
any luck with this.

Thanks, don

  

-- 
Best regards,
 Don  mailto:[EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Newbie authentication question.

[Tim Funk]

Since the root cause is:
*root cause*
java.lang.UnsatisfiedLinkError: checkUser
at FuseBoxServlet.checkUser(Native Method)
at FuseBoxServlet.doGet(FuseBoxServlet.java:40)
at FuseBoxServlet.doPost(FuseBoxServlet.java:9)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
I would check with the FuseBox people.
-Tim
Terry wrote:
I'm running Apache 1.3.27 and Tomcat 4.1.29 and Oracle 4.2.04.  When i 
have everything running on the same box authentication works just fine 
and Oracle puts out the requested data.  But when i try to authenticate 
via remote box (also running oracle on this remote box) it fails with

javax.servlet.ServletException: Servlet execution threw an exception
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) 


*root cause*
java.lang.UnsatisfiedLinkError: checkUser
at FuseBoxServlet.checkUser(Native Method)
at FuseBoxServlet.doGet(FuseBoxServlet.java:40)
at FuseBoxServlet.doPost(FuseBoxServlet.java:9)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247) 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Newbie authentication question.

[Terry]

I'm running Apache 1.3.27 and Tomcat 4.1.29 and Oracle 4.2.04.  When i 
have everything running on the same box authentication works just fine 
and Oracle puts out the requested data.  But when i try to authenticate 
via remote box (also running oracle on this remote box) it fails with

javax.servlet.ServletException: Servlet execution threw an exception
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:577)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:457)
at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:576)
at java.lang.Thread.run(Thread.java:536)
*root cause*
java.lang.UnsatisfiedLinkError: checkUser
at FuseBoxServlet.checkUser(Native Method)
at FuseBoxServlet.doGet(FuseBoxServlet.java:40)
at FuseBoxServlet.doPost(FuseBoxServlet.java:9)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:256)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2417)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at 
org.a

RE: form-based authentication question

[Koes, Derrick]

It may be good for someone to answer this, but I figured out my problem.  I
accidentally used the login page name where the welcome page name should
have been in the servlet configuration.

Cockpit error.



-Original Message-
From: Koes, Derrick 
Sent: Tuesday, March 23, 2004 2:49 PM
To: '[EMAIL PROTECTED]'
Subject: form-based authentication question

Using Tomcat 4.1.X, I'm attempting to switch a web app from basic auth
to
form-based.  I'm having difficulty in one area.  After creating the new
form
and posting to j_security_check, I wish to GET my "welcome" page.  It
appears to be doing this from the URL in the address bar, but the page
looks
exactly like my login page.  That is, it seems to have posted to itself.
What's the appropriate way to forward to the "welcome" page?

 

A working example login page, welcome page, and deployment descriptor
would
be appreciated.

 

Thanks,

Derrick

 

 

This electronic transmission is strictly confidential to Smith & Nephew
and
intended solely for the addressee.  It may contain information which is
covered by legal, professional or other privilege.  If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy or take any action in reliance on this
transmission.  If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message.
This electronic transmission is strictly confidential to Smith & Nephew and
intended solely for the addressee.  It may contain information which is
covered by legal, professional or other privilege.  If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy or take any action in reliance on this
transmission.  If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

form-based authentication question

[Koes, Derrick]

Using Tomcat 4.1.X, I'm attempting to switch a web app from basic auth to
form-based.  I'm having difficulty in one area.  After creating the new form
and posting to j_security_check, I wish to GET my "welcome" page.  It
appears to be doing this from the URL in the address bar, but the page looks
exactly like my login page.  That is, it seems to have posted to itself.
What's the appropriate way to forward to the "welcome" page?

 

A working example login page, welcome page, and deployment descriptor would
be appreciated.

 

Thanks,

Derrick

 

 

This electronic transmission is strictly confidential to Smith & Nephew and
intended solely for the addressee.  It may contain information which is
covered by legal, professional or other privilege.  If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy or take any action in reliance on this
transmission.  If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message.

Form-based authentication question

[Edd Dawson]

Hi

I have successfully set up tomcat to protect various parts of my
application using JDBCrealm and form-based-authentication, and it all
works fine.

Now i have written a system whereby new users can register and it
creates them their chosen username and puts them in the right roles in
the database.

Now what i want to be able to do is have my servlet automatically log
them in as the register without the need for them to be redirected to
the login-form and re-enter their username and password.

I am presuming this is possible as i log my users out by invoking
request.getSession().invalidate(); in my logoff servlet, so my question
is how do i create their session without using the default login form?

Thanks
Edd


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: authentication question

[Rick Roberts]

Use SSL with Form Based AUTH.
Then all traffic is SSL protected.
Dave Naden wrote:
I can set up Tomcat's authentication fine, either basic (or digest)  or form-based.  Everything I read seems to prefer form-based, because you can customize the screen. However, basic as least encrypts the userID/password, and digest does that even better.  But form-based just sends these thing as clear text, does it not?   Isn't this an argument against form-based authentication for a simple web app?
-Dave Naden
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
***
* Rick Roberts*
* Advanced Information Technologies, Inc. *
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: authentication question

[Tim Funk]

Basic authentication is so weak that it is the equivalent of cleartext. If 
security of a password is an issue, use SSL.

-Tim

Dave Naden wrote:
I can set up Tomcat's authentication fine, either basic (or digest)  or form-based.  Everything I read seems to prefer form-based, because you can customize the screen. However, basic as least encrypts the userID/password, and digest does that even better.  But form-based just sends these thing as clear text, does it not?   Isn't this an argument against form-based authentication for a simple web app?
-Dave Naden
 
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

authentication question

[Dave Naden]

I can set up Tomcat's authentication fine, either basic (or digest)  or form-based.  
Everything I read seems to prefer form-based, because you can customize the screen. 
However, basic as least encrypts the userID/password, and digest does that even 
better.  But form-based just sends these thing as clear text, does it not?   Isn't 
this an argument against form-based authentication for a simple web app?
-Dave Naden
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

apache 1.3.x + tomcat 4.1.24 (authentication question)

[Leo Stone]

We've had an Apache 1.3.26 / Tomcat 4.0.3 configuration for load balancing and the 
authentication was using the apache htaccess method,   it has been working fine.  

After I upgraded to Tomcat 4.1.24 ( I didn't make any changes to the apache), I am 
having problems with the authentication. Looks like tomcat can't recognize the 
authentication did by apache and gave null to HTTPRequest.getAuthType().

Does anyone have any ideas what caused this?
Do I have to switch to mod_jk2 if I use tomcat 4.1.24? (we were using mod_jk for 
tomcat4.0.3).

Thanks,
L S


-
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).

RE: Basic authentication question

[Koes, Derrick]

Sorry, it is a protected resource and I want to continue to use basic
authentication, not form authentication.  I still don't see a way around the
problem.

The relevant part of my web.xml:



  dora
  /index.jsp
  GET
  POST


  1
  2
  3

  
  
BASIC
DORA
  

-Original Message-
From: Boon Seong [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 25, 2003 5:37 PM
To: Tomcat Users List
Subject: Re: Basic authentication question

In that case, meaning it is a protected resource right ? Maybe u can try
using
the container's security feature such as putting this configuration in your
web application's web.xml file.



  admin page
  /admin/*




FORM

  /admin/login.jsp
  /admin/error.jsp

 

- Original Message -
From: "Koes, Derrick" <[EMAIL PROTECTED]>
To: "'Tomcat Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 6:31 PM
Subject: RE: Basic authentication question


>
> Unfortunately, this does not work.
> Tomcat seems to use 401 as a prompt to put up the basic auth login dialog.
> If you add the configuration below, it goes to this page first without
ever
> prompting for user login.
>
> Do you have any other suggestions?
>
> Thanks,
> Derrick
>
>
>
> -Original Message-
> From: Boon Seong [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 25, 2003 5:27 PM
> To: Tomcat Users List
> Subject: Re: Basic authentication question
>
> add this to the web.xml
>
> 
> 401
> /errorpage.jsp
>   
>
> - Original Message -
> From: "Koes, Derrick" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 25, 2003 6:22 PM
> Subject: Basic authentication question
>
>
> >
> > I wish to replace tomcat's 401 error page with something more elegant
and
> > specific to my web app.  How can I do this?
> >
> > Thanks,
> > Derrick
> >
> >
> >
> > This electronic transmission is strictly confidential to Smith & Nephew
> and
> > intended solely for the addressee.  It may contain information which is
> > covered by legal, professional or other privilege.  If you are not the
> > intended addressee, or someone authorized by the intended addressee to
> > receive transmissions on behalf of the addressee, you must not retain,
> > disclose in any form, copy or take any action in reliance on this
> > transmission.  If you have received this transmission in error, please
> > notify the sender as soon as possible and destroy this message.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> This electronic transmission is strictly confidential to Smith & Nephew
and
> intended solely for the addressee.  It may contain information which is
> covered by legal, professional or other privilege.  If you are not the
> intended addressee, or someone authorized by the intended addressee to
> receive transmissions on behalf of the addressee, you must not retain,
> disclose in any form, copy or take any action in reliance on this
> transmission.  If you have received this transmission in error, please
> notify the sender as soon as possible and destroy this message.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This electronic transmission is strictly confidential to Smith & Nephew and
intended solely for the addressee.  It may contain information which is
covered by legal, professional or other privilege.  If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy or take any action in reliance on this
transmission.  If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Basic authentication question

[Boon Seong]

In that case, meaning it is a protected resource right ? Maybe u can try
using
the container's security feature such as putting this configuration in your
web application's web.xml file.



  admin page
  /admin/*




FORM

  /admin/login.jsp
  /admin/error.jsp

 

- Original Message -
From: "Koes, Derrick" <[EMAIL PROTECTED]>
To: "'Tomcat Users List'" <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 6:31 PM
Subject: RE: Basic authentication question


>
> Unfortunately, this does not work.
> Tomcat seems to use 401 as a prompt to put up the basic auth login dialog.
> If you add the configuration below, it goes to this page first without
ever
> prompting for user login.
>
> Do you have any other suggestions?
>
> Thanks,
> Derrick
>
>
>
> -Original Message-
> From: Boon Seong [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 25, 2003 5:27 PM
> To: Tomcat Users List
> Subject: Re: Basic authentication question
>
> add this to the web.xml
>
> 
> 401
> /errorpage.jsp
>   
>
> - Original Message -
> From: "Koes, Derrick" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 25, 2003 6:22 PM
> Subject: Basic authentication question
>
>
> >
> > I wish to replace tomcat's 401 error page with something more elegant
and
> > specific to my web app.  How can I do this?
> >
> > Thanks,
> > Derrick
> >
> >
> >
> > This electronic transmission is strictly confidential to Smith & Nephew
> and
> > intended solely for the addressee.  It may contain information which is
> > covered by legal, professional or other privilege.  If you are not the
> > intended addressee, or someone authorized by the intended addressee to
> > receive transmissions on behalf of the addressee, you must not retain,
> > disclose in any form, copy or take any action in reliance on this
> > transmission.  If you have received this transmission in error, please
> > notify the sender as soon as possible and destroy this message.
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> This electronic transmission is strictly confidential to Smith & Nephew
and
> intended solely for the addressee.  It may contain information which is
> covered by legal, professional or other privilege.  If you are not the
> intended addressee, or someone authorized by the intended addressee to
> receive transmissions on behalf of the addressee, you must not retain,
> disclose in any form, copy or take any action in reliance on this
> transmission.  If you have received this transmission in error, please
> notify the sender as soon as possible and destroy this message.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Basic authentication question

[Koes, Derrick]

Unfortunately, this does not work.
Tomcat seems to use 401 as a prompt to put up the basic auth login dialog.
If you add the configuration below, it goes to this page first without ever
prompting for user login.

Do you have any other suggestions?

Thanks,
Derrick



-Original Message-
From: Boon Seong [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 25, 2003 5:27 PM
To: Tomcat Users List
Subject: Re: Basic authentication question

add this to the web.xml


401
/errorpage.jsp
  

- Original Message -
From: "Koes, Derrick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 6:22 PM
Subject: Basic authentication question


>
> I wish to replace tomcat's 401 error page with something more elegant and
> specific to my web app.  How can I do this?
>
> Thanks,
> Derrick
>
>
>
> This electronic transmission is strictly confidential to Smith & Nephew
and
> intended solely for the addressee.  It may contain information which is
> covered by legal, professional or other privilege.  If you are not the
> intended addressee, or someone authorized by the intended addressee to
> receive transmissions on behalf of the addressee, you must not retain,
> disclose in any form, copy or take any action in reliance on this
> transmission.  If you have received this transmission in error, please
> notify the sender as soon as possible and destroy this message.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This electronic transmission is strictly confidential to Smith & Nephew and
intended solely for the addressee.  It may contain information which is
covered by legal, professional or other privilege.  If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy or take any action in reliance on this
transmission.  If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Basic authentication question

[Boon Seong]

add this to the web.xml


401
/errorpage.jsp
  

- Original Message -
From: "Koes, Derrick" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 6:22 PM
Subject: Basic authentication question


>
> I wish to replace tomcat's 401 error page with something more elegant and
> specific to my web app.  How can I do this?
>
> Thanks,
> Derrick
>
>
>
> This electronic transmission is strictly confidential to Smith & Nephew
and
> intended solely for the addressee.  It may contain information which is
> covered by legal, professional or other privilege.  If you are not the
> intended addressee, or someone authorized by the intended addressee to
> receive transmissions on behalf of the addressee, you must not retain,
> disclose in any form, copy or take any action in reliance on this
> transmission.  If you have received this transmission in error, please
> notify the sender as soon as possible and destroy this message.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Basic authentication question

[Koes, Derrick]

I wish to replace tomcat's 401 error page with something more elegant and
specific to my web app.  How can I do this?

Thanks,
Derrick



This electronic transmission is strictly confidential to Smith & Nephew and
intended solely for the addressee.  It may contain information which is
covered by legal, professional or other privilege.  If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy or take any action in reliance on this
transmission.  If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

User Authentication question

[Aleksandr Shneyderman]

Here my scenario:

We have two applications runing on the same
server (App A and App B)

What we'd like to do is to allow one login 
prompt but two different role initializations.

In other words suppose the user browses the web 
site and comes upon a page that she needs to
authenticate herself for. The sever redirects the
user to the login page and upon submission of 
her credentials she gets auhtenticated by an LDAP 
serevr and her roles are generated. The application 
A uses the LDAP to generate roles (groups), while 
application B uses a database. 

Wihle I suspect that I need to use SingleSignOn valve
to have a unified session accross the contexts I am
not quite sure how to do the role assignment.

I can see bits of the solution here and there but
I can not see the whole picture. I have read the 
JAAS developer's guide and even came accross JAASRealm
class (which I can't find the doc for). I am just not
quite sure how to put that info to use.

If anyone have a resource that will help me out to 
the solution I would appreciate your information. Or you
might have a clear idea of how to do it, that would be
even better :-)

Thanks,
Alex.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: BASIC Authentication Question

[Christopher K . St . John]

Mark Shaw wrote:
> 
> In subsequent requests I pass back the sessionID (in a cookie
> labeled "jsessionid"...) instead of the BASIC authentication
>

 You need to include the authentication information with
every request for a protected resource, or you're going 
to get another challenge. rfc2617 says:

  2 Basic Authentication Scheme
  ...
  A client SHOULD assume that all paths at or deeper
  than the depth of the last symbolic element in the
  path field of the Request-URI also are within the
  protection space specified by the Basic realm value
  of the current challenge. A client MAY preemptively
  send the corresponding Authorization header with
  requests for resources in that space without receipt
  of another challenge from the server.


-- 
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com

--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: BASIC Authentication Question

[Paul Chen]

Have you turn on the SingleSignOn valve in server.xml?

-Paul

Mark Shaw wrote:

>I'm hoping someone can shed some light on a particular behavior I'm
>experiencing with BASIC authentication and session cookies:
> 
>I've set up my servlet to use BASIC authentication and I'm my own very
>simple realm implementation:
>  protected String getPassword(String username) { return "tomcat"; }
>  protected Principal getPrincipal(String username) {
>List roles = new ArrayList();
>roles.add("test");
>return new GenericPrincipal(this, "tomcat", "tomcat", roles);
>  } 
> 
>I have a Java client that connects to my servlet via a URL connection,
>identical to the code in org.apache.catalina.ant.AbstractCatalinaTask,
>passing in "tomcat" for user and password in the first request which works
>great!  In subsequent requests I pass back the sessionID (in a cookie
>labeled "jsessionid"...) instead of the BASIC authentication, but my request
>fails ["This request requires HTTP authentication (Unauthorized)"] although
>my session ID is recognized by the servlet.  I figured my initial
>authentication was cached so that I only needed to send the session ID and
>not pass the authentication string in the header each time - this seems to
>be the behavior of the Manager App when I dump its Request/Response headers.
>Any ideas how I can accomplish this from a Java client: only sending
>authentication once, then using the session ID cookie from then on?  What's
>even stranger is that if I pass both the BASIC authentication header and my
>session ID every time it works great and my session is recognized, but my
>realm methods (see above) are never called, so the authentication must be
>stashed somewhere?
> 
>Thanks for any help,
>-Mark
>



--
To unsubscribe:   
For additional commands: 
Troubles with the list: 

Re: BASIC Authentication Question

[Craig R. McClanahan]

On Wed, 6 Mar 2002, Mark Shaw wrote:

> Date: Wed, 6 Mar 2002 22:37:17 -0800
> From: Mark Shaw <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
> Subject: BASIC Authentication Question
>
> I'm hoping someone can shed some light on a particular behavior I'm
> experiencing with BASIC authentication and session cookies:
>
> I've set up my servlet to use BASIC authentication and I'm my own very
> simple realm implementation:
>   protected String getPassword(String username) { return "tomcat"; }
>   protected Principal getPrincipal(String username) {
> List roles = new ArrayList();
> roles.add("test");
> return new GenericPrincipal(this, "tomcat", "tomcat", roles);
>   }
>
> I have a Java client that connects to my servlet via a URL connection,
> identical to the code in org.apache.catalina.ant.AbstractCatalinaTask,
> passing in "tomcat" for user and password in the first request which works
> great!

One of the best aspects of open source ... you can see what worked for
somebody else :-).

>  In subsequent requests I pass back the sessionID (in a cookie
> labeled "jsessionid"...) instead of the BASIC authentication, but my request
> fails ["This request requires HTTP authentication (Unauthorized)"] although
> my session ID is recognized by the servlet.  I figured my initial
> authentication was cached so that I only needed to send the session ID and
> not pass the authentication string in the header each time - this seems to
> be the behavior of the Manager App when I dump its Request/Response headers.
> Any ideas how I can accomplish this from a Java client: only sending
> authentication once, then using the session ID cookie from then on?  What's
> even stranger is that if I pass both the BASIC authentication header and my
> session ID every time it works great and my session is recognized, but my
> realm methods (see above) are never called, so the authentication must be
> stashed somewhere?
>

When you use BASIC authentication, Tomcat 4 currently expects that you
will include the "Authorization" header on every request, even though it
does cache the authenticated Principal when you are in a session.
Looking at the specs (http://www.ietf.org/rfc/rfc2617.txt>, it is not
stated that this is required, so this behavior could probably be relaxed
(when within a session) without ill effects.

One possibly negative side effect would be the case where the server's
user database changes the password for this username (or removes it
entirely) -- the previous authentication would still work for the duration
of the current session.  That's what happens already with form-based
login, so it's probably ok.

Could you please post this as an enhancement request to our bug tracking
system (http://nagoya.apache.org/bugzilla) to make sure it does not get
lost?

> Thanks for any help,
> -Mark
>

Craig

PS:  Has anyone had any success trying to force a logout (and subsequent
re-authentication)  of a BASIC authentication when the current session is
invalidated or times out, without requiring that the user close down and
restart the browser?  It would be very useful in Servlet 2.4 to know
whether or not this is techically feasible -- if it is, we can think about
mandating it as standard behavior so that applications do not have to care
which login method is being used.




--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

BASIC Authentication Question

[Mark Shaw]

I'm hoping someone can shed some light on a particular behavior I'm
experiencing with BASIC authentication and session cookies:
 
I've set up my servlet to use BASIC authentication and I'm my own very
simple realm implementation:
  protected String getPassword(String username) { return "tomcat"; }
  protected Principal getPrincipal(String username) {
List roles = new ArrayList();
roles.add("test");
return new GenericPrincipal(this, "tomcat", "tomcat", roles);
  } 
 
I have a Java client that connects to my servlet via a URL connection,
identical to the code in org.apache.catalina.ant.AbstractCatalinaTask,
passing in "tomcat" for user and password in the first request which works
great!  In subsequent requests I pass back the sessionID (in a cookie
labeled "jsessionid"...) instead of the BASIC authentication, but my request
fails ["This request requires HTTP authentication (Unauthorized)"] although
my session ID is recognized by the servlet.  I figured my initial
authentication was cached so that I only needed to send the session ID and
not pass the authentication string in the header each time - this seems to
be the behavior of the Manager App when I dump its Request/Response headers.
Any ideas how I can accomplish this from a Java client: only sending
authentication once, then using the session ID cookie from then on?  What's
even stranger is that if I pass both the BASIC authentication header and my
session ID every time it works great and my session is recognized, but my
realm methods (see above) are never called, so the authentication must be
stashed somewhere?
 
Thanks for any help,
-Mark

RE: Authentication question...

[Guido Medina]

and I forgot it, thank you...Guido

-Original Message-
From: Randy Layman [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 2:42 PM
To: Tomcat Users List
Subject: RE: Authentication question...


String username = request.getRemoteUser();

(Remember JSPs are just servlets).

> -Original Message-
> From: Guido Medina [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 17, 2001 2:20 PM
> To: '[EMAIL PROTECTED]'
> Subject: Authentication question...
> 
> 
> Is there any method to get on a JSP the user authenticated 
> through JDBCRealm
> ?
> 

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: Authentication question...

[Guido Medina]

I know, that's what I was asking, the method (JSP & Servlet)

-Original Message-
From: Randy Layman [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 17, 2001 2:42 PM
To: Tomcat Users List
Subject: RE: Authentication question...


String username = request.getRemoteUser();

(Remember JSPs are just servlets).

> -Original Message-
> From: Guido Medina [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 17, 2001 2:20 PM
> To: '[EMAIL PROTECTED]'
> Subject: Authentication question...
> 
> 
> Is there any method to get on a JSP the user authenticated 
> through JDBCRealm
> ?
> 

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: Authentication question...

[Randy Layman]

String username = request.getRemoteUser();

(Remember JSPs are just servlets).

> -Original Message-
> From: Guido Medina [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 17, 2001 2:20 PM
> To: '[EMAIL PROTECTED]'
> Subject: Authentication question...
> 
> 
> Is there any method to get on a JSP the user authenticated 
> through JDBCRealm
> ?
> 

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Authentication question...

[Guido Medina]

Is there any method to get on a JSP the user authenticated through JDBCRealm
?

Re: FORM-based authentication question

[Craig R. McClanahan]

On Fri, 7 Sep 2001, Kevin HaleBoyes wrote:

> Date: Fri, 7 Sep 2001 16:48:01 +0100 (BST)
> From: Kevin HaleBoyes <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: FORM-based authentication question
>
> I'm successfully using FORM-based logins in my application but I have
> a few questions.  When a user logs in, I want to attach certain information
> to the session.  Currently I use a filter that checks to see if the
> request.getRemoteUser is set (or has changed) and if so, I do a database
> call to get the User information, instantiate a UserClass and set it into
> the session.  It works fine but...
>
> The filter gets called for every request but only acts when a user logs in.
> Sure the test (to see if anything needs to be done) is simple and fairly
> quick, but it is done for _every_ request.
>
> Is there a better way?
>
> I'm thinking something similar in style to the HttpSessionListener
> interface. Maybe an AuthenticationListener.  Tomcat 4 (or any Servlet
> 2.3 container :) "knows" when a user has been authenticated (or, for
> that matter, when the authentication/session times out) but I don't
> see any way to hook into that event.  The timed out session
> information can be had using the
> HttpSessionListener.sessionDestroyed() method and my application knows
> if, in the very rare case :-) that a user actually logs out.  But
> notification of an authentification seems to be missing (from the
> spec).
>
> The HttpSessionListener.sessionCreated() method doesn't do what I want since
> a session is created even when a user is not authenticated.
>
> How do others attach information to the session once a user has been
> authenticated?
>

You can use HttpSessionListener to detect when the session is created or
destroyed, but there are no servlet API mechanisms that let you hook in to
the "user was authenticated" event.  You could write a Tomcat-specific
mechanism to do that, but for a portable application the filter approach
seems to me to be the best.

> Thanks,
> Kevin HaleBoyes
>

Craig

FORM-based authentication question

[Kevin HaleBoyes]

I'm successfully using FORM-based logins in my application but I have
a few questions.  When a user logs in, I want to attach certain information
to the session.  Currently I use a filter that checks to see if the
request.getRemoteUser is set (or has changed) and if so, I do a database
call to get the User information, instantiate a UserClass and set it into
the session.  It works fine but...

The filter gets called for every request but only acts when a user logs in.
Sure the test (to see if anything needs to be done) is simple and fairly
quick, but it is done for _every_ request.

Is there a better way?

I'm thinking something similar in style to the HttpSessionListener interface.
Maybe an AuthenticationListener.  Tomcat 4 (or any Servlet 2.3 container :)
"knows" when a user has been authenticated (or, for that matter, when the
authentication/session times out) but I don't see any way to hook into that
event.  The timed out session information can be had using the
HttpSessionListener.sessionDestroyed() method and my application knows
if, in the very rare case :-) that a user actually logs out.  But notification
of an authentification seems to be missing (from the spec).

The HttpSessionListener.sessionCreated() method doesn't do what I want since
a session is created even when a user is not authenticated.

How do others attach information to the session once a user has been
authenticated?

Thanks,
Kevin HaleBoyes



Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie