How SecureAuth IdP Services Use Certificates for Secure Authentication
Introduction
This article describes ways in which SecureAuth IdP services provide the most secure authentication functionality possible through the use of X.509 digital certificates (SSL certificates) and personal certificates on end-user devices and browsers.
SecureAuth IdP services utilize SSL certificates in a Public key infrastructure (PKI) to enable secure Internet-based communications. In this manner, SecureAuth IdP leverages the strengths of PKI and SSL certificates while abstracting the complexity of traditional PKI.
An SSL (secure) certificate installed on a secure Web server is used to identify a website. This digital certificate establishes the identity and authenticity of the company or merchant so that online users can trust that the website is secure and reliable. In order to verify that these sites are legitimate (they are who they say they are), the companies and their websites are commonly verified by a third party, such as Verisign or Thawte.
See Introduction to Public-Key Cryptography for more information about how certificates are used in a PKI structure to ensure secure communications.
Applies to
SecureAuth IdP Version | OS Version |
|---|---|
7.x+ |
|
Usage of SecureAuth IdP-signed SSL Certificate
The SecureAuth IdP Appliance is shipped with a SecureAuth IdP-signed SSL certificate. Ways in which this SecureAuth IdP-signed SSL certificate is used by SecureAuth IdP and SecureAuth hosted services are described in the following sections.
SSL Protected Web Services
The SecureAuth IdP-signed SSL certificate shipped with the SecureAuth IdP Appliance is bound to the IIS default website to enable SSL connections.
The Common Name (CN) on this SSL certificate shipped with the SecureAuth IdP Appliance will most likely not match the actual Fully Qualified Domain Name (FQDN) of the SecureAuth IdP Appliance.
This certificate can be changed / replaced without affecting anything other than the basic SSL functionality of the default website, as long as the original SecureAuth IdP-signed certificate is not deleted.
Links to documentation for changing / replacing this SSL certificate that executes basic SSL functionality can be found below
IIS Version | SecureAuth Documentation |
|---|---|
6.0 | |
7.0 |
Appliance Identification
The SecureAuth IdP-signed SSL certificate shipped by default is used to identify each customer Appliance in SecureAuth's customer database.
This certificate "thumbprint" is registered and verified during the license check of each transaction / connection.
WSE / WCF Encryption
The SecureAuth IdP-signed SSL certificate shipped by default is also used to encrypt communications between the Appliance and SecureAuth's hosted services.
The public key of the certificate installed on SecureAuth's hosted services is also installed on each appliance in the "Other Certificates" store to permit bidirectional SSL validation. Communications occur over TCP 80 which is typically not encrypted, but as part of WSE / WCF, the payload is encrypted to enable easy firewall traversal.
For additional information, see "What is WSE / WCF Encryption and How is it Used with SecureAuth IdP?" in the article SecureAuth IdP Digital Certificate Overview.
Data Store Information Encryption (e.g. KBA / KBQ)
Additionally, the SecureAuth IdP-signed SSL certificate shipped by default is used as part of the encryption process to protect data in the data store whenever an end-user attempts to use Knowledge-Based Question-Answering as a Multi-Factor Authentication method.
Information for Knowledge Based Questions and Answers is stored in an LDAP attribute or database table depending upon the type of data store being used.
Two methods to protect data in the data store from being viewed are encryption and Base64 hashing. The merits of either can be determined by the customer and will not be discussed in this article.
If encryption is configured to protect data store information, an SSL certificate is used as part of the encryption process. The specific SSL certificate used for this encryption is determined by the certificate selected in the License Info section on the System Info tab of a realm configured as an end-user self-service page. The Web Admin can also be used to convert Base64 hashing to encryption
Options to convert from Base64 to encryption are also available via the Web Admin.
For information on configuring a realm to use KBA / KBQ as a Multi-Factor Authentication method, see Knowledge-based Authentication (KBA / KBQ) as 2-Factor Authentication Method Configuration Guide
Personal SSL Certificates (Native or Java)
As an optional credential to authenticate the end-user, SecureAuth IdP can deliver a Native or Java-based X.509 certificate to the end user's browser or device.
See "What is an Identity Certificate and How is it Used by SecureAuth IdP?" in the article SecureAuth IdP Digital Certificate Overview for information about how these certificates are used.