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
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/<domain> (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. This scope 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.
To help set up SAML for your organization please contact your OverOps Success Manager or our Customer Support.
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.
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.
In order to provide implementation flexibility for setting up the SAML attribute names (as some attribute names might already have other uses) OverOps supports several alternative attribute names, you can select and use any one of these to pass the authorization level as part of the SAML request:
Example for an Attribute statement:
The attribute 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 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>
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:
*If you are using SaaS and not On-Premises installation - please contact our support to assist with setting this up for your domain.
If you don’t use one of the ‘groups’ attribute as mentioned above - the default level of access will be set to 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 with the value ‘null’ (or any value that is not part of your environment names) and we will prevent the user from accessing OverOps for any of the environments in your domain.
To prevent a user from accessing some of the environments - you should specify all the environments and roles for the environment to which the user should have access and simply not include the environments the user should not have access. 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: “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 user 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.
Updated about 4 hours ago