This article describes ways in which SecureAuth IdP services provide the most secure authentication functionality possible via the usage 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.
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 sections below.
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
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 bi-directional 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.
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, click the documentation link pertinent to the SecureAuth IdP version used in the environment