You can use the Authentication workspace to configure SSO in SaltStack Config to work with an authentication system compatible with the SAML protocol.

Note: You can use more than one system at a time to authenticate users in SaltStack Config if needed. For example, you could use both a SAML-based IdP or LDAP-based IdP while simultaneously storing some user credentials natively on the RaaS server. However, SaltStack Config does not allow configuring more two SAML providers or two LDAP providers at the same time.


SAML Single Sign-On (SSO) is functionality that many organizations configure during the implementation of SaltStack Config. SSO provides many benefits, including:

  • Reducing the time users spend signing into services for the same identity. After users sign in to one of the services at an institution, they are then automatically authenticated into any other service that uses SSO.
  • Reducing password fatigue. The user is only required to remember one set of credentials rather than several.

Many services provide implementations of the SAML SSO protocol including ADFS, OneLogin, Okta, Shibboleth, SimpleSAMLPHP, Google Suite, and more.

How SAML SSO works with SaltStack Config

When SaltStack Config receives a successful identity assertion from any of its supported authentication integrations, it searches for a user login that matches the value of the asserted identity. If it finds a matching login, it logs in the associated user account.

For example, if SaltStack Config receives an ADFS assertion for a user and the value for the configured identity attribute is “fred,” SSE will search for a login with a username of “fred.” If one is found, the associated user is logged in. Otherwise, the login is unsuccessful.

SAML authentication terminology

Acronym Definition

Security Assertion Markup Language (SAML, pronounced SAM-el)

SAML is an open protocol (also sometimes referred to as a standard) for exchanging authentication and authorization data between parties. In particular, it is used to exchange data between an identity provider and a service provider.

SAML is browser-based single sign-on (SSO). All communications happen through the user agent (the browser). There is no communication between a service provider (such as SaltStack Config) and an identity provider (such as Azure AD). This separation allows authentication to occur across security domains where a service provider can be in one (possibly public) domain and the identity provider in a separate, secured network segment.


Identity provider

The job of the IdP is to identify users based on credentials. An identity provider is software that provides a service that complies with the identity provider part of the SAML Specification. The IdP typically provides the login screen interface and presents information about the authenticated user to service providers after successful authentication.

Sample identity providers:

  • ADFS
  • Azure AD
  • Google SAML
  • Shibboleth
  • Okta
  • OneLogin
  • PingFederated
  • SimpleSAMLPHP

Service provider or relying party

An SP (service provider) is usually a website providing information, tools, reports, etc. to the end user. A service provider is software that provides a service that complies with the service provider part of the SAML Specification SaltStack Config. Microsoft products (such as Azure AD and ADFS) call the SP a relying party.

In this scenario, SaltStack Config is the service provider. SaltStack Config accepts authentication assertions from the IdP and allows users to login.

An SP cannot authenticate with an IdP unless it is listed in the list of approved services. Configuring an SP with a list of approved IdPs is part of the configuration process.


Single sign-on

Single sign-on is an authentication system in which a user isn’t required to log in to a second service because information about the authenticated user is passed to the service.


Single logout

When a user logs out of a service, some IdPs can subsequently log the user out of all other services the user has authenticated to.

SaltStack Config does not currently support SLO.


Role-based access control

Role-based access control, also known as role-based security, is an advanced access control measure that restricts network access based on a person’s role within an organization. The roles in RBAC refer to the levels of access that employees have to the network.

Employees are only allowed to access the network resources or perform tasks that are necessary to effectively perform their job duties. For example, lower-level employees usually do not have access to sensitive data or network resources if they do not need it to fulfill their responsibilities.

SaltStack Config can support RBAC with SAML configurations using the Roles workspace. However, the user will first need to login to SaltStack Config in order to be added as a user in the local user database and managed by the Roles workspace. For more information, see Configuring RBAC for SAML.