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 [EMAIL PROTECTED] 2005-12-31 17:08 ------- 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. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
