DO NOT REPLY [Bug 34643] - document how to use certificate-based "clientAuth" on a per user or per session basis also with self-signed/expired client certs

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34643>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34643





------- Additional Comments From jackzhp@hotmail.com  2005-12-31 17:07 -------
Ralf said that <role-name>*</role-name> should be add into the <auth-
constraint> element. The inserted element authorizes all the right to access 
the resource to  the roles defined in this web application.

He is right, but I think that he is not absolutely right. It is obvious that we 
should not be forced to authorize the right to all the roles.

I put some information here, I hope that I can help some people to understand 
the stuff. Let's look at the bigger picture:
when the requested resource is constrained with different roles, we need a map 
between the user & the role to access the resource. Even when the resource is 
constrained with transfering, since the specification starts there is no access 
if no role is defined. In such a case, as Ralf said, we use "*" to indicate 
there is no role constraint.

We know that only the right persons are allowed to access the constrained 
resource. In a web application, we use two maps to define the right persons:
One map (1) is in application descriptor, in the security constraint. the map 
is between the resource & the roles to access it. Another map (2) is in tomcat-
users.xml, between persons identified by usernames & the roles.

When we use Basic, Digest, & Form, the user inputs his/her username & password 
for a specific resource. If the input password is same as the one stored with 
us, which is stored in tomcat-users.xml, too. we regard the user who is 
requiring the resource is the person defined in tomcat-users.xml. Furthermore, 
we can know his/her roles according to map 2, and we can know whether the user 
has the right to access the resource. In these cases, actually there is one 
more map (3) which is between the username & its password.

For whatever reasons, When we use "client-authentication", the relationship is 
not so clear. The most possible reason is the complication of this 
authentication. However, authentication is just a method to verify the user is 
the person he/she claimed to be. In those above cases, as long as the input 
password is same as the one stored with us, we regard the user as the person 
defined in tomcat-users.xml. Whether the person has the right to access the 
required resource, we will have to check the first two maps mentioned (map 1 & 
map 2).

In the case of "client-auth", as long as the certificate is verified, we 
believe that the user is the person. Now we can see, this authentication 
eliminate the neccessity for map 3. However, we still need map 2, the map 
between persons & roles. At present, map 2 is undefined.

In other methods, we use a username to identify a person. When using a 
certificate, it is not a simple thing to indentify a person (in certificate, 
they use the term "subject", in Java & tomcat, we use the term "principal"),
since the certificate system has to cover all human beings.
And it seems that the certificate system also introduce a map (4) between 
persons/subjects & certificates. So here, we need map 2 (between persons & 
roles) & map 4 (between persons & certificates). 

However, since certificates include usage information. So, it is reasonable to 
map certificates to roles. If we go with this direction, we might lose some 
flexibility, but more security control. Let's name this map as map 5. For 
tomcat, I believe that finally, both of them will be supported.

When the system has only a few users, then there is no problem no matter where 
we put all the certificates. When the system has many users, then we have to 
plan where to put these certificates, and how to verify them in order to have a 
better performance.
We have at least the following 5 options:
1. put in the keystore where we put our server authentication certificate.
2. put into a serie of xml file.
3. put into a local Database on the same machine or different machine.
4. put into LDAP on the same machine or different machine.
5. leave them on the internet
6. combination of these, for example ca certificate on local, others on the 
internet.

The team has developed many realms for us, and here are some extra information.

http://issues.apache.org/bugzilla/attachment.cgi?id=6666
implemented a class com.ops.webcontrol.tomcat.JNDIRealmCertAD

http://issues.apache.org/bugzilla/show_bug.cgi?id=7831
JDBCRealm

http://issues.apache.org/bugzilla/show_bug.cgi?id=34643

http://issues.apache.org/bugzilla/attachment.cgi?id=1499
org.apache.catalina.realm.JNDIRealm

http://issues.apache.org/bugzilla/attachment.cgi?id=14994

About how complicated it is to identify a subject, please refer to 
http://www.ietf.org/rfc/rfc2459.txt for more information.
For example, in a X509 certificate, (I am not sure whether there is any other 
kind of certificate system), The "subject" field is unique for that the CA 
issuing the certificate, but it might be empty. The "subjectUniqueID" field 
might be also only unique for this specific CA.

For his item C in comment #4, I guess the "clear SSL states" button which is 
besides the "certificates" button might help.
(In reply to comment #0)
> http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html#Edit%20the%
20Tomcat%20Configuration%20File
> nicely documents how to enable "clientAuth" on a global basis.
> A web application may well have a mixed user community, some authenticate by
> means of a password or other authenticators, others have a certificate for
> authentication.
> The goal of this RFE is to amend the documentation with how the clientAuth
> mechanism can be triggered and enforced on a per user basis.
> Interim results of my own little research:
> - if I request org.apache.catalina.Globals.SSL_CERTIFICATE_ATTR,
> org.apache.coyote.tomcat4.CoyoteRequest.getAttribute triggers the
> org.apache.coyote.ActionCode.ACTION_REQ_SSL_CERTIFICATE re-handshake
> - to enforce this for a given user, I guess I could store that certificate in
> the session and for every subsequent request test whether the cert is stored 
or
> otherwise trigger the re-handshake by asking for SSL_CERTIFICATE_ATTR.
> Open issues I haven't mastered so far:
> 1) If the application allows for self-signed certificates the user uploads 
into
> the DB i.e. her profile, is there a way to use a non-global trustStore to
> validate? Otherwise, with an increasing user-basis, I foresee scalability
> problems if I had to import all such certificates into a global trust store?
> 2) javax.net.ssl.SSLServerSocket.setNeedClientAuth in
> org.apache.tomcat.util.net.jsse.JSSE14SocketFactory.configureClientAuth might 
be
> the basis for an alternative approach, but I wouldn't know how to set that (or
> probably rather
> org.apache.tomcat.util.net.ServerSocketFactory.setAttribute("clientAuth", 
true)
> before the org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket has
> already occurred?
> related mailing list threads probably are:
> http://marc.theaimsgroup.com/?l=tomcat-user&m=105300671215744&w=2 and
> http://marc.theaimsgroup.com/?l=tomcat-user&m=104581231518394&w=2



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org