SAML Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(55 intermediate revisions by the same user not shown)
Line 2: Line 2:


* [[SAML#Subjects|SAML]]
* [[SAML#Subjects|SAML]]
=Security Assertion=


=Subject=
=Subject=


Subjects are entities that have identity related information specific to a [[#Security_Domain|security domain]].
Subjects are entities that have identity related information specific to a [[#Security_Domain|security domain]].
=Principal=
==Pseudonyms==
SAML uses ''pseudonyms'' to provide a privacy-enabling "alias" for global identifiers, to avoid collisions between service providers. The pseudonyms are opaque pseudo-random identifiers, with no discernible correspondence with meaning identifiers such as e-mail addresses, between service providers to represent [[#Principal|principals]].


=Security Domain=
=Security Domain=
Line 15: Line 19:
The Identity Provider (IdP) is.
The Identity Provider (IdP) is.


The Identity Provider is also known as the ''asserting party''.
The Identity Provider is also known as a ''security provider'' or the ''asserting party''.


=Service Provider=
=Service Provider=
Line 27: Line 31:
There is a ''trust relationship'' between the Identity Provider and and the Service Provider.
There is a ''trust relationship'' between the Identity Provider and and the Service Provider.


=SAML Use Cases=
=Request-Response Model=
==Web Browser Single Sign-On==


Web browser single sign-on (SSO) among independent but cooperating parties is the most important SAML use case. Another more recent approach to addressing browser SSO is the [[OpenID Connect]] protocol.
SAML uses a request-response model to implement interaction between the Service Provider and Identity Provider. For more details see {{Internal|SAML Request-Response Model|SAML Request-Response Model}}


==Attribute-based Authorization==
=Token=


==Identity Federation==
A SAML token is a type of token issued by a STS/IdP that can be used to enable SSO. A [[#Service_Provider|relying resource]] secured by SAML will redirect users to SAML identity provider to obtain a valid SAML token before authenticating and authorizing the user.


==WS-Security==
A client application relying on SAML must be able to parse and process the token.


=SAML Profile=
=SAML Profile=


A ''profile'' is essentially a use case for SAML. <font color=red>If that is true, map to use cases above and coalesce</font>. The profile combines [[#SAML_Assertion|assertions]], [[#SAML_Protocol|protocols]] and [[#SAML_Binding|bindings]] to support a specific use case.
A ''profile'' is essentially a use case for SAML. A profile combines [[#SAML_Assertion|assertions]], [[#SAML_Protocol|protocols]] and [[#SAML_Binding|bindings]] to support specific use cases.  For example, the [[SAML Web Browser Single Sign-On Profile|Web Browser SSO Profile]] specifies how SAML authentication assertions are communicated between an [[#Identity_Provider|Identity Provider]] and [[#Service_Provider|Service Provider]] to enable single sign-on for a browser user. From a high level perspective, several notable SAML use cases are [[SAML Web Browser Single Sign-On Profile|Web Browser Single Sign-On]], Attribute-based Authorization, Identity Federation and WS-Security.
 
[[Image:SAML_Concepts_Profile_Binding_Protocol_Assertion.png]]
 
For more details on SAML profiles, see: {{Internal|SAML Concepts - Profile|SAML Profile}}


=SAML Binding=
=SAML Binding=
SAML ''protocol bindings'' are the mappings from SAML request/response message exchanges into standard messaging or communication protocols. For more details see: {{Internal|SAML Concepts - Binding|SAML Binding}}


=SAML Protocol=
=SAML Protocol=
A SAML protocol is represented by the sequence of requests and responses for obtaining assertions and performing identity management.
{{Internal|SAML Concepts - Protocol|SAML Protocol}}


=SAML Assertion=
=SAML Assertion=
The SAML ''assertion'' is apiece of data in XML format, produced by an SAML authority (for example, [[SAML_Architecture#Authentication_Authority|Authentication Authority]], and transferred between the [[#Identity_Provider|security providers]] and the service providers. Assertions contain ''statements'' issued by a SAML authority. Applications and service providers use these statements make authentication and authorization decisions. Assertions can be:
* <span id='Authentication_Assertion'></span>'''Authentication Assertion''': an assertion that carries data about a successful authentication performed on a subject. The assertion certifies that the subject was authenticated by the Identity Provider with a particular authentication mechanism at a certain time. This is an [[SAML AuthnQuery and AuthnStatement|example of a request/response that consists in an authentication query and a authentication assertion response]].
* <span id='Authorization_Decision_Assertion'></span>'''Authorization Decision Assertion''': an assertion that carries data about an authorization decision. For example, the authorization decision may indicate that the subject is allowed to access a requested resource. The resource is typically identified by a URI reference. The response reflects the authorization decision, expressed as the <Decision> element, which may be "Permit", "Deny", or "Indeterminate". It usually includes the resulting actions using the element <Action> and a set of assertions using the element <Evidence> that the SAML authority relied on while making the decision. This is an [[SAML AuthzDecisionQuery and AuthzDecisionStatement|example of a request/response that consists in an authorization query and a authorization assertion response]].
* <span id='Attribute_Assertion'></span>'''Attribute Assertion''': an assertion that carries data about the attributes of a subject.
Each SAML assertion consists of ''basic information'', such as unique identifier of the assertion and issue date and time, ''conditions'' - dependency or rule for the assertion - and ''advice'' - specification of the assertion for policy decision.
More details {{External|http://saml.xml.org/assertions}}
=Authentication Context=
<font color=red>Detailed data on types and strengths of Authentication.</font>
=Metadata=
<font color=red>
Metadata is an XML document that specifies configuration for IdPs and SPs. Configuration elements:
* endpoint of the single sign on
* expect request/response with signature
* support bindings of request/response (GET/POST)
* X.509 Certificate used for signature and verification
SAML metadata specify how configuration and trust-related data can be more easily deployed in SAML systems. Identity providers and service providers often need to agree on data such as roles, identifiers, and supported profiles. SAML metadata provides a structure for identifying the actors involved in the various profiles, such as single sign-on identity provider, attribute authority, and requester.
</font>
=Standards SAML 2.0 Relies On=
* XML Schema
* [[XML Signature]]
* XML Encryption
* HTTP
* SOAP
=SAML Architecture=
{{Internal|SAML Architecture|SAML Architecture}}
=Single Sign-On (SSO)=
Single sign-on (SSO) is not strictly a SAML concept. However, because SAML provides a trusted way to share security information, applications using SAML can participate in single sign-on scenario where the identity of a subject is verified by a party and other party uses it because it trusts the first party and the communication mechanisms between them. SAML requires the user to enroll with at least one SAML-enabled security provider. The identity of the user will be verified (authenticated) by that security provider. [[#Web_Browser_Single_Sign-On|Web browser single sign-on]] is a SAML profile.


=To Deplete=
=To Deplete=

Latest revision as of 01:16, 7 November 2017

Internal

Subject

Subjects are entities that have identity related information specific to a security domain.

Principal

Pseudonyms

SAML uses pseudonyms to provide a privacy-enabling "alias" for global identifiers, to avoid collisions between service providers. The pseudonyms are opaque pseudo-random identifiers, with no discernible correspondence with meaning identifiers such as e-mail addresses, between service providers to represent principals.

Security Domain

Identity Provider

The Identity Provider (IdP) is.

The Identity Provider is also known as a security provider or the asserting party.

Service Provider

The Service Provider (SP) is ....

The Service Provider is also known as the relying party.

Trust Relationship

There is a trust relationship between the Identity Provider and and the Service Provider.

Request-Response Model

SAML uses a request-response model to implement interaction between the Service Provider and Identity Provider. For more details see

SAML Request-Response Model

Token

A SAML token is a type of token issued by a STS/IdP that can be used to enable SSO. A relying resource secured by SAML will redirect users to SAML identity provider to obtain a valid SAML token before authenticating and authorizing the user.

A client application relying on SAML must be able to parse and process the token.

SAML Profile

A profile is essentially a use case for SAML. A profile combines assertions, protocols and bindings to support specific use cases. For example, the Web Browser SSO Profile specifies how SAML authentication assertions are communicated between an Identity Provider and Service Provider to enable single sign-on for a browser user. From a high level perspective, several notable SAML use cases are Web Browser Single Sign-On, Attribute-based Authorization, Identity Federation and WS-Security.

SAML Concepts Profile Binding Protocol Assertion.png

For more details on SAML profiles, see:

SAML Profile

SAML Binding

SAML protocol bindings are the mappings from SAML request/response message exchanges into standard messaging or communication protocols. For more details see:

SAML Binding

SAML Protocol

A SAML protocol is represented by the sequence of requests and responses for obtaining assertions and performing identity management.

SAML Protocol

SAML Assertion

The SAML assertion is apiece of data in XML format, produced by an SAML authority (for example, Authentication Authority, and transferred between the security providers and the service providers. Assertions contain statements issued by a SAML authority. Applications and service providers use these statements make authentication and authorization decisions. Assertions can be:

  • Authentication Assertion: an assertion that carries data about a successful authentication performed on a subject. The assertion certifies that the subject was authenticated by the Identity Provider with a particular authentication mechanism at a certain time. This is an example of a request/response that consists in an authentication query and a authentication assertion response.
  • Authorization Decision Assertion: an assertion that carries data about an authorization decision. For example, the authorization decision may indicate that the subject is allowed to access a requested resource. The resource is typically identified by a URI reference. The response reflects the authorization decision, expressed as the <Decision> element, which may be "Permit", "Deny", or "Indeterminate". It usually includes the resulting actions using the element <Action> and a set of assertions using the element <Evidence> that the SAML authority relied on while making the decision. This is an example of a request/response that consists in an authorization query and a authorization assertion response.
  • Attribute Assertion: an assertion that carries data about the attributes of a subject.

Each SAML assertion consists of basic information, such as unique identifier of the assertion and issue date and time, conditions - dependency or rule for the assertion - and advice - specification of the assertion for policy decision.

More details

http://saml.xml.org/assertions

Authentication Context

Detailed data on types and strengths of Authentication.

Metadata

Metadata is an XML document that specifies configuration for IdPs and SPs. Configuration elements:

  • endpoint of the single sign on
  • expect request/response with signature
  • support bindings of request/response (GET/POST)
  • X.509 Certificate used for signature and verification

SAML metadata specify how configuration and trust-related data can be more easily deployed in SAML systems. Identity providers and service providers often need to agree on data such as roles, identifiers, and supported profiles. SAML metadata provides a structure for identifying the actors involved in the various profiles, such as single sign-on identity provider, attribute authority, and requester.

Standards SAML 2.0 Relies On

SAML Architecture

SAML Architecture

Single Sign-On (SSO)

Single sign-on (SSO) is not strictly a SAML concept. However, because SAML provides a trusted way to share security information, applications using SAML can participate in single sign-on scenario where the identity of a subject is verified by a party and other party uses it because it trusts the first party and the communication mechanisms between them. SAML requires the user to enroll with at least one SAML-enabled security provider. The identity of the user will be verified (authenticated) by that security provider. Web browser single sign-on is a SAML profile.

To Deplete

Retrieved from "https://kb.novaordis.com/index.php?title=SAML_Concepts&oldid=30354"