Nirmata is built for enterprise DevOps teams. Secure role-based access control is a requirement for enterprise software. In this post, I will describe how Nirmata enables Single Sign On (SSO) using the Security Assertions Markup Language (SAML) 2.0 protocol.
Introduction
In a typical Nirmata deployment each product team has an account, and each account has a few administrative users, a few platform users, and several developers. In Nirmata administrators can manage users and billing details, platform users can manage cloud providers and infrastructure policies, and developers can manage applications and runtime environments.
As teams and projects change, user roles and access also need to be updated. Enterprise security teams and administrators need to ensure proper onboarding, and offboarding, for users. Enterprise security certifications and best practices require a single place where all services and access rights can be managed for employees. It’s a major concern, and operations pain, to use 3rd party software that requires its own identity management and authentication, and does not integrate with existing enterprise user and identity management tools.
SAML 2.0 is a protocol that allows software systems to securely exchange user authentication and authorization data. SAML is an industry standard from OASIS (Organization for the Advancement of Structured Information Standards) and uses XML to exchange security data.
The diagram below shows the messages exchanges for SSO. When using SAML, Nirmata plays the Service Provider (SP) role. The User Agent is the Web Browser or other client that the user is using to access Nirmata. And the Identity Provider is the customer’s user authentication system, like Active Directory Federation Services (ADFS).
A similar, but different message exchange, is used for logging out the user session.
Enabling Single Sign On in Nirmata
While SAML is a complex protocol, Nirmata makes it extremely easy to setup and manage SAML. Here are the steps:
1) In your Account view (Settings -> Account) select the option “Enable Single Sign-On with SAML”:
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.
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.
That’s it! You now have SAML fully configured!
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.
Summary
As enterprise product teams are adopting DevOps and multiple cloud providers, they are increasingly choosing Software-as-a-Service (SaaS) tooling for ease of use and easy management of their application delivery pipelines.
While SaaS products offer several benefits, it’s a pain, as well as a security challenge, to manage user identities in each SaaS product. Products designed for enterprise teams must provide SAML 2.0 based single sign on, so that user identities can be safely and easily managed.
In this post we saw how Nirmata implements SAML 2.0 and makes it easy for enterprise DevOps tools to easily manage and scale their applications across any cloud.
You can give Nirmata a try, by signing up for our free trial. We love hearing from our users, so do reach out with questions and feedback!
Sorry, the comment form is closed at this time.