Adding SAML SSO in your Golang service in 20 minutes
It’s really easy
SAML protocol continues to be one of the most used authentication protocols even after almost two decades since the initial release. Although now, some big players in the industry have started to transition to the latest Oauth2 and OpenID Connect. SAML 2.0 still remains the de facto standard for enterprise single sign-on.
SAML 1.0 was adopted as an OASIS standard in November 2002 followed by SAML 1.1 in September 2003 and SAML 2.0 in March 2005 . SAML 2.0 remains adopted industry-wide even today.
At some point in time, every organization needs to protect its services and resources from public access. The way to do it is using Single sign-on service which puts a layer of authentication in front of services by integrating with an Identity Provider. Too many new words?
What is Single Sign-on?
Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID and password to any of several related, yet independent, software systems.
Means you can sign-in once into your google account (or some other) and use the same account in multiple different services which are not owned by Google, without entering username and password again. Here the services put their trust in the authentication system provided by Google.
What is an Identity Provider (IDP)?
Identity provider offers user authentication as a service. In simple words, you can add and manage your user accounts, groups in an Identity Provider which gives you a way to authenticate your users while accessing any of your services.
So how does it happen?
In summary, whenever a user tries to access a website (or a resource) provided by a service provider, the service provider checks whether the user has a valid session with it.
- If the session is present then service provider returns the resource directly
- If the session is not present, the Service provider redirects to the IDP login page with a bundled SAML request.
- User puts his credentials on the login page after which IDP redirects back to the service provider with a signed SAML assertion.
- The service provider validates assertion source by verifying the signature and finally gives the user access to the resource along with a temporary session.
That was a lot to process, mostly because SAML request and assertion are just jargons which we don't understand. Let's dig into these to understand further
SAML Request
SAML Request contains information about the service provider which is trying to get authentication done with IDP. IDP may use this info to verify whether the request is coming from the right source or not.
SAML Assertion
SAML assertion is generated by Identity Provider after the User has successfully signed in.
Assertion contains information about the authenticated user like his email address, department, or any other claims. Since it's signed by the Identity Provider, it acts as a certificate for the user claiming the resource.
The service provider is already aware of the Identity Provider, it can verify the signature applied on the assertion and accept the information present in the assertion.
Ok, that's enough theory, let's do some coding.
To make it easy, there is already a Golang library available implemented by crewjam. So you don't need to get into protocol level details of integrating SAML in your service.
This looks fairly easy, you just need to configure it once, then there is no need to care about session management at all. The library does all the handling for you.
Running the program with Azure AD gives the following output
Token contents,
map[
http://schemas.microsoft.com/claims/authnmethodsreferences:[http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password] http://schemas.microsoft.com/identity/claims/displayname:[arpit] http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname:[arpit]
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name:[arpit@testdomain.onmicrosoft.com] http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname:[Khurana]]For each identity provider, like Azure, Gsuite, Okta or any other, you will need to configure some parameters
- Reply URL: This is the URL where Identity Provider will send the assertion. The allowed value has to be configured in the Identity Provider. Value: serverurl/saml/acs Example: https://localhost/saml/acs
- Entity ID: This ID works uniquely identifies Service Provider in the eyes of the Identity provider. It is sent to IDP in each SAML request for validation. Value: any URL which is not already configured Example: https://localhost
- Metadata: We need metadata URL in our service to get details of the Identity Provider like login page URL and signing certificate for assertion verification etc. Metadata URL is not supported by all Identity providers, some providers may give a metadata file.
IDP configuration is out of scope for this article. I have added few links for configuring major IDPs in the appendix.
Appendix
- https://medium.com/@robert.broeckelmann/saml-v2-0-vs-jwt-series-550551f4eb0d
- https://github.com/crewjam/saml
Setting up IDP configuration
