Re: Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm

2003-04-03 Thread Bill Barker
You got it: Authenticator is called before Filter.  If you want to get in
before the Authenticator is called, then you need to use the
(Tomcat-specific, and totally non-portable) Valve.

Oliver Wulff [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]

I wrote a custom HttpServletRequestWrapper and a filter. I've overriden the
method getUserPrincipal() and isUserInRole(). The second one just returns
true back (for test purposes).
Now, I have a problem if I define a security-constraint in the web.xml. I
get the following error if I try to access a secured servlet (filter is
activ):
Configuration error: Cannot perform access control without an authenticated
principal

I guess I have to write a custom realm for authorization purposes (which
roles the user belongs to). But Tomcat has to authenticate the user which
is already authenticated by Apache. The returned principal by
getUserPrincipal() is the authenticated user.

Is the authenticator called before the filter?

Hope you can help me...






*** BITTE BEACHTEN ***
Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
Ausschluss jeder Reproduktion zu zerstören und die absendende Person
umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.
=




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



RE: Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm

2003-04-03 Thread Ralph Einfeldt
From the code in 
catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java

Principal principal =
((HttpServletRequest) request.getRequest()).getUserPrincipal();
if (principal != null) {
if (debug = 1)
log(Already authenticated ' + principal.getName() + ');
return (true);
}

it looks like you shouldn't need a Realm if getUserPrincipal() returns 
a Principal.

The problem is that the security contrains are evaluated before the 
filter. So I guess that you may have to implement that what you want to 
achive with the constraints on your own. (Or you have to configure apache
to do it, and this way omit the constraints from tomcat.)

One tomcat specific way to come around that may be a Valve. (It is called 
before any filter, but I don't know if it is called before the evaluation 
of the constraints)

 -Original Message-
 From: Oliver Wulff [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 02, 2003 11:51 PM
 To: Tomcat Users List
 Subject: Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm
 
 
 I wrote a custom HttpServletRequestWrapper and a filter. I've 
 overriden the method getUserPrincipal() and isUserInRole(). The second one 
 just returns
 true back (for test purposes).
 Now, I have a problem if I define a security-constraint in 
 the web.xml. I
 get the following error if I try to access a secured servlet 
 (filter is
 activ):
 Configuration error: Cannot perform access control without an 
 authenticated
 principal
 

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



Re: Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm

2003-04-03 Thread Bill Barker
It's Tomcat-specific (and, so, non-portable to other servlet containers),
but yes, Valves are called before Authenticators.

Ralph Einfeldt [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
From the code in
catalina/src/share/org/apache/catalina/authenticator/BasicAuthenticator.java

Principal principal =
((HttpServletRequest) request.getRequest()).getUserPrincipal();
if (principal != null) {
if (debug = 1)
log(Already authenticated ' + principal.getName() + ');
return (true);
}

it looks like you shouldn't need a Realm if getUserPrincipal() returns
a Principal.

The problem is that the security contrains are evaluated before the
filter. So I guess that you may have to implement that what you want to
achive with the constraints on your own. (Or you have to configure apache
to do it, and this way omit the constraints from tomcat.)

One tomcat specific way to come around that may be a Valve. (It is called
before any filter, but I don't know if it is called before the evaluation
of the constraints)

 -Original Message-
 From: Oliver Wulff [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 02, 2003 11:51 PM
 To: Tomcat Users List
 Subject: Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm


 I wrote a custom HttpServletRequestWrapper and a filter. I've
 overriden the method getUserPrincipal() and isUserInRole(). The second one
 just returns
 true back (for test purposes).
 Now, I have a problem if I define a security-constraint in
 the web.xml. I
 get the following error if I try to access a secured servlet
 (filter is
 activ):
 Configuration error: Cannot perform access control without an
 authenticated
 principal





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



Antwort: Re: Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm

2003-04-03 Thread Oliver Wulff

I have to overwrite the getUserPrincipal in this valve. I tried the
following:

public void invoke(Request request, Response response, ValveContext
context)
throws IOException, ServletException
{
  logger.info(invoke);
  HttpRequestWrapper wrapper = new HttpRequestWrapper
((HttpServletRequest)request);
  context.invokeNext((Request)wrapper, response);
  logger.info(invoke);
}

and registred the valve in server.xml:
Valve className=zurich.RequestWrapperValve/

I have a servlet which returns the value of getUserPrincipal. I'm not sure
if this servlet will be called.
Am I doing anything wrong?






*** BITTE BEACHTEN ***
Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
Ausschluss jeder Reproduktion zu zerstören und die absendende Person
umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.



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



Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm

2003-04-02 Thread Oliver Wulff

I wrote a custom HttpServletRequestWrapper and a filter. I've overriden the
method getUserPrincipal() and isUserInRole(). The second one just returns
true back (for test purposes).
Now, I have a problem if I define a security-constraint in the web.xml. I
get the following error if I try to access a secured servlet (filter is
activ):
Configuration error: Cannot perform access control without an authenticated
principal

I guess I have to write a custom realm for authorization purposes (which
roles the user belongs to). But Tomcat has to authenticate the user which
is already authenticated by Apache. The returned principal by
getUserPrincipal() is the authenticated user.

Is the authenticator called before the filter?

Hope you can help me...






*** BITTE BEACHTEN ***
Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
Ausschluss jeder Reproduktion zu zerstören und die absendende Person
umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.



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



user principal, realm

2003-04-01 Thread Oliver Wulff
Hi

Can I implement a filter which sets the current principal, so that calls to
request.getUserPrincipal().getName() succeed?

In our company, an apache server in front of tomcat authenticates the
client and delegates the user principal as an http header attribute. I want
to read this principal and set the user principal in a filter. Can I do
this?

Thanks for your help!

Oliver






*** BITTE BEACHTEN ***
Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
Ausschluss jeder Reproduktion zu zerstören und die absendende Person
umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.



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



RE: user principal, realm

2003-04-01 Thread Ralph Einfeldt
Although I havn't tried it, I guess yes.

I think you have to define your own RequestWrapper
that lets you set the principal.

 -Original Message-
 From: Oliver Wulff [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, April 01, 2003 2:42 PM
 To: [EMAIL PROTECTED]
 Subject: user principal, realm
 
 
 Can I implement a filter which sets the current principal, so 
 that calls to
 request.getUserPrincipal().getName() succeed?
 
 In our company, an apache server in front of tomcat authenticates the
 client and delegates the user principal as an http header  attribute. 
 I want to read this principal and set the user principal in a filter. 
 Can I do this?
 

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



Antwort: RE: user principal, realm

2003-04-01 Thread Oliver Wulff

I took a look to JavaDoc and saw that all methods are deprecated. Is it
really the right way? My first thought was that it's very low level.
Doesn't there exist an easier solution for my problem?

**
Oliver Wulff
Zürich Versicherungs-Gesellschaft
IA4, CoC Middleware
Postfach, 8085 Zürich
Telefon: +41- 1 628 58 07
Fax: +41 - 1 623 58 07
E-Mail: mailto:[EMAIL PROTECTED]



   
   
  Ralph Einfeldt 
   
  [EMAIL PROTECTED] An:  Tomcat Users List [EMAIL 
PROTECTED]   
  ime-isc.de Kopie:   
   
  Thema:   RE: user principal, realm   
   
  01.04.2003 14:50 
   
  Bitte antworten an   
   
  Tomcat Users List  
   
   
   
   
   




Although I havn't tried it, I guess yes.

I think you have to define your own RequestWrapper
that lets you set the principal.

 -Original Message-
 From: Oliver Wulff [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, April 01, 2003 2:42 PM
 To: [EMAIL PROTECTED]
 Subject: user principal, realm


 Can I implement a filter which sets the current principal, so
 that calls to
 request.getUserPrincipal().getName() succeed?

 In our company, an apache server in front of tomcat authenticates the
 client and delegates the user principal as an http header  attribute.
 I want to read this principal and set the user principal in a filter.
 Can I do this?


-
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: Antwort: RE: user principal, realm

2003-04-01 Thread Ralph Einfeldt
Which class/methods are you talking about ?

 -Original Message-
 From: Oliver Wulff [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, April 01, 2003 5:02 PM
 To: Tomcat Users List
 Subject: Antwort: RE: user principal, realm
 
 I took a look to JavaDoc and saw that all methods are deprecated. 
 Is it really the right way? My first thought was that it's very low level.
 

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



Antwort: RE: Antwort: RE: user principal, realm

2003-04-01 Thread Oliver Wulff

org.apache.catalina.connector.RequestWrapper

I'm wondering if I could just implement my custom authenticator (compare
BasicAuthenticator.java) or a custom Realm. But I don't know how I can
register my authenticator.
As mentioned already I want to read the delegated user from a http header
attribute and register it. Here the way how the BasicAuthenticator does it:
register(request, response, principal, Constants.BASIC_METHOD, username,
password);

My problem, am I free in choosing a constant? I don't have a password
because authentication has been done in the apache server which is in front
of tomcat.

I don't know if I have to write a custom authenticator, a custom Realm or
overwrite RequestWrapper. In all cases, how can I integrate my custom
classes in tomcat? I don't want to build a custom tomcat release.
Integration should be possible by configuration.






*** BITTE BEACHTEN ***
Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
Ausschluss jeder Reproduktion zu zerstören und die absendende Person
umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.



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



RE: Antwort: RE: Antwort: RE: user principal, realm

2003-04-01 Thread Ralph Einfeldt
As I understood your problem I think that you have to
implement your own RequestWrapper as your username is 
not in an official attribute but a private one. (So 
tomcat wouldn't know how to give this information to 
a realm)

More on extending a RequestWrapper:
http://java.sun.com/products/servlet/Filters.html#72674

Also note that Realms are tomcat specific.

If you are trying o deal with Realms and BasicAuthenticator
these will couple your application strongly with tomcat:

Although the Servlet Specification describes a portable 
mechanism for applications to declare their security 
requirements (in the web.xml deployment descriptor), 
there is no portable API defining the interface between 
a servlet container and the associated user and role 
information. In many cases, however, it is desireable 
to connect a servlet container to some existing 
authentication database or mechanism that already exists 
in the production environment. Therefore, Tomcat 4 
defines a Java interface (org.apache.catalina.Realm) 
that can be implemented by plug in components to 
establish this connection. 

From: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.htm


 -Original Message-
 From: Oliver Wulff [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 02, 2003 9:25 AM
 To: Tomcat Users List
 Subject: Antwort: RE: Antwort: RE: user principal, realm
 
 
 
 org.apache.catalina.connector.RequestWrapper
 
 I'm wondering if I could just implement my custom 
 authenticator (compare BasicAuthenticator.java) or a 
 custom Realm. But I don't know how I can register my authenticator.
 As mentioned already I want to read the delegated user from a 
 http header
 attribute and register it. Here the way how the 
 BasicAuthenticator does it:
 register(request, response, principal, 
 Constants.BASIC_METHOD, username,
 password);
 
 My problem, am I free in choosing a constant? I don't have a password
 because authentication has been done in the apache server 
 which is in front
 of tomcat.
 
 I don't know if I have to write a custom authenticator, a 
 custom Realm or
 overwrite RequestWrapper. In all cases, how can I integrate my custom
 classes in tomcat? I don't want to build a custom tomcat release.
 Integration should be possible by configuration.
 
 
 
 
 
 
 *** BITTE BEACHTEN ***
 Diese Nachricht (wie auch allfällige Anhänge dazu) beinhaltet
 möglicherweise vertrauliche oder gesetzlich geschützte Daten oder
 Informationen. Zum Empfang derselben ist (sind) ausschliesslich die
 genannte(n) Person(en) bestimmt. Falls Sie diese Nachricht
 irrtümlicherweise erreicht hat, sind Sie höflich gebeten, diese unter
 Ausschluss jeder Reproduktion zu zerstören und die absendende Person
 umgehend zu benachrichtigen. Vielen Dank für Ihre Hilfe.
 
 
 
 -
 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]