Antwort: Re: Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm
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("<
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]
Re: Antwort: RE: Antwort: RE: Antwort: RE: user principal, realm
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 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
>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 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
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 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]
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 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: user principal, realm
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]
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]
RE: Antwort: RE: user principal, realm
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: 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.
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: user principal, realm
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]
