-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Andrew,
On 12/2/14 8:09 AM, Andrew Gronosky wrote: > > On 2014-12-02 04:55, John Dunn wrote: >> I have been asked the following question during an audit, which >> I personally don't understand. >> >> "When using Mutually authenticated TLS is authorisation based on >> the certificate name(and not just on the root CA)?" Just to be clear: none of this matters if you aren't using "client certificates" to identify clients. If you are using plain-old TLS for encryption and site-identity, then the answer to this question is "we don't use mutual TLS authentication/authorization". >> Can anyone clarify what exactly this means and whether Tomcat >> supports this? >> >> Cheers > > I believe the question is asking whether, during the > authentication process, Tomcat inspects the certificate and reads > the CN of the client cert, then matches it against the set of known > users (defined in whatever Realm you are using). +0.95 Technically, the TLS handshake is over before Tomcat gets to inspect the cert's CN and the Realm does anything with it. In the case of the TLS handshake, it's part authentication (determining who you are) and part authorization (determining if you are allowed to do something). For the TLS handshake, the configuration of your truststore and those certificates that are within that truststore are what matter. If you trust the certificate that signed all of your client certificates, then you will authorize all client certificates to complete TLS handshakes and thus access your web application. If you trust individual certificates (more fine-grained control, but a pain in the neck to administer) then you are using your TLS certificate trust for authorization at the individual (person) certificate level and not "a root CA" (note that the signing certificate doesn't have to be a CA in the usual sense... you can create a local CA that can sign certificates). > I found out just yesterday that the answer is yes, at least for > Tomcat 7. > > There are really two things going on with the client certs in > mutual authentication. First, the server requests the client cert > in order to complete the TLS handshake and establish a connection. > Next, *after* the TLS connection is open, if the resource being > accessed has an auth-constraint in web.xml, Tomcat checks the CN, > matches it to a user name, maps that name to a role, and checks > that the role is allowed to access the resource. +1 > As I discovered yesterday, if you have a client cert that is signed > by a CA that Tomcat trusts, but whose name (synonymously, CN) does > not map to a recognized user, then you will connect to Tomcat but > get an HTTP 401 error as your response. If the user name is > recognized but lacks the required role, you get HTTP 403. You already corrected this to be 401, which is correct. So, Tomcat can block (or admit) users either by only trusting the individual client certificates or by trusting all certificated signed by a CA and then a second authorization step will occur after the TLS handshake, where you can configure authorization based upon your user-mapping. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUfjI5AAoJEBzwKT+lPKRYY3UP/3EZiiHWULHOV92qNsgdBUeV rrUqg7GaghDNkc4b9IgkVbnLrIv7A5/Sft0CPf8vdrp6Xrdn2uV7HpfJmQ2Max9w CW9DG+sGqf9yILgKDiKw9YLgY9nyp6jRySJNhdlGAmZD0+AcDjaTAcSw0dCe7EBw cmCYbNKAA5wfurWJsPCSqA9/8sbtExIR+ShB3M1kImgmQopdTOSUH6G9Yomp2aB+ mU1loKNoqEaMrA1GAVov5LTgcmJV46C1+HoS2F0aEPYgXIi8yOtl6XD2oUFLMQi7 HVTeTqIyXHRtO4uTeYYlDO26BVUBGCtDBebt7FCQqNNtp4mFIRgnwPxkEDKBLX+T zk3OOUdX05D9nv8Gs3WoUU/ybCTjNM2RSydXX27nhx9hPGST8m1zyJW/o/9diBYw r/8RKAsij2XFeeXgKnn4+egOXHwtRe9aqdxAuYo7xf6VDAC0uDmX8DTGMkgere8+ kC3nnxL6IDaLK3ErLLwaZ3Jp1o1mVVMj331inSdTsj8DScHKlR8ALmSEjDeb+tJ5 M5NdDiPQnEUtcKH0t1izywqMMZYLS4OGgRxQTO64313P9WCUoem3irfOV5a/bwAh wWq3sTIosncifrdjR1lx3UWoDgwp/OPi2iBoVtoCqTYUoewCuQwt9W/cK8Oseuqu KgvYqTXw8PdKkXS0ffXh =5oE+ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
