SAML, which stands for Security Assertion Markup Language, is an open standard for exchanging authentication and authorization data between an identity provider and a service provider.
SAML utilizes Extensible Markup Language (XML) for communications between the identity provider and service providers — linking authentication of a user’s identity and the authorization to use a service.
Why is SAML used?
Using SAML for identity federation to achieve single sign-on (SSO) is very common. Single sign-on is relatively simple to accomplish within a security domain (using cookies), but spreading SSO across security domains is more complicated and requires identity federation. Identity federation is a system of trust between two parties to authenticate users and convey the information needed to authorize their access to resources. The SAML Web Browser SSO profile was defined and standardized to support interoperability between various parties.
Using SSO can help company’s employees log in to various applications using only one username and password. It provides central control over identity management features like multi-factor authentication, password policies, and a single system to assign or unassign application login rights to users. It creates a more user-friendly way to access applications that employees need to get their job done.
How does SAML work?
SAML passes information about users, logins, and attributes between the identity provider and service providers. When a user logs in once to SSO with the identity provider — the identity provider then passes SAML credentials to the service provider when the user tries to access those sites. Because both systems speak the same language, SAML, the user only needs to sign in once.
SAML can be compared to several authentication and access methods. In some ways, it is a lot like traveling by plane:
Flying as a Service:
1. Fred goes to check in for his flight with the ticketing agent, where his ID is checked, and a confirmation is provided.
- The ticketing agent is the identity provider; their objective is to verify Fred’s identity and make sure he is authorized to pick up the ticket and fly.
2. It’s now time for Fred to board the plane. The gate agent scans Fred’s confirmation and lets him go through to board the plane.
- The gate agent is the service provider; they provide Fred with what he needs access to: in this case, the plane.
Now, let’s look at this from a more traditional point of view:
VPN as a Service:
- Owen tries to establish a VPN connection using Connect Client. The VPN is a restricted service that needs authentication. OpenVPN Cloud, acting as the Service Provider, opens an embedded web browser in the client that shows the identity provider’s login screen.
- Owen enters his SSO credentials. The Identity Provider then passes the authenticated identity to the Service Provider (OpenVPN Cloud). OpenVPN Cloud now knows that Owen has been authorized for VPN access and allows the VPN client to establish the connection.
And that’s SAML in action. Owen logged into his VPN Client and authenticated via his IdP, which gave him access to connect to the company VPN.
SAML + OpenVPN Cloud
OpenVPN Cloud offers SAML authentication for SSO. This provides the option to authenticate OpenVPN Cloud services using an IdP such as Okta, G Suite, Azure AD, and many others. Now, employees can just log into the VPN Client using their credentials from the IdP and will be granted access to connect to the VPN.
TL;DR: Advantages of using SAML + OpenVPN
- You no longer need to add users manually through the OpenVPN Cloud Administration Portal. Just provide them access to OpenVPN Cloud using your Identity Provider.
- You can map an Identity provider attribute for your users to OpenVPN Cloud User Group. This will allow you to correctly map your users to appropriate OpenVPN Cloud User Groups and enforce least privilege access using Access Groups.
- Your users do not need to remember yet another username/password combination.
Get started with three free VPN connections on OpenVPN Cloud.