Introduction

OverOps supports the use of Security Assertion Markup Language (SAML), which is a standard used for logging users into applications. SAML is a single sign-on (SSO) login standard, which has many advantages over username/password login, including:

• You don't need to enter your credentials
• You don't need to remember and renew passwords
• There's no possibility of entering a weak password

OverOps Domain and Domain Initializer

The Domain you choose will be the entry point to all the OverOps Environments (service keys) under the Domain Initializer. For example: https://app.overops.com/saml/ (the domain will usually be the company or company and business unit name, in lowercase letters)

The Domain Initializer is the person who is the owner of the OverOps environments for the Domain and the users in this domain will get access to all the services that this user owns and also connected to. A user cannot get access to an environment which the Domain Initializer isn't its owner or if this environment has been removed. The scope of the domain is determined at the time of login.
By default a user accessing a service under this domain after enabling SAML authentication will receive a Member role to each of the environments, unless using SAML Groups attribute (described as follows) and specifically setting the permissions for the user.

🚧

A planned update for the 2020 November release will change the default access role to No_Access.

To set the default access role for On-Premises installation add the following property to your my.server.properties configuration file:
SAML_BASIC_SSO_MODE_DEFAULT_ROLE=<Set one of the following options: No_Access / Viewer / Member>
To change the default role for SaaS - contact our Support team.

To help set up SAML for your organization please contact your OverOps Success Manager or our Customer Support.

❗️

Existing Users

If a user previously had an existing user in OverOps, this user’s role will be maintained until the next authentication or until the user’s session ends.
If the new authorization levels described below are not setup the user will automatically revert to a Member role even if previously the user was setup as admin or viewer role.

Managing Users Authorization using SAML in OverOps

After enabling SAML authentication, the authorization level is controlled via a SAML attribute that you can provide to pass the desired environments and roles information for every user as part of the SAML request.

The default SAML Groups attribute name is overops-groups.
In order to provide implementation flexibility for setting up the SAML attribute name, OverOps supports setting an alternative attribute name instead of the default one.

🚧

To set a different name for the SAML Groups attribute in an On-Premesis deployment, add the following property in your my.server.properties:
LDAP_SAML_GROUPS_FIELD_NAMES=
To change the default attribute name for SaaS - contact our Support team.

Example for an Attribute statement:
The attribute's value should be a comma-separated list of pairs of service names and assigned roles, such as "service-name-1 member, service2 admin" (spaces in the original service name should be replaced by "-"). The Value part of the attribute can also be divided between multiple Value tags.

The available User Roles which can be used are: admin, member and viewer (See more on these roles in here).

<saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
        <saml2:Attribute Name="overops-groups" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
           <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:type="xs:string">Production-Environment member, QA-Environment admin</saml2:AttributeValue>
        </saml2:Attribute>
</saml2:AttributeStatement>

📘

Note that as of 4.53 release OverOps applies strict parsing on the SAML assertion group attribute expression: any user with missing, incorrect or non existing assignment of an Environment name or a Role (or when using an empty expression) will be denied access to the system.
We provide a backwards compatibility mode, for an interim period, to support cases where the older (and less-secure) parsing is required. For more details on this option see here, or contact our Support team.

📘

Configuring an alternative separator

In case your chosen IDP does not support 'space' character as a valid separator for the SAML Attribute (the separator between environment and role in groups definition is space by default) - it is possible to configure an alternative separator character (or a string to be used as separator) by adding the following property to my.server.properties and assigning it your chosen separator character/string:

AUTH_DOMAIN_ENV_ROLE_SEPARATOR

*If you are using SaaS and not On-Premises installation - please contact our support to assist with setting this up for your domain.

Scenarios

Restricting User Access to Specific Services

If you don’t use one of the ‘groups’ attribute as mentioned above - the default level of access, for authenticated users, will be set to the default role as set on SAML_BASIC_SSO_MODE_DEFAULT_ROLE for on-premises, or for SaaS as the value set as default role for the domain (Current default level is Member role for all of the available environments).

To prevent a user from accessing all environments, you would, ideally, remove the user from the OverOps application user directory in your IDP of choice. However, even if the user exists in your IDP directory and the OverOps application, you can use the ‘groups’ attribute to restrict the user's access to specific environments only. OverOps will apply the permissions set within this attribute and will deny any other privileges for this user. In case any part within the attribute expression are invalid the user will be denied access to all environments. Therefor, the 'groups' attribute should only contain Environment & Role pairs that exist for your domain, and should not be empty.

For example, if I’d like to restrict the user for environment PROD but allow the user to access environment QA (with a member role) - use the following value for the 'groups' attribute: “QA member”.

Example of possible use cases:

In our scenario, John is the Domain Initializer for his company ACME and is the owner of the following environments in OverOps: Prod Billing, Prod Ecom, Stage.

The users in ACME are defined in the ACME IDP as part of two main groups: Dev-Ops and Dev-Leads. The Dev-Ops group users should have access only to Prod Ecom and Stage, in both cases the access level should be as a Viewer.

In this scenario, John, or the person managing the authorization list in ACME’s IDP, will pass the following definition in the overops SAML groups attribute, for all members of the Dev-Ops group: “Prod-Ecom viewer, Stage viewer”.

In this example, Jack who is associated to the Dev-Ops group on the ACME IDP, will be granted viewer access to Prod Ecom and Stage OverOps environments, and will not see or be able to access the Prod Billing environment.