In a typical SAML 2 environment, specially formed URLs that incorporate the single sign-on action to take, the binding to be used for the action, and the location where the action should take place can be used for user-initiated single sign-on actions. These URLs are referred to as profile initial URLs and should be provided within the SAML Metadata.
Architects and application developers, who will design and implement their users' interaction with the single sign-on process, will need to understand profile initial URLs and incorporate them into their Web applications.
The following sections describe the format of the SAML 2.0 profile initial URLs that are supported in a Tivoli Federated Identity Manager Business Gateway environment.
Another type of SAML profile is an attribute profile. SAML defines a series of attribute profiles to provide specific rules for interpretation of attributes in SAML attribute assertions. An example is the X.500/LDAP profile, describing how to carry X.500/LDAP attributes within SAML attribute assertions. Bindings and profiles connect SAML with the wire
A "profile" is a pattern for how to make assertions about other information.
For example, currently there Two browser profiles for SSO
Profiles are sort of like choreography templates. SAML is intentionally desgined to be very flexible and profiles give you a way to standardize on particular flows of SAML-related data in order to secure some other traffic.
The SAML committee is standardizing some of these, but the intention of seeing more created by others. We hope that these will be standardized by some body, or at least openly specified.
A SAML profile describes in detail how SAML assertions, protocols, and bindings combine to support a defined use case. The most important SAML profile is the Web Browser SSO Profile.
In SAML 1.1, all flows begin with a request at the identity provider for simplicity. Proprietary extensions to the basic IdP-initiated flow have been proposed (by Shibboleth, e.g.).
Unlike previous versions, SAML 2.0 browser flows begin with a request at the service provider. This provides greater flexibility, but SP-initiated flows naturally give rise to the so-called Identity Provider Discovery problem, the focus of much research today.
In addition to Web Browser SSO, SAML 2.0 introduces numerous new profiles:
A number of these profiles are discussed in more detail in the SAML 2.0 topic.
[#1] Wikipedia http://en.wikipedia.org/wiki/Security_Assertion_Markup_Language