A new world for integration: SAML and Identity

SAML was initially a standard for cross-domain SSO. A user who is logged on to the domain *.i8c.be could transparently point his browser to a web application in another domain *.cronos.be without having to authenticate again. His identity (and other attributes) are passed on transparently, behind the scenes. Many mechanisms were defined to exchange the information contained in SAML token (signed XML structures) between an Identity Provider and a Relying Party, including SOAP very early on (the SAML SOAP Binding).

But SAML was taken further. WS-Security SAML Token Profile allows the use of SAML tokens in SOAP messages secured with WS-Security. And WS-Trust and its Secure Token Service standardized the mechanism to obtain or exchange SAML (or other) tokens.

The STS is a standard (web) service to obtain such a SAML token: 1) through standard authentication mechanisms or 2) by exchanging one token for another (SAML to SAML, non-SAML to SAML or SAML to non-SAML).

But transferring SAML tokens between domains means the exchange of information between heterogeneous organizations. The SAML standard does not define how attributes within the SAML tokens should be named nor what their content should exactly look like. Every organziation is free to specify how information is structured in a SAML token:

  • what information or attributes is contained in the SAML token: name, cost center, department, …
  • how the atrributes should are named, e.g. LastName or lname?
  • how the information in the attributes is represented

Imagine a vendors of office materials (Staples) that wants to offer a SSO experience to the employees of its majore customers. If every customer (large enterprises themselves) use a different SAML token structure, the office material vendor will have a great time translating the information from these different SAML tokens to its own attributes. And what if information is missing in the SAML token, e.g. what is the maximum value that employee may purchase?

Another integration challenge!

Note: Microsoft prefers the use of the term claim

Authored by: Guy



Curious to know more about this topic?

Working at i8c

i8c is a system integrator that strives for an informal atmosphere between its employees, who have an average age of approx 30 years old. We invest a lot of effort in the professional development of each individual, through a direct connection between the consultants and the management (no multiple layers of middle management). We are based in Kontich, near Antwerp, but our customers are mainly located in the triangle Ghent-Antwerp-Brussels and belong to the top 500 companies in Belgium (Securex, Electrabel, UCB, etc…).

Quality Assurance

i8c is committed to delivering quality services and providing customer satisfaction. That’s why we invested in the introduction of a Quality Management System, which resulted in our ISO9001:2000 certification. This guarantees that we will meet your expectations, as a reliable, efficient and mature partner for your SOA & integration projects.

i8c - ISO9001-2015

Also worth reading

AWS AppFlow: Streamlining SaaS Integrations with AWS Services

In today’s digital world, organizations are constantly looking for ways to streamline their workflows and improve their data management processes. One of the key challenges that organizations face is integrating their various software as a service (SaaS) applications with their data management systems. This is

Read More »

Apigee Scope Validation using OpenAPI Specification

In API security and management, we often use a lot of different security mechanisms to protect the requested resource behind the API Gateway. One of these mechanisms is the validation of scopes to authorize a client on a specific sub-resource of the API. Most of

Read More »