Isn’t it magic when all your DevOps team, including new members, can access the company’s repository fast and securely by simply logging in once? It isn’t a dream! You can easily arrange it using SAML single sign-on (SSO).
What You Should Know About SAML
Before jumping into the technical details of SAML, let’s try to understand what SAML is in a simple language. For that reason, let’s look at an example.
Imagine you are managing the activity of a big DevOps team – all of them use a bunch of apps to make their work easier. It can include GitHub, Jira, AWS, and many more. All those apps your organization uses on a daily basis. Then it comes the moment to expand your DevOps team. After a thorough search, your headhunter’s work is done – your company hires a new developer and gives him a work email address and access to a dashboard. As soon as he signs in to the dashboard, he gains access to all the apps there. All he needs to do is to click the app he wants to use without entering any other credentials. Not bad, eh? And it is how Security Assertion Markup Language (SAML) actually works.
Using a more technical language, SAML is an open standard used to authenticate the user. Web applications use this standard, which is based on the XML format, to transfer authentication data between two parties. They are:
- The identity provider (IdP), which performs authentication and passes the user’s identity information and the level of authorization to the service provider
- The service provider (SP), which authorizes the use and permits him to access the requested resources.
Benefits of SAML Authentication
SAML brings a lot of benefits to the company. Among them, we can name improved user experience, increased level of security, and reduced costs for different service providers, and it permits skipping multiple questionnaires as all the information is synchronized between directories.
|
Specific Benefit of SAML
|
What it brings to the team
|
|---|---|
| Boosts User Experience | Your team members need to sign in just 1 time to access multiple apps. It makes the authentication process much faster and reduces your team’s stress, as your DevOps don’t need to remember the bulk of login credentials for each application they use. |
| Improves Security | SAML brings forth a single point of authentication – a secure identity provider. So, the credentials are only sent to the IdP directly. You eliminate the risk of using weak and repeatable passwords by employees. |
| Reduces Responsibility | You don’t need to maintain all your account details across multiple services. With SAML turned on, the identity provider takes this responsibility. |
| Empowers Single Identity | As a user, you don’t need to maintain and synchronize your information between directories. SAML makes a user’s life easier. |
GitHub and SAML SSO: All You Need To Know
If your company uses GitHub Enterprise Cloud, then SAML SSO will be a great benefit for you. It permits organization owners to control and secure the access to company’s GitHub data, including repositories, pull requests, and issues.
How Does SAML SSO Work on GitHub?
Once you decide to configure SAML SSO, members of your organization still need to log in to their personal accounts on the GitHub platform. Though, in this case, the process will look this way:
- As soon as a member of your DevOps team tries to access some resources within your organization, GitHub will redirect those members to your company’s IdP for authentication reasons.
- Once the authentication is successful, your IdP will redirect the member of your DevOps team back to the git hosting service.
However, it’s worth remembering that SAML SSO “doesn’t replace the normal sign-in process for GitHub,” as mentioned in GitHub Docs:
You don’t need IdP authentication if you want to view the public repository overview page and its file contents on GitHub, fork, or clone the repo. However, if you plan to view issues, projects, pull requests, and releases, then authentication is a must-have.
What Enforcement of SAML SSO for Your GitHub Brings to Your DevOps Team
If you enforce SAML SSO for your GitHub organization, all members of your DevOps team will have to authenticate through your IdP to access your GitHub repositories and metadata to start building their code. It will definitely help to eliminate unauthorized access.
When the enforcement is turned on, it will remove any member (or administrator) who failed to authenticate with IdP from the organization.
At the same time, you, as a removed user, will get an email notification from GitHub. Is it possible to rejoin the GitHub organization? Sure… All you need to do is authenticate with SAML SSO once again within 3 months after being removed. Within this time frame, all the access privileges and settings are preserved.
When it comes to bots and service accounts, to retain access to them, the administrator of an organization can enable SAML SSO. If you need to enforce SAML SSO for your GitHub organization, you need to create an external identity for the bot or service account you want with your IdP. Otherwise, those bots and services will be removed from your organization.
You can test your SAML SSO implementation during the setup phase. All you need to do is to leave Require SAML SSO authentication for all members of the [name of the organization] unchecked. In this case, the process of testing won’t affect your organization’s members.
Are There Any Risks?
What will you do if an attacker cracks your password and encrypts all your data? Yep, it’s possible to lose all your data and resources as all your web apps and accounts are linked with the same credentials. Or you can face a problem if there is any failure or breakdown in the SSO. In this case, all your applications will come to rest to log in. For example, in March 2022 due to a hacker attack on Okta, an identity and access management company, around 360 of its customers were potentially impacted and the incident lasted for “25 consecutive minutes.”
Is it possible to avoid situations like those mentioned? Unfortunately, no. Yet you can try to eliminate the risks connected with those situations – downtime, data, and financial losses.
Back up your GitHub repositories and metadata. In this case, even if your GitHub environment is encrypted (with ransomware, for example), you will be able to run your backup copy from another storage instance.
GitHub Backup: What To Keep In Mind
Let’s look at what your GitHub backup should include. If you build your backup strategy in advance and in an appropriate way, you can save time and money in the event of a threat. So, what features can bring your company reliability and any-time data access? They are:
- Meeting the 3-2-1 backup rule (when you have at least 3 copies in 2 different storage instances, one of which is out of your infrastructure)
- Possibility for infinite retention (to recover your data from any point in time)
- Encryption (AES, in-flight and at rest with your own encryption key)
- Ransomware protection (including immutable storage)
- Restore and disaster recovery technology (permitting to perform granular recovery, restore to the same or new repo/organization account/local device, or cross-over recovery to another Git hosting platform – from GitHub to Bitbucket or GitLab)
Takeaway
SAML Single sign-on (SSO) is a very useful function that brings your team convenience and permits you to avoid remembering multiple passwords and logging in just once into all your web apps.
Despite being a reliable and secure way of accessing your apps, it still needs an additional layer of protection – backup, which can help to eliminate downtime and data loss. You can try to arrange your backup by yourself or use third-party backup tools.