Java Reference
In-Depth Information
Client Certificate Authentication
When you buy things or trade stocks on the Internet, you use the HTTPS protocol to obtain a
secure connection with the server. HTTPS isn't only an encryption mechanism—it can also
be used for authentication. When you first interact with a secure website, your browser re-
ceives a digitally signed certificate from the server that identifies it. Your browser verifies
this certificate with a central authority like VeriSign. This is how you guarantee the identity
of the server you are interacting with and make sure you're not dealing with some man-in-
the-middle security breach.
HTTPS can also perform two-way authentication. In addition to the client receiving a signed
digital certificate representing the server, the server can receive a certificate that represents
and identifies the client. When a client initially connects to a server, it exchanges its certific-
ate and the server matches it against its internal store. Once this link is established, there is
no further need for user authentication, since the certificate has already positively identified
the user.
Client Certificate Authentication is perhaps the most secure way to perform authentication
on the Web. The only disadvantage of this approach is the managing of the certificates them-
selves. The server must create a unique certificate for each client that wants to connect to the
service. From the browser/human perspective, this can be a pain, as the user has to do some
extra configuration to interact with the server.
Authorization
While authentication is about establishing and verifying user identity, authorization is about
permissions. Is my user allowed to perform the operation it is invoking? None of the
standards-based Internet authorization protocols discussed so far deals with authorization.
The server and application know the permissions for each user and do not need to share this
information over a communication protocol. This is why authorization is the domain of the
server and application.
JAX-RS relies on the servlet and Java EE specifications to define how authorization works.
Authorization is performed in Java EE by associating one or more roles with a given user
and then assigning permissions based on that role. While an example of a user might be
“Bill” or “Monica,” roles are used to identify a group of users—for instance, “adminstrator,”
“manager,” or “employee.” You do not assign access control on a per-user basis, but rather
on a per-role basis.
