SAML Architecture

This section describes the core SAML concepts and components briefly.

3.2.1 SAML Participants and Scenarios

SAML which exchanges take place between system entities referred to as a SAML asserting party and a SAML relying party is different from other security systems due to its approach of expressing assertions about a subject that other applications within a network can trust [5].

Asserting party

The system that makes SAML assertions asserts information about a subject. It is also called a SAML authority which role is defined as identity provider (IDP).

Relying party

The system that relies on information supplied to it by the asserting party uses assertions it has received. It is up to the relaying party as to whether it trusts the assertions provided to it. SAML defines the role called service provider (SP).

Subject

At the heart of SAML assertions, a subject, could be a human but also could be some other kind of entity, such as a company or a computer. The terms subject and user tend to be used interchangeably in this thesis.

When a SAML asserting or relying party makes a direct request to another SAML entity, the party making the request is called a SAML requester, and the other party is referred to as a SAML responder. A relying party`s willingness to rely on information from an assertion party depends on the existence of a trust relationship with the asserting party.

A typical assertion about a subject who has been authenticated and has given associated attributes from an identity provider might convey information such as “This user is Bob Li, he has an email address of [email protected], and he was authenticated into this system using a password mechanism,” A service provider could choose to use this information, depending on its access policies, to grant Bob Li web SSO access to local resources. Figure 3.2.1 illustrates the concept of Web SSO, and how to achieve this purpose will be demonstrated later in the thesis.

In this case, a user has a login session on a web site, Company.com, and is accessing resources on that site. At sometime, he is directed over to a partner`s web site, Travel.com.

Assuming a trust relationship has been previous established between Company.com and Figure 3.2.1 SAML Participants

Travel.com based on a business agreement between them. The identity provider site, Company.com, asserts to the service provider site, Travel.com, that the user has authenticated to it and has certain identity attributes (e.g. has a “Gold” status). Since Travel.com trusts Company.com, it trusts that the user is valid and properly authenticated and thus creates a local session for the user. The user is not required to re-authenticate when directed over to the Travel.com site. Once logged in, the IdP can produce an assertion that can be used by the SP to validate the user`s access rights to the protected resource [5].

3.2.2 SAML Components

SAML consists of building-block components that allow many use cases to be supported, when put the components together. It has the following key concepts: [6]

Assertion: A SAML assertion is a package of information that carries statements about a subject. Assertions are created by a SAML authority. SAML defines three kinds of statements that can be carried within an assertion.

 Authentication statements: They describe the means used to authenticate the user and the specific time at which the authentication took place.

 Attribute statements: These contain specific details or identifying attributes about the subject, for example, the user holds “Gold” card status.

 Authorization decision statements: These define what the subject is entitled to do, for example, whether a user is permitted to buy a specific production.

Protocol: SAML defines a number of generalized request/response protocols for obtaining assertions. SAML protocol messages are used to make the SAML requests which can either ask for a specific known assertion or make authentication, attribute, and authorization decision queries and return appropriate responses.

Bindings: A binding details exactly how the various SAML protocol messages map onto underlying transport and messaging protocols. For example, SAML provides a binding of how request/response protocols are carried within SOAP exchanges over HTTP.

Profiles: SAML profiles typically define how the SAML assertions, protocols, and bindings are combined and constrained to solve particular business use cases in an interoperable fashion, for example the Web Browser SSO profile.

Figure 3.2.2 illustrates the relationship between these basic SAML concepts. [6]

3.2.3 Security in SAML

SAML defines many security mechanisms to detect and protect against the

“man-in-the-middle” attacks. The primary mechanism is for the relying party and asserting party to have a pre-existing trust relationship which typically relies on a Public Key Infrastructure (PKI). Using PKI is recommended by SAML, however, what is recommended is provided below:

HTTP over SSL 3.0 or TLS 1.0 is recommended to ensure message integrity and message confidentiality.

When a relying party requests an assertion from an asserting party then bi-lateral authentication is required and the use of SSL 3.0 or TLS 1.0 using mutual authentication or authentication via digital signatures is recommended.

When a response message containing an assertion is delivered to a relying party via a Figure 3.2.2 Basic SAML Component

user`s web browser, it is mandated that the response message be digitally signed using the XML signature standard to ensure message integrity [5][7].