Tomcat IPV6 Test

2001-03-15 Thread jerome . camilleri

Just for informationand little question at this end.

I'am testing TOMCAT with java API for IPV6 at the moment and my only problem with your product is about 
traitment of number port in request Header which raise an NumberFormatException exception ...

Function parseHeaders() in class apache/catalina/connector/http/httpProcessor.java which manipulate 
request header http and extract portNumber.
MyURL is using the format for literal IPv6 addresses (described in RFC 2732).
A literal IPv6 address in a URL is the address enclosed in square brackets and 
eatch block is converted to hexadecimal and delimited with colons (eg: 1ffe:00D3::2F3B:02AA:00FF:FE28:00AA)

So my only modification is to convert line (number 531 of source product 4.0-b1)
int n = value.IndexOf(:);
by
int n = value.lastIndexOf(:); 
and that's run well

My question for tomcat's developpers is
do you think this problem can find in other place of your product ?

Thanks for your help.


Jérôme Camilleri
Bull Echirolles

Question about auth-method=CLIENT-CERT on web.xml file ?

2000-12-22 Thread jerome . camilleri



Yes I understand what you said about CLIENT-CERT and I add a new entry in my tomcat-usr.xml file : 
tomcat-users 
 user name=tomcat password=tomcat roles=tomcat / 
 user name=role1 password=tomcat roles=role1 / 
 user name=both  password=tomcat roles=tomcat,role1 / 
 user name=OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr password=tomcat roles=tomcat,role1 / 
/tomcat-users 

Functions getSubjectDN().getName() return OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr value for the 
first certificate chain, so I consider this value is the new user name. 
I have yet auth-method into CLIENT-CERT value and when I try to connect on my tomcat serveur I have the same message : 

You are not authorized to view this page 

My local_host_access.log file give me this information : 
camilleri - OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr [21/Dec/2000:11:07:50 1000] GET /examples/servlet/SnoopServlet HTTP/1.1 200 4017 
camilleri - OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr [21/Dec/2000:11:08:32 1000] GET /examples/servlet/SnoopServlet HTTP/1.1 403 - 

So I try to cut attribut password on tomcat-users file because when I use a certificate I don't understand what I would say... but 
with no success... 
Is it possible that value OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr as too complicate for a user name

Thank you if you are a another good idea ? 

Best Regards 

Jérôme

Craig McClanahan écrit :

[EMAIL PROTECTED] wrote:  
Hello, 

I try to use the auth-method of web.xml to CLIENT-CERT value like it's precise on web.dtd 
So the fragment of web.xml file 
 !-- Default login configuration uses form-based authentication -- 
 login-config 
 auth-methodCLIENT-CERT/auth-method 
 realm-nameExample Form-Based Authentication Area/realm-name 
 form-login-config 
 form-login-page/jsp/security/login/login.jsp/form-login-page 
 form-error-page/jsp/security/login/error.jsp/form-error-page 
 /form-login-config 
 /login-config 

When I try to access on a url-pattern who is protect by a security-constraint with https on port 8443, 
I always have the same response on the catalina server : 
 You are not authorized to view this page 
 
When you use CLIENT-CERT login plus a security constraint, what you are asking Catalina to do is look up the authenticated client in its Realm (by default, the MemoryRealm that reads from $CATALINA_HOME/conf/tomcat-users.xml), to (a) make sure that the client is present in the Realm, and (b) look up the associated roles to verify against the security constraint. 

The username that is looked up is the value returned by calling getSubjectDN().getName() on the first certificate in the certificate chain -- in other words, the principal name of the client that was authenticated by this certificate. 

If all you want to do is make sure the client has a valid certificate, you don't need to use a security constraint at all -- just set the clientAuth property on the Connector to true, and no requests will be accepted without a certificate. On the other hand, if you want to use security constraints in addition, you will need to define the user (and associated roles) in your Realm, just as you would for any other login method.  
Anybody know where do I find any information about this fonctionnality whas I bad used ? 

Best regards 

JérômeCraig McClanahan 


Question about CLIENT-CERT on web.xml file ?

2000-12-20 Thread jerome . camilleri



Hello,

I try to use the auth-method of web.xml to CLIENT-CERT value like it's precise on web.dtd 
So the fragment of web.xml file :
  !-- Default login configuration uses form-based authentication --
  login-config
   auth-methodCLIENT-CERT/auth-method
   realm-nameExample Form-Based Authentication Area/realm-name
   form-login-config
form-login-page/jsp/security/login/login.jsp/form-login-page
form-error-page/jsp/security/login/error.jsp/form-error-page
   /form-login-config
  /login-config

When I try to access on a url-pattern who is protect by a security-constraint with https on port 8443,
I always have the same response on the catalina server :
   You are not authorized to view this page


Anybody know where do I find any information about this fonctionnality whas I bad used ?

Best regards

Jérôme

RE:RE: Réf. : RE: X509 client certificate (Mr. McClanahan, please take alook at this)

2000-12-18 Thread jerome . camilleri



Excuse for my determination but my problem was not solve...

After change my serveur.xml to clientAuth=true like Craig R. McClanahan said,
I fall again on my first exception when I try to extract the certificate request because 
object associate with ùrequest attributes nameés 'javax.servlet.request.X509Certificate' 
aren't of well-known type java.security.cert.X509Certificate but [Ljava.security.cert.X509Certificate;@13a66f !

My snoop servlet give me this fragment information :
Request attributes:
  filters.ExampleFilter.SERVLET_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Servlet Mapped Filter, filterClass=filters.ExampleFilter])
  javax.servlet.request.key-size = 40
  javax.servlet.request.X509Certificate = [Ljava.security.cert.X509Certificate;@13a66f
  filters.ExampleFilter.PATH_MAPPED = InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter, filterClass=filters.ExampleFilter])
  javax.servlet.request.cipher-suite = SSL_RSA_EXPORT_WITH_RC4_40_MD5

and my catalina server crash on exception when I try to cast this strange objet to java.security.cert.X509Certificate
Exception dans le traitement de la requête sécurisée :
java.lang.ClassCastException: [Ljava.security.cert.X509Certificate;
at SnoopServlet.doGet(SnoopServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp


Any idea?

Best regards

Jérôme

stupid question on array return by javax.servlet.request.X509Certificateattribute

2000-12-18 Thread jerome . camilleri



Why the attribute 'javax.servlet.request.X509Certificate' return an array of X509Certificate.
I don't understand how it's possible because when my client choose an certificate, he chooses only one...
For my test array contain always one element... so is it an specification to anticipate the future ?

Best Regards

The type is javax.servlet.request.X509Certificate[] ?? ie an array not a
single instance..





[EMAIL PROTECTED] on 18/12/2000 05:03:48

Please respond to [EMAIL PROTECTED]

To:  [EMAIL PROTECTED]
cc:  [EMAIL PROTECTED] (bcc: Ken X Horn)
Subject: RE:RE: Réf. : RE: X509 client certificate (Mr. McClanahan,
   please take a look at this)



Excuse for my determination but my problem was not solve...

After change my serveur.xml to clientAuth=true like Craig R. McClanahan
said,
I fall again on my first exception when I try to extract the certificate
request because
object associate with ùrequest attributes nameés
'javax.servlet.request.X509Certificate'
aren't of well-known type java.security.cert.X509Certificate but
[Ljava.security.cert.X509Certificate;@13a66f !

My snoop servlet give me this fragment information :
Request attributes:
  filters.ExampleFilter.SERVLET_MAPPED =
InvokerFilter(ApplicationFilterConfig[name=Servlet Mapped Filter,
filterClass=filters.ExampleFilter])
  javax.servlet.request.key-size = 40
  javax.servlet.request.X509Certificate =
[Ljava.security.cert.X509Certificate;@13a66f
  filters.ExampleFilter.PATH_MAPPED =
InvokerFilter(ApplicationFilterConfig[name=Path Mapped Filter,
filterClass=filters.ExampleFilter])
  javax.servlet.request.cipher-suite = SSL_RSA_EXPORT_WITH_RC4_40_MD5

and my catalina server crash on exception when I try to cast this strange
objet to java.security.cert.X509Certificate
Exception dans le traitement de la requête sécurisée :
java.lang.ClassCastException: [Ljava.security.cert.X509Certificate;
at SnoopServlet.doGet(SnoopServlet.java:68)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp


Any idea?

Best regards

Jérôme

Jérôme

Réf. : RE: X509 client certificate

2000-12-13 Thread jerome . camilleri



Hi Stefan

I try to extract certicate to my request like you say in your mail but I have
an exception because object return by request.getAttribute( javax.servlet.request.X509Certificate )
method wasn't type of java.security.cert.X509Certificate but [Ljava.security.cert.X509Certificate; 

log file : 
2000-12-13 16:21:10 StandardWrapperValve[org.apache.catalina.INVOKER.SnoopServlet]: Servlet.service() for servlet org.apache.catalina.INVOKER.SnoopServlet threw exception
java.lang.ClassCastException: [Ljava.security.cert.X509Certificate;
at SnoopServlet.doGet(SnoopServlet.java:65)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterWrapper.doFilter(ApplicationFilterWrapper.java:159)
at filters.ExampleFilter.doFilter(ExampleFilter.java:136)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:258)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:936)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:311)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at org.apache.catalina.valves.CertificatesValve.invoke(CertificatesValve.java:152)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:934)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:1674)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161)
at org.apache.catalina.valves.ValveBase.invokeNext(ValveBase.java:242)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:343)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:934)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:159)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:936)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:787)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:904)
at java.lang.Thread.run(Thread.java:484)

Very strange but are you an idea about my problem?

Config : Apache Tomcat (v4.0-m1)

Jérôme






Stefán F. Stefánsson [EMAIL PROTECTED]
04/12/00 10:53
Veuillez répondre à tomcat-dev


Pour :[EMAIL PROTECTED]
cc :
Objet :RE: X509 client certificate


Hi Alexandre.

I'm not sure I fully understand your question but let me see if I can
help you at all.

The addSecureEndpoint method of EmbededTomcat used to be just like the
one you described below. I added the addSecureEndpoint(int port,
InetAddress addr, String hostname, String keyfile, String keypass,
boolean clientAuth) to be able to force the client to show a certificate
for logging in.

I want to answer you in a few steps, so please bear with me.

1.
Now, first of all I think you're going a little bit too long of a way
using the addSecureEndpoint. Wouldn't it be easier for you to call the
method I described above (the addSecureEndpoint(int, InetAddress,
String, String, String, boolean)) instead of calling the original one
(the addSecureEndpoint(int, InetAddress, String, String, String)) and
changing the code in that? The modifications to the original
addSecureEndpoint were for backwards compatability. In other words, the
original method, addSecureEndpoint added an endpoint with no client
authentication. I added a method that provides means for getting client
authentication by the means of client certificates, and modified the
original call to call my method with client authentication == false.
Hence, maintaining backwards compatability. I would say you should much
rather change the code in tomcat to what it was before and call
addSecureEndpoint(int, InetAddress, String, String, String, boolean) in
EmbededTomcat directly instead. That way you won't have to recompile
Tomcat every time you change your mind about requiring a client
certificate in your application.

2.
Now for your problem at hand ;o). I don't know exactly how the
getUserPrincipal method in HttpServletRequest class is supposed to work
but what I got from JavaDoc was:

Returns a java.security.Principal object containing the name of the
current authenticated user. If the user has not been authenticated, the
method returns null.

And from the JavaDoc for java.security.Principal, I got:

This interface represents the abstract notion of a principal, which can
be used to represent any entity, such as an individual, a corporation,
and a login id.

Now. You would think that Tomcat should serve up the DN of the client
certificate when a user calls request.getUserPrincipal but according to
you, it doesn't. I don't know if there are any reasons for that
although I doubt it. I