SSO: What is Single Sign On? Universal SSO Service for Enterprises

When navigating an app or a website, you’ve probably seen the option to log in with Facebook or Google. And next thing you know, you are magically signed into the third-party website without even making an account.

It’s not magic, it’s a single sign-on technology, or SSO. What is it, how does it work, and why do so many modern organizations use it for security reasons?

What SSO Means and How It Works

Single Sign-On is a user authentication process that lets users access multiple applications with one set of login credentials, like a username and password. This means that once a user is logged in, they don’t have to log in repeatedly for every application linked to this system.

Actually, single sign-on is a federated identity management arrangement between three entities:

Users — Individual people need to access different services. They should be able to manage personal information such as their login or password, and they should be uniquely identifiable.

Service providers (SP) — Traditionally, these are websites and applications that the users want to access, but they can include all sorts of products and services such as WiFi access, your phone, or “Internet of Things” devices.

Identity providers (IdP) — Databases that store user identities which can then be federated to various IT resources. They can also store many instantiations of user identity, which contain information such as usernames, passwords, SSH keys, biometric information, and other attributes. One of the most popular identity providers nowadays is Microsoft Active Directory which was designed to manage Windows usernames and passwords and connect them to on-premise Windows-based IT resources.

In order for SSO to work, most applications rely on open standard protocols to define how service providers and identity providers can exchange identity and authentication information with one another. The most common protocols are SAML, OAuth, and OpenID Connect (OIDC) which securely allow one service to access data from another.

Today, we can see a trend that companies are starting to realize: remote work from home means that more users have to log in to their accounts over the internet to access important information. And this is the whole new realm of potential attack vectors. Criminals already know this, and they are taking advantage of it. So more and more companies are starting to address those new threats by implementing SSO solutions.

Single Sign On Disadvantages and Advantages

The main advantage of SSO is the great user experience and convenience it brings to users. They have minimum passwords to remember, it streamlines the sign-in process, and lessens the chances of phishing.

SSO is especially great for businesses running remotely due to COVID-19 because single sign-on services provide the most secure and user-friendly authentication for remote logins. Using SSO can also be part of an integrated access management system for faster provisioning and de-provisioning of users.

On the other hand, SSO presents risks because it creates a single point of failure that can be exploited by attackers to gain access to other apps. Additionally, like many IT tools, SSO requires implementation and configuration that can get quite expensive.

Many SSO vendors charge individually by feature, so the fees add up quickly and can become a heavy burden on the budget of small or medium-sized businesses.

Anyway, we believe that the convenience of SSO is worth all the shortcomings it brings.

Single Sign-On Examples

A typical and good example for single sign-on is Google. Any user that is logged in to one of the Google services is automatically logged in to other services such as Gmail, Google Drive, Youtube, Google Analytics, and so on.

Single sign-on usually makes use of a central service that orchestrates the single sign-on between multiple clients, which in the case of Google is Google accounts.

Moving on to enterprise security, nowadays, there are a lot of single sign-on products and services for business. These are typically password managers with client and server components that log the user into target applications by replaying user credentials.

Hideez Authentication Service is one such example of secure SSO solutions. One of the unique benefits of Hideez SSO is that it allows combining basic authentication methods (username/password + one-time password) with fully passwordless logins (FIDO2 tokens or mobile application).

So, how does the Hideez Single Sign-On work?

Step 1. User accesses any Service provider, i.e. application supporting SAML or OpenID protocols;

Step 2. The Service provider sends SAML/OIDC request to the Hideez Server, and the user is automatically redirected to the Hideez server;

Single Sign-on Service

Step 3. User is prompted to fill in login details or select one of the available methods of authentication: a hardware security key (Yubikey, multifunctional Hideez Key or any other physical security token), or Hideez Authenticator mobile application;

Step 4. Hideez server sends an authentication result to the Service provider and redirects the user back to the initial application.

Step 5. A user is authenticated, probably without noticing anything except for a few redirecting calls at the URL bar of his browser.

Universal SSO Service by Hideez

Hideez Single Sign-On Service is a SAML Identity Provider (IdP) that adds SSO to Windows Active Directory using SAML 2.0 federation. Admins can configure single sign-on to any web or mobile application that supports OpenID Connect or SAML standards. And on top of that, we make SSO fully passwordless!

Unlike SSO with traditional password-based logins, Hideez SSO can eliminate passwords and replace them with FIDO2/Mobile App passwordless experience, where possible. Even if some of your applications do not support SAML or OIDC standards and cannot be made fully passwordless, you can use the Hideez Key as a hardware password manager and automatically fill in login credentials at the push of the button.

You can choose whichever authentication factor is most convenient for your employees:

Smartphones. Hideez Authenticator is an SSO app for Android and iOS devices. It can turn users’ smartphones into passwordless hardware tokens that replace their usernames and passwords with secure logon based on one-time QR codes using biometric verification or verification of the PIN code in the end-user's smartphone

Hardware security keys. Hideez Key tokens are multifunctional Bluetooth/NFC/USB devices protected by a PIN. You can use them to log in to services without passwords based on FIDO2 standard, store credentials for password-based logins, generate one-time passwords for 2FA, and even lock or unlock Windows computers based on device proximity.

Hideez Enterprise Server integrates with Microsoft Active Directory, Azure Active Directory, and LDAP identity systems to simplify onboarding and user management. Your employees can just use one SSO application to access all the things, making Hideez SSO Service super user friendly. Not to mention you don’t have to remember login credentials or think about preventing phishing and identity thefts.

Hideez outperforms all of the current competitors in convenience and price, offering full compliance with the strongest authentication standards, such as GDPR, NIST, PSD2, PSI-DSS, and HIPAA. By taking precautionary steps well in advance you can save so much money and time in the long run.

Schedule a demo or request a free 30-day trial of the Hideez SSO and capture the future of passwordless security!

Example of configuring ASA AnyConnect VPN to Hideez Enterprise Server through SAML

Hideez Enterprise Server (HES) supports SAML 2.0 (Security Assertion Markup Language) standard for user authentication. HES is an IdP (Identity Provider) that enables SSO for all web applications (SP, Service Provider) supporting SAML.

Since HES supports FIDO2 passwordless authorization, service providers automatically get the ability to authorize with hardware security keys without having to create and enter passwords.

Requirements

Cisco recommends that you have knowledge of these topics:

Basic knowledge of RA VPN configuration on ASA
Basic knowledge of SAML and Microsoft Active Directory.
AnyConnect Licenses enabled (APEX or VPN-Only).

Components Used

The information in this document is based on these software and hardware versions:

Hideez Enterprise Server 3.9+
Microsoft Active Directory
Cisco ASA 9.7+ and Anyconnect 4.6+
Working AnyConnect VPN profile

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command. You can also map users to specific application roles based on rules you define in your setting in Active Directory, Cisco ASA and Anyconnect.

Background Information

SAML is an XML-based framework for exchanging authentication and authorization data between security domains. It creates a circle of trust between the user, a Service Provider (SP), and an Identity Provider (IdP) which allows the user to sign in a single time for multiple services. Hideez Enterprise Server seamlessly integrates with Cisco ASA VPN appliance to provide additional security for the Cisco AnyConnect VPN logins.

SAML Components

Metadata: It is an XML based document that ensures a secure transaction between an IdP and an SP. It allows the IdP and SP to negotiate agreements.

Roles supported by the devices (IdP, SP)

A device may support more than one role and could contain values for both an SP and an IdP. Under the EntityDescriptor field is an IDPSSODescriptor if the information contained is for a Single Sign-On IdP or a SPSSODescriptor if the information contained is for a Single Sign-On SP. This is important since the correct values must be taken from the appropriate sections in order to set up SAML successfully.

Entity ID: This field is a unique identifier for an SP or an IdP. A single device might have several services and can use different Entity IDs to differentiate them. For example, ASA has different Entity IDs for different tunnel-groups that need to be authenticated. An IdP authenticating each tunnel-group has separate Entity ID entries for each tunnel-group in order to accurately identify those services.

ASA can support multiple IdPs and has a separate entity ID for each IdP to differentiate them. If either side receives a message from a device that does not contain an entity ID that has been previously configured, the device likely drops this message, and SAML authentication fails. The Entity ID can be found within the EntityDescriptor field beside entityID.

Service URLs: These define the URL to a SAML service provided by the SP or IdP. For IdPs, this is most commonly the Single Logout Service and Single Sign-On Service. For SPs, this is commonly the Assertion Consumer Service and the Single Logout Service.

The Single Sign-On Service URL found in the IdP metadata is used by the SP to redirect the user to the IdP for authentication. If this value is incorrectly configured, the IdP does not receive or is unable to successfully process the Authentication request sent by the SP.

The Assertion Consumer Service URL found in the SP metadata is used by the IdP to redirect the user back to the SP and provide information about the user's authentication attempt. If this is configured incorrectly, the SP does not receive the assertion (the response) or is unable to successfully process it.

The Single Logout Service URL can be found on both the SP and the IdP. It is used to facilitate logging out of all SSO services from the SP and is optional on the ASA. When the SLO service URL from the IdP metadata is configured on the SP, when the user logs out of the service on the SP, the SP sends the request to the IdP. Once the IdP has successfully logged the user out of the services, it redirects the user back to the SP using the SLO service URL found within the SP’s metadata.

SAML Bindings for Service URLs: Bindings are the method the SP uses to transfer information to the IdP and vice versa for services. This includes HTTP Redirect, HTTP POST, and Artifact. Each method has a different way of transferring data. The binding method supported by the service is included within the definition of that service. For example: SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://saml.example.com/simplesaml/saml2/idp/SSOService.php"/ >. The ASA does not support the Artifact binding. ASA always uses the HTTP Redirect method for SAML authentication requests, so it is important to choose the SSO Service URL that uses the HTTP Redirect binding so that the IdP expects this.

Certificates for Signature and Encryption Operations

To provide confidentiality and integrity for the messages sent between the SP and the IdP, SAML includes the ability to encrypt and sign the data. The certificate used to encrypt and/or sign the data can be included within the metadata so that the receiving end can verify the SAML message and ensure that it comes from the expected source. The certificates used for signing and encryption can be found within the metadata under KeyDescriptor use="signing" and KeyDescriptor use="encryption", respectively, then X509Certificate. The ASA does not support encrypting SAML messages.

Configure HES as an IdP

Step 1. Set Identity Provider settings

IdPs and service providers must exchange public key certificates, addresses for requests, and other parameters to establish an acceptance between them.

A certificate in the “.pfx” format is necessary for the work of the SAML protocol. It can be generated, for example, through an OpenSSL application or by using an existing certificate. The certificate file must be copied to the HES server (e.g. the folder with binary files and settings).

Select your .pfx file and enter the password for the .pfx. Also you need to select appropriate algorithm:

SignatureAlgorithm - a signature algorithm. It should match the algorithm with which the pfx certificate was established. The possible options are SHA1, SHA256, SHA384, SHA512.

Step 2. Get HES Metadata File

On the same page (Settings -> Parameters -> SAML), after you have set the .pfx certificate you can:

View metadata · Download metadata · Download the public key certificate

Metadata is an XML file that contains all the necessary information about the IdP settings and the public key certificate. ASA allows you to import IdP metadata when configuring SAML, which simplifies the configuration. You can also download a separate certificate, if necessary, or view all metadata on the screen.

For the next steps you need to download the metadata file and certificate files.

Configure ASA for SAML via CLI

Step 1. Create a Trustpoint and import our SAML certificate

# config t

# crypto ca trustpoint HES-SAML

revocation-check none

no id-usage

enrollment terminal

no ca-check

# crypto ca authenticate HES-SAML

-----BEGIN CERTIFICATE-----

…

HES IdP Certificate Text you downloaded on the previous step.

…

-----END CERTIFICATE-----

# quit

Step 2. Provision your SAML IdP

# webvpn

# saml idp https://example.hideez.com/

# url sign-in https://example.hideez.com/Saml/Login

# url sign-out https://example.hideez.com/Saml/Logout

# trustpoint idp HES-SAML - [IdP Trustpoint]

# trustpoint sp ASA-EXTERNAL-CERT - [SP Trustpoint]

# no force re-authentication

# no signature

# base-url https://asa.example.com

Step 3. Apply SAML Authentication to a VPN Tunnel Configuration

# tunnel-group TUNNEL-GROUP-NAME webvpn-attributes

saml identity-provider https://example.hideez.com/

authentication saml

# end

# write memory

Step 4. Get SAML ASA Metadata FIle

Run the following command:

# show saml metadata TUNNEL-GROUP-NAME

Then copy metadata text into a xml file and save it.

Note: If you make changes to the IdP config you need to remove the saml identity-provider config from your Tunnel Group and re-apply it for the changes to become effective.

Add the Service Provider to HES

On the following form you can add a metadata file or fill all parameters manually:

Issuer - a unique SP name you need to copy from the SP settings or extract from the metadata file.
Assertion Consumer Service - the login address on the side of the service provider. Redirection is done to this address following the successful login through the IdP service.
Single Logout Service - the address to log out of the account. If you exit IdP, this URL is opened in the loop for all SPs.
Public x509 Certificate - the public key certificate of the service provider.
Name Identifier Format - the format for the field that identifies the user.
Name Identifier Field - the choice of the field where you can take the user identifier.

Since the IdP and the SP can use different identifiers for users, a mechanism for matching these identifiers is needed to establish a one-to-one correspondence between users in both services. The user identifier (login) in HES is his email, although it can be something else in other systems (e.g. a combination of the user's first and last name).

If your ASA and AD configuration accepts email as a user ID, you need to set:

Name Identifier Format - Email Name Identifier Field - Email

If the ASA and AD configuration do not accept email as a user ID, you need to set the format that you use in the 'Name Identifier Format' field, and the value 'External ID' in the 'Name Identifier' field. Then you need to fill in the 'External ID' field for each employee. To do this, click Employees -> 'Select an employee -> Details -> Edit settings (in the Single Sign On section) -> Edit the External ID.

After filling in and saving all the settings, you can check the integration by logging into the service provider. You should be redirected to the HES authentication page where you will need to enter your username (email) and pass the security key verification.

Final Verification

Step 1. Enable SSO for a user in the HES

Employees cannot log into the HES service and use the SSO service by default, they must have an explicit permission of the administrator. Select an employee and click the [Edit] button. Then click the [Enable SSO] button at the opened page to give the permission.

Note: An employee must have an email and an associated key to activate the SSO service.

The SSO service is automatically enabled and cannot be deactivated for all HES administrators.

If External ID is used as the Name Identifier Field, you have to fill in this field as well. Open 'Employees' -> 'Select an employee' -> 'Edit' to edit the External ID field.

Some service providers may not support this functionality.

Step 2. Logon to a web service using SAML

Connect to your VPN URL and choose one of your sign-in options in the Hideez Enterprise Server window, then use your credentials to Sign In:

AnyConnect is Connected:

Common Issues

1. ENTITY ID MISMATCH

Debug Example: [SAML] consume_assertion: The identifier of a provider is unknown to #LassoServer. In order to register a provider in a #LassoServer object, you must use the methods lasso_server_add_provider() or lasso_server_add_provider_from_buffer().

Problem: Generally means that saml idp [entityID] command under the ASA's webvpn configuration does not match the IdP Entity ID found in the IdP’s metadata.

Solution: Check the entity ID of the IdP’s metadata file and change the saml idp [entity id] command to match this.

2. TIME MISMATCH

Debug Example: [SAML] NotBefore:2017-09-05T23:59:01.896Z NotOnOrAfter:2017-09-06T00:59:01.896Z timeout: 0

[SAML] consume_assertion: assertion is expired or not valid

Problem 1. ASA time is not synced with IdP’s time.

Solution 1. Configure ASA with the same NTP server used by IdP.

Problem 2. The assertion is not valid between the specified time.

Solution 2. Modify the timeout value configured on the ASA.

3. WRONG IDP SINGING CERTIFICATE USED

Debug Example: [Lasso] func=xmlSecOpenSSLEvpSignatureVerify:file=signatures.c:line=493:obj=rsa-sha1:subj=EVP_VerifyFinal:error=18:data do not match:signature do not match

[SAML] consume_assertion: The profile cannot verify a signature on the message

Problem: ASA not able to verify the message signed by the IdP or there is no signature for the ASA to verify.

Solution: Check the IdP signing certificate installed on the ASA to make sure it matches what is sent by the IdP. If this is confirmed, make sure that the signature is included in the SAML response.

4. INVAILD ASSERTION AUDIENCE

Debug Example: [SAML] consume_assertion: assertion audience is invalid

Problem: IdP is defining the incorrect audience.

Solution: Correct the Audience configuration on the IdP. It should match the ASA’s Entity ID.

5. WRONG URL FOR ASSERTION CONSUMER SERVICE

Debug Example: Unable to receive any debugs after the initial authentication request is sent. The user is able to enter credentials at IdP but IdP does not redirect to ASA.

Problem: IdP is configured for the wrong Assertion Consumer Service URL.

Solution(s): Check base URL in configuration and make sure it is correct. Check ASA metadata with show to make sure that the Assertion Consumer Service URL is correct. In order to test it, browse it, if both are correct on the ASA, check the IdP to make sure that the URL is correct.

5. SAML CONFIGURATION CHANGES NOT TAKING EFFECT

Example: After a single sign-on URL is modified or changed, the SP certificate, SAML still does not work and sends previous configurations.

Problem: ASA needs to regenerate it's metadata when there is a configuration change that affects it. It does not do this automatically.

Solution: After making changes, under the affected tunnel-group remove and re-apply the saml idp [entity-id] command.

Troubleshooting

Most SAML troubleshoots involve a misconfiguration that can be found when the SAML configuration is checked or debugs are run. debug webvpn saml 255 can be used to troubleshoot most issues, however in scenarios where this debug does not provide useful information, additional debugs can be run:

Need some help? Try searching our Knowledge Base articles or contact Support for further assistance.