It discusses these web client authentication types:
HTTP Basic Authentication
HTTP Digest Authentication
HTTPS Client Authentication
Form Based Authentication
And under "HTTPS Client Authentication", it says
End user authentication using HTTPS (HTTP over SSL) is a strong authentication mechanism. This mechanism requires the user to possess a Public Key Certificate (PKC) ...
...Client-certificate authentication is a more secure method of authentication than either BASIC or FORM authentication. It uses HTTP over SSL, in which the server and, optionally, the client authenticate one another with Public Key Certificates. Secure Sockets Layer (SSL) provides data encryption, server authentication, message integrity, and optional client authentication for a TCP/IP connection.
PS: No, the certificate doesn't necessarily need to come from somebody like Verisign. You can easily create your own, self-signed certificates with puttygen (Windows), openssl (Linux) or many other tools. [ September 07, 2006: Message edited by: Paul Santa Maria ]
The term "HTTPS client Authentication" is odd. It mixes two things that don't really have anything to do with each other - authentication and encryption. HTTP authentication and HTTP encryption (i.e., HTTPS) are orthogonal concepts - they can be used together or eahc of them individually.
HTTPS means using an encrypted connection; it requires the server to present a certificate in order to establish trust.
Authentication can be achieved by various means, as pointed out before. One of those is CLIENT-CERT, which requires a personal certificate to be imported into the browser, and then sent to the server. Note that this is a different certificate than the one used with SSL/HTTPS (which is a server certificate).
Paul Santa Maria
Joined: Feb 24, 2004
I think you're getting too hung up on the name.
Yes, I agree that encryption and authentication are two different things. Furthermore, "authorization" ("Are you privileged to look at this web page?": which is, after all, the whole *point* of these 4 "authentication" types) is yet a third completely different thing.
But provided we're all clear about what these terms actually mean, I'm OK with the name "HTTPS Client Authentication" ;-) [ September 08, 2006: Message edited by: Paul Santa Maria ]
Joined: Sep 03, 2006
HTTP authentication and HTTP encryption (i.e., HTTPS) are orthogonal concepts - they can be used together or eahc of them individually.
Thanks Ulf, that was exactly what was getting me confused. I came back to this thread to post what I had found in the Servlet Spec. In section SRV.12.5.4 (Page 95) it describes the various authentication methods (Basic, Digest, Form-based and HTTPS Client authentication).
This means that what the HF book refers to as CLIENT-CERT authentication is referred to in the Spec as HTTPS Client authentication. I think future versions of this book (which is great, BTW) could go to slightly greater lengths to distinguish between:
(i) HTTPS transport-level encryption (via <transport-guarantee> element). (ii) HTTPS-based authentication via client certificates.
I still have a few questions though...
Firstly, I just want to clarify part of Paul's quotation:
End user authentication using HTTPS...requires the user to possess a Public Key Certificate (PKC).
...It uses HTTP over SSL, in which the server and, optionally, the client authenticate one another with Public Key Certificates.
Question: Why is the authentication of the client optional?
Secondly, in the URL he references it shows an example DD for CLIENT-CERT with a <realm-name> element. However, in the Specification it says "The realm-name indicates the realm name to use in HTTP BASIC authentication." (Page 144). Is the spec being misleading here or is the example incorrect?
Finally, Pauls says:
No, the certificate doesn't necessarily need to come from somebody like Verisign. You can easily create your own, self-signed certificates with puttygen (Windows), openssl (Linux) or many other tools.
As I understand it this will create a certificate, but will will not be a "trusted" certificate since it doesn't come from a Certificate Authority (CA). Is this correct?
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com