InfoCenter Home > 5.5: Certificate-based authenticationCertificates and keys are part of an authorization mechanism supported in WebSphere Application Server. Instead of requiring each component of an application to log users in, a certificate-based authentication mechanism centralizes the login process. In such a system, users need to explicitly prove their identities only to a certificate authority (CA). A CA is a trusted third party; components of a system agree to trust the CA to do the necessary authentication for them. When the CA authenticates a user, it issues the user a certificate that contains a variety of data, including the identity of the issuing CA, how much the CA trusts the user, and an expiry date for the certificate. Other components of the system can read the user's certificate to determine if the certificate (and thus the identity it represents) is valid. To use certificates for authentication in WebSphere Application Server, choose Lightweight Third-Party Authentication (LTPA) as your authentication mechanism. Certificate-based authentication relies on several related technologies:
In order for certification to work, a system requires three things:
TrustIn order to accept third-party certificates from users, the components of the system need some way to know which CAs to trust. This is handled by creating a trust base, a collection of certificates authenticating the CAs themselves. Certificate authorities can be commercial ventures--companies that offer certification as their business--or they can be local entities. Creating the trust base is part of the work of the system administrator, who must contact commercial CAs (if used), configure local CAs (if used), and build the trust base. Each certificate issued to a user identifies the CA that issued the certificate. The component examining the certificate decides whether the certificate is trustworthy by determining if the issuing CA is in the trust base. Maintaining the integrity of the trust base is a crucial part of third-party authentication. As with any authentication mechanism, a user's ability to present a valid certificate from a valid CA proves only that the user was able to meet the CA's requirements for proving identity. It does not prove that the user is not malicious, using a stolen identity, or otherwise undesirable. Procedures for establishing trust in those scenarios are application- and site-specific. A site with stringent requirements can choose to pay a commercial certification company that agrees to impose requirements on those who request certificates, and a site doing testing can create certificates that impose no requirements at all. Administrators for each application must determine how thorough the CAs must be. Protection from forgeryEven if all the certificates in a system appear to be issued by trusted CAs, the certificates are worthless if they can be easily forged (for example, to create certificates for unauthorized users) or tampered with (for example, to give users "better" certificates than they are permitted to have). To preserve their contents, certificates are protected using digital signatures based on a public-key encryption strategy, making the forgery of and tampering with certificates (or any other data) impossible in practice. Use of certificates by ownersIf an intact certificate issued by a trusted CA can be used by someone other than the rightful owner of the certificate, the authentication system has failed. The system of digital signatures based on public-key encryption provides not only a way to ensure that certificates are intact; it also guarantees that the certificate can be used only by its rightful owner. The mechanics of public-key encryption ensure that a stolen certificate is useless. |
| ||
|