Configure OverOps to validate users and grant role access via SAML to environments with same owner


How do we configure OverOps to allow users to login with their SAML account (authenticate) and allow access to our application (authorize) for all environments with the same owner?


Validate that the following listed properties are configured in the configuration file and the values are set accordingly.

Note: All settings must be configured in the file located under /<INSTALL_PATH>/takipi-server/conf/tomcat/shared/ directory.

  • Enables the backend to utilize SAML SSO to authenticate users via IdP.


  • Location of the metadata that is provided by the IdP. The full path to the metadata file must be provided.


  • Sets the backend server to use a domain initializer. The domain initializer will be the owner for all available environments, which should all be the same email address to ensure all available environments will be eligible to be provided access if the user’s SAML response matches to the environment name and role accordingly.
  • Sets the appropriate values mapped from the users’ information within the IdP’s application to be displayed properly within OverOps. If not used, field names will be populated with the alias portion of the email address.



  • Adding this parameter assigns a different separator (such as a colon [:]) to be used. If this property is not used within the properties file, a blank space will be used as the default separator between the environment and role that is passed within the SAML response.


  • Assigns the attribute name that will be passed from the IdP into the OverOps application. The attribute value provided in the attribute name will need to contain the environment name and role the user is assigned to based on the groups the user has added to within their IdP. The role can be set either as Admin , Member , or Viewer . The overops-groups field name is the default SAML attribute name when this parameter is not used. Other field names that can be used are as follows: group, role, overops-group, groups, overops-groups, overops-role, roles, overops-roles, groups-membership

Results of the SAML Response should look like one of the following:

Environments passed as one value:

<saml2:Attribute Name=“overops-groups” NameFormat=“urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified”> <saml2:AttributeValue xmlns:xs="…" xmlns:xsi="…" xsi:type=“xs:string”>Environment1 Member, , Environment2 Admin</saml2:AttributeValue>


Environments passed as individual values:

<saml2:Attribute Name=“overops-groups” NameFormat=“urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified”>
<saml2:AttributeValue xmlns:xs="…" xmlns:xsi="…" xsi:type=“xs:string”>Environment1 Member</saml2:AttributeValue>
<saml2:AttributeValue xmlns:xs="…" xmlns:xsi="…" xsi:type=“xs:string”>Environment2 Admin</saml2:AttributeValue>


The settings above ensures that users login with their SAML credentials through their IdP and will be provided access to the designated environment and roles for each environment provided that the domain initializer is the owner of each said environment. If there are any environments that may be in the SAML response in which the domain initializer is not the owner of, the user will not gain access to those environments. The attribute values MUST match to existing environments and roles, otherwise, users logging in will NOT gain access to ANY environments.

For explanation on each of the parameters being used, please refer to the following docs:
On Premises Configuration of SAML
4.53 SAML Security Updates