If you like acronyms, you should be working with the Identity Server. From OAUTH to XACML to SAML, it is really acronyms galore.
After looking at OAUTH2 in a previous blog, we will now zoom in on Security Assertion Markup Language (SAML) and Single Sign On (SSO).
What is SAML
Knowing what the acronym stands for does not really help you in the sense that suddenly everything becomes clear. So let’s dive in a bit more.
SAML is an XML based language to exchange security assertions (in other words security ‘statements’) between systems. These statements pertain to authentication (verification of identity) and authorization (validation of access rights).
SAML revolves around a number of concepts:
- Service Provider (SP, e.g. a website with content that you would like to view)
- Identity Provider (IDP, e.g. a website or service that can authenticate you)
- User or principal (you, the person using it)
The flow is as follows:
- User access the Service Provider with SAML secured application
- The SP sends (via a 302 redirect http status code ) the user to a pre-registered IdP for authentication. ‘samlp’ is the SAML 2.0 protocol namespace, ‘urn:oasis:names:tc:SAML:2.0:protocol’
- If user is not authenticated yet, IdP interacts with user to authenticate him/her
- IdP sends a response to SP with the token for the user
An Example
So a SAML message would for instance transport that fact that I successfully signed in to system A to system B enabling Single Sign On. This mechanism is extremely useful since it allows to log in only once and using SAML message log in to all other systems that I need to do my job.
For example: a bank employee signs in to his computer and in the background is signed in to:
- Loans system;
- HR portal;
- Mortgages system;
- Bloomberg Terminal;
- Trading system and so on.
Without SSO it would be hard to manage separate strong passwords and time consuming to manually login to all of these systems.
Like OAUTH2, SAML is a complex topic and we will set the scope of this blog by explaining the basics that you need to know in order to use it in a responsible manner.
The anatomy of SAML messages
A SAML message is a bit like a well wrapt present. Imagine a vase that you want to ship. First you wrap the vase in paper against scratches and breakage. Then in wrapping paper since it is a git. Since you want to ship it, bubblewrap and a box. The box then gets closed and an address sticked to it.
A SAML message has a similar structure albeit of a different nature. The purpose is nevertheless the same, making sure the message can be sent and received.
A SAML message can be rather big and complex. In order to keep this blog easy to understand we will look at the essence of SAML, rather than all of the possibilities of SAML.
SAML uses SOAP (1.1). Below you find a SAML message from the WSO2 Identity Server Fundamentals training. Here we try to create a SSO with Identity Server as Identity Provider (IDP) and Freshdesk and Salesforce as service provider. Here you see that when we want to log in, de IDP is asked for the authentication of the user.
This gives a nice overview of the kind of message that are exchanged when SSO is invoked. You can monitor SAML messages (requests and responses) for instance with a Chrome or Firefox add-on like SAML Chrome Panel.
If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.
{{cta(‘d96cddee-168c-42a5-a0b6-00a670e766b7’)}}
