Home » What is SAML and how it works?
Applicable For Endpoint Central MSP 
 
 
On-PremisesCloud

What is SAML Authentication?

Security Assertion Markup Language (SAML) is the de facto open standard used for exchanging authentication and authorization details between the Service Provider and the Identity Provider. The exchange of details is done through digitally signed XML documents containing user data. Central Server on-premises offers support for SAML 2.0 authentication. By enabling this feature, users can login to Central Server on their desktops and mobiles (Central Server Mobile App) via a Single Sign-On (SSO) service, which supports SAML authentication.

Table of contents

  1. Glossary
  2. How SAML authentication works?
  3. Prerequisites

Glossary:

Service Provider - The application providing a specific service which authenticates and authorizes users by security assertions requested by SSO. For example: CRM, Endpoint Server, etc..

Identity Provider - The entity which maintains and manages the user's credentials. For example: Okta, OneLogin, etc..

Single Sign-On service - A service provided by Identity Provider, that has a centralized login system in which the user enters the credentials once, after which, the authentication and authorization details are passed to different service providers to grant access to the user.

The main advantage of SSO is that it has centralized authentication, thereby eliminating the need for users to remember multiple passwords to access different applications.

How SAML authentication works?

When a user tries to login to access the Service Provider, the user will be redirected to SSO login page. Upon entering the credentials, the SSO will pass the information to the Service Provider. Further, the Service Provider will decide based on the authentication and authorization details provided by the SSO, whether or not to grant access to the user.

Prerequisites:

  • Since, the IdP redirection happens via HTTPS port, the HTTPS port must be kept open. The ACS URL is generated using HTTPS only.
  • Identity Provider should support HTTP POST binding.
  • Certificates from the Identity Provider should not have been tampered with, encrypted or expired and should be encoded in base 64 format.

Click below for configuring SAML authentication settings between Central Server

Data provided by Central Server that has to be entered in IdP

After logging in, go to the Admin tab, and select SAML Authentication. Here, you can find the details that are provided by Central Server to be entered in IdP's side. service provider details

  • Entity ID
    An Entity ID is a Globally-Unique Identifier used to represent your Central Server instance.
  • Assertion Consumer Service URL (ACS URL)
    The ACS URL or Reply URL is an endpoint pointing to your Central Server instance that tells the IdP where to send the SAML response. The ACS URL must be used in IdP configuration.

    Note: Steps to change the default ACS URL:
    1. Open <Installation_directory>/UEMS_CentralServer/conf/websettings.conf
    2. In a new line, type saml.fqdn.name=FQDN_Name
    3. Save the websettings.conf file
    For example: saml.fqdn.name=dc.com
    4. Restart the Central Server server
    5. Reconfigure SAML Authentication

    where FQDN_Name is the new FQDN, without the port.
    Both Entity ID and the Assertion Consumer URL will be present in the Metadata XML.

Data required for Central Server from IdP

After logging into the product console, go to the Admin tab, and select SAML Authentication. At the bottom, you have to enter the IdP's details. Identiy provider details

  • Name ID
    The Name ID is used to uniquely identify the user who is trying to sign in- it can be either the username or the email ID.
    Note: For domain users, the Username should be in this format: domain\username. This may not be supported in some IdPs.
  • Login URL
    The Login URL is an endpoint pointing to your IdP that tells Central Server where to send the SAML request.
  • Certificate
    A certificate from the IdP, used by Central Server to verify future SAML requests from the IdP.

Note: The Federation Metadata XML file from IdP, that contains the information mentioned above, can be uploaded to Central Server.

SAML-Points-to-be-noted
  • To successfully log in using SAML, the user must be present both in the IdP and Central Server.
  • SAML authentication may not work in browsers that are not supported by the Identity Provider.
  • SAML Single logout is not supported currently.
  • If FQDN changes, the ACS URL changes. This implies that the ACS URL should be again updated manually in the Identity Provider.
  • FQDN and port mentioned in the ACS URL must be used to configure the Central Server mobile app for SAML Authentication.
  • In SAML Authentication settings of Central Server, the Name ID  can be either chosen as Username or Email ID. The same option should be selected in the Identity Provider for authenticating users.
  • All accounts should have a unique email ID associated with Central Server.
  • The metadata file while configuring Identity Provider, must have these three parameters- SSO URL, SSO Signing Certificate; SSO Binding Protocol
  • If the user tries to access Secure Gateway Server on the mobile app, the security protocols of Secure Gateway Server restrict the user to login via SAML authentication. As a workaround, access the internal server's FQDN/IP address to login via SAML on the mobile app.

Note: All the SAML configuration and authentication steps discussed for Central Server also applies to Patch Manager Plus and Vulnerability Manager Plus.

Was this article helpful?

Thank you for your feedback!

Sorry about that!

By clicking "Submit", you agree to processing of personal data according to thePrivacy Policy.
Back to Top