Settings

Users and Roles

An account can have multiple users, and each user has a role that defines what they can see and do. When a new account is created, the first user has an admin role which allows that user to create and manage additional users for the account.

The following user roles are available:

Role Description
admin admin users have full access to the account and can also manage other users and their access.
platform platform users can all other resorces including Cloud Providers, Host Groups, Policies, Applications, and Environments, but cannot manage users.
devops devops users can manage Applications and Environments. They do not have access to Cloud Providers, Host Groups, and Policies, and cannot manage users.
readonly readonly users can view all data, but create, edit, or delete anything. This role is ideal for system accounts that collect and report data.

Single Sign-On (SSO) with SAML

For Enterprise accounts, Nirmata supports Single Sign-On (SSO) with SAML 2.0. This feature allows enterprise administrators to manage their users in a secure and easy manner. For example, when an employee is on-boarded to, or leaves, the enterprise the administrators can enable, or disable, their account in a single place for all enterprise services. This feature also makes life easier for enterprise users as they can authenticate once, and access all enabled services without managing separate passwords and accounts.

SAML (Security Assertions Markup Language) is a protocol that defines how systems can exchange security data. The following references are useful in understanding SAML:

The SAML protocol is defined at: Security Assertion Markup Language (SAML) V2.0 Technical Overview - OASIS.

Although SAML is a complex protocol, Nirmata makes it extremely easy to setup and manage. Here are the detailed steps:

  1. In your Account view (Settings -> Account) select the option “Enable Single Sign-On with SAML”:
_images/SAML-1.png

2. This option provides a dialog where you can upload the SAML metadata file of your Identity Provider (IdP) e.g. ADFS 3.0. Or, you can manually configure your IdP settings.

SAML IdP Metadata import:

_images/SAML-2.png

SAML IdP manual configuration:

_images/SAML-3.png

3. Next, export your accounts’ Nirmata SAML Service Provider (SP) metadata and import that into your IdP. To export the SP Metadata go to Settings - SAML 2.0 and click on the View SP Metadata option. You can then copy the metadata or download it to a file.

_images/SAML-4.png

To complete the setup, you can now import the SAML SP Metadata into your IdP. If you are using Microsoft AD FS (Active Directory Federation Services) follow the steps at Setup AD FS for use with Nirmata to configure ADFS for SSO with Nirmata.

Thats it! You now have SAML fully configured!

Note: By default, self-signed certificates are used to sign and encrypt the data. In order to use CA signed certificates, see Using CA signed SAML signature certificates.

Using CA signed SAML signature certificates

In order to use CA signed SAML signature certificates you can add the certificates in the Service Provider Settings section.

_images/settings-sp-data.png

Next, export your accounts’ Nirmata SAML Service Provider (SP) metadata and import that into your IdP. To export the SP Metadata go to Settings - SAML 2.0 and click on the View SP Metadata option. You can then copy the metadata or download it to a file.

To complete the setup, you can now import the SAML SP Metadata into your IdP.

Enable SAML SSO for a User

Nirmata allows you to control which accounts use SAML. This provides a lot of flexibility and control, especially for service accounts and other temporary users. You can select the IdP for a user when you add the user, or can edit the settings at anytime.

_images/SAML-5.png

Setup AD FS for use with Nirmata

This section provides instructions on how to setup Microsoft AD FS (Active Directory Federation Services) as a SAML Identity Provider (IdP). Before you setup ADFS, you must first enable SAML SSO in Nirmata, import the IdP Metadata into Nirmata, and export the SP Metadata. You must also Copy or transfer the SP Metadata XML file to your AD FS server.

Setting up ADFS involves three steps (the following steps use Windows Server 2012 R2 and ADFS 3.0):

  1. Import the SP Metadata into ADFS

On your ADFS host open the Server Manager tool and select the AD FS Management option:

_images/adfs-1.png

In the AD FS Management window, navigate to Trust Relationships -> Relying Part Trusts and select Add Relying Party Trust from the right Actions panel:

_images/adfs-2.png

Select the SP Metadata XML file that you exported from Nirmata:

_images/adfs-3.png

Provide a Display Name:

_images/adfs-4.png

If your organization used Multi-factor Authentication (MFA), you can enable it. Otherwise, leave it disabled:

_images/adfs-5.png

On the next screen, select Permit all users to access this relying party:

_images/adfs-6.png

Since we imported the SP settings from the Metadata file, simply click next on the Ready to Add Trust screen:

_images/adfs-7.png

Make sure that the Open the Edit Claim Rules dialog… option is checked and close the wizard:

_images/adfs-8.png

Proceed to configure a SAML claim below.

  1. Setup a SAML Claim Rule for Nirmata

Nirmata requires that the SAML Name ID field contain the email address of the principal. You can enable this by configuring a SAML Claim Rule in ADFS.

Click on Add Rule.. to configure the claim:

_images/adfs-9.png

Select Send LDAP Attributes as Claims and click next:

_images/adfs-10.png

Enter a name for the claim rule, such as “email address”. Then select Active Directory as the Atribute Store. In the mapping section, select E-Mail-Addresses as the LDAP Attribute and Name ID as the Outgoing Claim Type.

_images/adfs-11.png

Click Finish to add the claim and then OK to exit the Edit Claim Rules dialog.

  1. Allow SAML signature certificates to be self-signed

In a SAML message exchange, X.509 Certificates with public and private key pairs are used to sign and encrypt the data. Since the keys are exchanged via Metadata and the SAML messages are exchanged over a secure (TLS) connection, there is no benefit in using CA signed certificates for signing.

Nirmata generates self-signed certificates for SAML signatures and encryption. You must setup AD FS to not require CA certificates for SAML signing and encryption. You can manage these settings using PowerShell as described below.

Check you current settings using the PowerShell command:

Get-AdfsRelyingPartyTrust | Select-Object Identifier, SigningCertificateRevocationCheck, EncryptionCertificateRevocationCheck

Look for the Identifier https://www.nirmata.io/security/api.

_images/adfs-12.png

Use this PowerShell command to disable CA certificate checks for Nirmata:

Get-AdfsRelyingPartyTrust -Identifier  https://www.nirmata.io/security/api/ | Set-AdfsRelyingPartyTrust -SigningCertificateRevocationCheck None -EncryptionCertificateRevocationCheck None
_images/adfs-13.png

You should now be able to navigate to your AD FS login page and select Nirmata (Nirmata Cloud Services). This will initiate the SAML SSO exchange and authenticate your users with AD FS.

_images/adfs-14.png

Alternatively, you can also sign in using your email address at: https://nirmata.io/.