A SAN certificate authenticates multiple explicitly-defined hostnames, the subjects indicated in a SAN certificate are listed, for example:
DNS Name: erp.acme.com
DNS Name: mail.acme.com
DNS Name: payroll.acme.com
A SAN certificate is widely considered to be more secure than a wildcard certificate. If a wildcard certificate falls into the wrong hands, then an attacker can pose as the legitimate organization through an unlimited number of hostnames. However, a similar compromise of a SAN certificate would only jeopardize the hostnames listed on that particular certificate.
Alternatively, the wildcard certificate has the advantage of flexibility, so you do not need to worry about altering your certificate in the future to accommodate more domain names. For this particular reason, as long as the private key of your wildcard certificate is properly secured, then you may consider the convenience of a wildcard certificate to outweigh the security benefits of a SAN certificate.
Cloud Access Manager offers a variety of ways to automate sign-on to suit all types of web application:
Many modern web applications support Single Sign-On (SSO) using identity federation protocols. These methods rely on a separate, independent web system, called an identity provider or Security Token Service which performs the task of authenticating the user.
When multiple applications rely on the same identity provider you only need to enter your credentials once, so SSO is achieved. Cloud Access Manager operates as an identity provider for applications which support SAML or WS-Federation SSO.
This method is generally considered the fastest, most cost-effective, reliable, and efficient way to implement single sign-on for those applications which support it. Some Software-as-a-Service (SaaS) providers levy an additional charge for use of federated SSO, however this should be weighed against the significant advantages of this approach.
Applications which require HTTP Basic or NT LAN Manager (NTLM) authentication rely on the browser to capture your credentials using a pop-up dialog. Information is then passed to the application in HTTP headers which the application uses to check if the supplied credentials are correct. It is typical for web applications which accept HTTP basic or NTLM authentication to run on an internal corporate network.
When such an application is accessed using the One Identity Cloud Access Manager proxy, the proxy can automatically construct the HTTP headers, as the browser would do. By using the username and password previously stored for a user, sign on to the application is automated.
If the application accepts HTTP Basic or NTLM authentication, this approach to Single Sign-On (SSO) is preferred over form-fill techniques, for further information please refer to Proxied form-fill.
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center
