Feature Spotlight: SAML SSO

Increase Security & Reduce Password Reset Requests
Bryan Harding

As an end user, accessing multiple services using a single set of credentials has been a game changer. Single sign on, or SSO, capabilities promote productivity, and reduce the risk of a user suffering from “credential amnesia.”  These benefits are passed directly onto Help Desk teams through a significant reduction in password reset requests.

What is SAML?

SAML, or Security Assertion Markup Language, is an XML-based standard for exchanging authentication, authorization, and attribution data between an identity provider (IdP) and a service provider (SP). Using SAML, a typical user performs an access request from the service provider, which then requests an identity assertion from the identity provider. Depending on the assertion, the service provider may make a determination on whether some service should be provided for the user.blog-b0115-bharding-SAML

SSO – Why would I want to use it?

With SSO, organizations can limit credential validation to a central SSO server, rather than individual services. As a result, security is increased. Additionally, because SSO can be used across multiple services, the number of credentials users must memorize is reduced. Gartner estimates up to 50% of all Help Desk calls are password reset requests.

Thought, the most significant benefit is the overall reduction of IT resources for user management. User management is provided through a single central SSO server, less tickets concerning credential resets will filter through Help Desk services.

ScienceLogic & SAML

ScienceLogic introduced a productized SAML 2.0 SSO integration in version 7.8.0, a feature that had been requested by MSPs and enterprises alike. This feature introduces a new level of control for our customers. Read more about centralizing identity management for MSPs here.

Essentially, now it’s possible to utilize your corporate SAML provider to authenticate in the ScienceLogic platform, just as you could with Active Directory or LDAP prior. In both cases you can choose to manually identify the domain users that should be authorized within the platform or you can simply let the platform create the user upon first login.

Have something to add to this post? Share it in the comment section below.

Request a demo
Get the white paper!

Share This Post

Most Popular

Archive

Comments