Security Assertion Markup Language (SAML) defines a common XML framework for creating, requesting, and exchanging authentication and authorization data among entities known as Identity Providers (IdPs) and Service Providers (SPs). This exchange enables single sign-on among such entities.
In simple terms, an IdP is a claims producer and a service provider is a claims consumer. An IdP produces assertions about users, attesting to their identities. Service providers consume and validate assertions before providing access to resources.
SAML 2.0 is an OASIS open standard. The SAML core specification defines the structure and content of assertions. For the SAML 2.0 features that Access Policy Manager) APM) supports, see solution article sol16497 on the AskF5 web site located at http://support.f5.com/.
SAML metadata specifies how configuration information is defined and shared between two communicating entities: a SAML Identity Provider (IdP) and a SAML service provider. Service provider metadata provides information about service provider requirements, such as whether the service provider requires a signed assertion, the protocol binding support for endpoints (AssertionConsumerService) and which certificates and keys to use for signing and encryption. IdP metadata provides information about IdP requirements, such as the protocol binding support for endpoints (SingleSignOnService), and which certificate to use for signing and encryption.
Single logout (SLO) service is a way to allow a user to terminate all sessions in an automatic manner without user intervention. A SAML Identity Provider (IdP) or the SAML service provider (SP) can initiate logout. The SAML IdP coordinates all logouts. When a SAML SP initiates a logout it contacts the SAML IdP to carry out the coordinated logout on its behalf.
Access Policy Manager® (APM®) supports SLO when all participating entities (SAML SPs and IdPs) support SLO. APM supports HTTP-POST binding for SLO messages.
SAML artifact resolution protocol provides a mechanism by which a service provider (SP) can obtain a SAML assertion from an Identity Provider (IdP) by reference. Instead of binding an assertion to a transport protocol, an IdP sends a small piece of data (known as an artifact) using either HTTP POST or HTTP Redirect bindings. An SP can then use artifact resolution protocol with the SOAP binding protocol to resolve the artifact into the original assertion.
Although the SAML 2.0 specification supports using an artifact in place of any SAML message (request or response), the BIG-IP® system supports using artifacts for assertions only.
When BIG-IP is configured as a SAML IdP, an artifact resolution service on the BIG-IP system can process artifact resolution requests and artifact resolution responses.
When BIG-IP is configured as a SAML SP, it can send the artifacts it receives to a URL that the IdP specifies for resolving artifacts into assertions.
APM supports Microsoft Office 365 as a SAML service provider (SP). The BIG-IP system, configured as a SAML Identity Provider (IdP), supports the Enhanced Client or Proxy Profile (ECP) SAML profile. APM includes a predefined external service provider connector for Office 365. The SP connector supports assertion consumer services with PAOS (HTTP reverse SOAP) and POST bindings.
Configure a BIG-IP system as a SAML identity provider (IdP) when you have one BIG-IP system and you want it to provide single sign-on authentication service for a group of external SAML service providers.
Configure a BIG-IP system as a SAML service provider when you have one BIG-IP system and you want it to protect services that are behind it, and direct users to an external SAML identity provider for authentication.
For security purposes, each SAML service provider (SP) should have a certificate from the SAML Identity Provider (IdP) that manages identities for it; each IdP should have certificates from the SPs for which it manages identities.
Metadata normally includes a certificate. When you import metadata into a BIG-IP® system from an external SP or an external IdP, the certificate that was included in the metadata is stored on the BIG-IP system. When you configure security-related settings on the BIG-IP system, you select certificates from the store.
If you do not have metadata that you can import from external SPs or IdPs, then you need to do one of the following:
To get a certificate from the BIG-IP system, you can export it. You can potentially also get a certificate from a BIG-IP system by exporting SAML metadata for use on the external system.
When you export metadata from a BIG-IP system, it includes a certificate. However, when an external system requires signed metadata, the external system must already have a certificate from the BIG-IP system to validate the metadata.