GUI snapshots:
http://content.zdnet.com/2346-11470_22-188303.html

[ group ref ]

Google offers two tools to help partners understand and implement a SAML-based SSO service.

1. The SAML-based SSO Static Demo demonstrates the SAML transaction process. The demo uses static files to simulate the transactions that Google and the partner company would conduct to log a user into a hosted Google application (Gmail).
2. The Web-based Reference Implementation is an interactive Java application that allows partners to view the XML generated for SAML requests and responses. The documentation for the tool explains how the partner could modify the tool to submit SAML requests to an internal application that actually authenticates a user.

Both of these tools display a similar interface. However, the static demo does not actually execute any code whereas the web-based reference implementation provides Java code that demonstrates the functionality a partner will need to perform to process SAML requests and generate SAML responses.

How does the relying party trust what is being asserted to it? In addition, what prevents a “man-in-the-middle” attack that might grab assertions to be illicitly “replayed” at a later date? These and many more security considerations are discussed in detail in the SAML Security and Privacy Considerations specification [SAMLSec].

SAML allows for message integrity by supporting XML digital signatures in request/response messages.

SAML suports public key exchange either out of band or included in request/response messages.

If additional message privacy is needed, SAML supports sending request/response messages over SSL 3.0 or TLS 1.0. There are other security features that should be covered here such as the security levels of the different bindings, and the fact that both the IDP and SP can create opaque handles to represent the user’s account for privacy issues but this would take alot of energy and time to cover…

[ Security Assertions and Protocol Digest here ]

docs.oasis-open.org

This post encompasses OASIS SAML for Multiple Single Sign On solutions. . .
This list of definitions takes a more detailed look at each of the components that represent the assertion, protocol, binding, and profile concepts in a SAML environment.

• Assertions: SAML allows for one party to assert security information in the form of statements about a subject. For instance, a SAML assertion could state that the subject is named “John Doe”, has an email address of john.doe@example.com, and is a member of the “engineering” group. An
assertion contains some basic required and optional information that applies all assertions, and usually contains a subject of the assertion, conditions used to validate the assertion, and assertion statements. SAML defines three kinds of statements that can be carried within an assertion:
• Authentication statements: These are created by the party that successfully authenticated a user. At a minimum, they describe the particular means used to authenticate the user and the specific time at which the authentication took place.
• Attribute statements: These contain specific identifying attributes about the subject (for example, that user “John Doe” has “Gold Membership” card status).
• Authorization decision statements: These define something that the subject is entitled to do (for example, whether “John Doe” is permitted to buy a specified item).
• Protocols: SAML defines a number of generalized request/response protocols:
• Authentication Request Protocol: Defines a means by which a principal (or an agent acting on behalf of the principal) can request assertions containing authentication statements and, optionally, attribute statements. The Web Browser SSO Profile uses this protocol when redirecting a user from an SP to an IdP when it needs to obtain an assertion in order to establish a security context for the user at the SP.

• Single Logout Protocol: Defines a mechanism to allow near-simultaneous logout of active sessions associated with a principal. The logout can be directly initiated by the user, or initiated by an IdP or SP because of a session timeout, administrator command, etc.

• Assertion Query and Request Protocol: Defines a set of queries by which SAML assertions may be obtained. The Request form of this protocol can ask an asserting party for an existing assertion by referring to its assertion ID. The Query form of this protocol defines how a relying party can ask for assertions (new or existing) on the basis of a specific subject and the desired statement type.

• Artifact Resolution Protocol: Provides a mechanism by which SAML protocol messages may be passed by reference using a small, fixed-length value called an artifact. The artifact receiver uses the Artifact Resolution Protocol to ask the message creator to dereference the artifact and return the actual protocol message. The artifact is typically passed to a message recipient using
one SAML binding (e.g. HTTP Redirect) while the resolution request and response take place over a synchronous binding, such as SOAP.

• Name Identifier Management Protocol: Provides mechanisms to change the value or format of the name identifier used to refer to a principal. The issuer of the request can be either the service provider or the identity provider. The protocol also provides a mechanism to terminate an association of a name identifier between an identity provider and service provider.

• Name Identifier Mapping Protocol: Provides a mechanism to programmatically map one SAML name identifier into another, subject to appropriate policy controls. It permits, for example, one SP to request from an IdP an identifier for a user that the SP can use at another SP in an application integration scenario.

• Bindings: SAML bindings detail exactly how the various SAML protocol messages can be carried over underlying transport protocols.
The bindings defined by SAML V2.0 are:
• HTTP Redirect Binding: Defines how SAML protocol messages can be transported using HTTP redirect messages (302 status code responses).
• HTTP POST Binding: Defines how SAML protocol messages can be transported within the base64-encoded content of an HTML form control.
• HTTP Artifact Binding: Defines how an artifact (described above in the Artifact Resolution Protocol) is transported from a message sender to a message receiver using HTTP. Two mechanisms are provided: either an HTML form control or a query string in the URL.
• SAML SOAP Binding: Defines how SAML protocol messages are transported within SOAP 1.1 messages, with details about using SOAP over HTTP.
• Reverse SOAP (PAOS) Binding: Defines a multi-stage SOAP/HTTP message exchange that permits an HTTP client to be a SOAP responder. Used in the Enhanced Client and ProxyProfile and particularly designed to support WAP gateways.
• SAML URI Binding: Defines a means for retrieving an existing SAML assertion by resolving a URI (uniform resource identifier).

• Profiles: SAML profiles define how the SAML assertions, protocols, and bindings are combined and constrained to provide greater interoperability in particular usage scenarios. Some of these profiles are examined in detail later in this document. The profiles defined by SAML V2.0 are:
• Web Browser SSO Profile: Defines how SAML entities use the Authentication Request Protocol and SAML Response messages and assertions to achieve single sign-on with standard web browsers. It defines how the messages are used in combination with the HTTP Redirect,
HTTP POST, and HTTP Artifact bindings.
• Enhanced Client and Proxy (ECP) Profile: Defines a specialized SSO profile where
specialized clients or gateway proxies can use the Reverse-SOAP (PAOS) and SOAP bindings.
• Identity Provider Discovery Profile: Defines one possible mechanism for service providers to learn about the identity providers that a user has previously visited.
• Single Logout Profile: Defines how the SAML Single Logout Protocol can be used with SOAP, HTTP Redirect, HTTP POST, and HTTP Artifact bindings.
• Assertion Query/Request Profile: Defines how SAML entities can use the SAML Query
• Artifact Resolution Profile: Defines how SAML entities can use the Artifact Resolution Protocol over a synchronous binding, such as SOAP, to obtain the protocol message referred to by an artifact.
• Name Identifier Management Profile: Defines how the Name Identifier Management Protocol may be used with SOAP, HTTP Redirect, HTTP POST, and HTTP Artifact bindings.
• Name Identifier Mapping Profile: Defines how the Name Identifier Mapping Protocol uses a synchronous binding such as SOAP.

Figure 6 shows an XML fragment containing an example assertion with a single authentication statement. Note that the XML text in the figure (and elsewhere in this document) has been formatted for presentation purposes.

SAML’s predefined formats do include Kerberos principal name along with others found here pg17

Persistent identifiers provide a permanent privacy-preserving federation since they remain associated with the local identities until they are explicitly removed.

Attribute Statement Structure

Attribute information about a principal is often provided as an adjunct to authentication information in single sign-on or can be returned in response to attribute queries from a relying party. A single statement can contain multiple attributes. In this example, there are three attributes (starting on lines 2, 10, and 16) within the statement.

X.500/LDAP Attribute Profile to define a value for the LDAP attribute identified by the OID “2.5.4.42”.

Message Structure and the SOAP Binding

In environments where communicating SAML parties are SOAP-enabled.

Figure 9 shows an XML document containing an example SAML authentication request message being transported within a SOAP envelope.

An example XML fragment containing a SAML protocol Response message being transported in a SOAP message is shown in Figure 10.