FICAM SAML SSO for CSP, v1.0

This Trustmark Definition specifies the conformance criteria and assessment process for Credential Service Providers wishing to support FICAM SAML SSO.

Assessment Steps (14)

1
The CSP uses and supports SAML 2.0 (SAML_2_0_Check_Step)

Does this CSP support SAML 2.0? Please provide a sample SAML Response (as XML/Text).

Artifact
Sample SAML Response

Provide a full XML SAML Response as text or an uploaded XML file.

2
The CSP supports SAML Redirect Binding (SAML_Redirect_Binding_Step)

Does the CSP support the Redirect Binding for SP Initiated SAML SSO. Please provide a header trace with the full URL accessed on the Credential Service Provider.

Artifact
Header Trace Showing Redirect Binding Usage

Using a header tracing tool like the Chrome's Developer Tools linked earlier will make this an easy copy/paste operation.

3
Signature Verification on AuthnRequest (Signature_Verification_Step)

Does the Credential Service Provider verify the signature on a SAML AuthnRequest when it is signed? To do this step, the assessor needs to initiate SAML SSO from their SP at least twice, once signing with the key that was pre-established as trusted, and a second time with an untrusted key to verify that some sort of error condition occurred.

Artifact
CSP Signature Failure Error

Please provide a screen shot or logging details of the error(s) generated when an untrusted signature was sent.

4
Valid NameIDPolicy (Valid_NameIDPolicy_Step)

Does the CSP honor the Name ID Policy as requested by a SAML SP? Verify that both persistent and transient can be requested and supported. Please provide two SAML Assertions generated by this CSP, one for persistent and one for transient.

Artifacts
SAML Assertion - Persistent

Please provide in XML a copy of a SAML Assertion where a persistent name identifier is used.

SAML Assertion - Transient

Please provide in XML a copy of a SAML Assertion where a transient name identifier is used.

5
ForceAuthn Supported (ForceAuthn_Supported_Step)

Does the CSP honor the ForceAuthn flag within AuthnRequests? To perform this test, the assessor must initiate SAML SSO to the Credential Service Provider three times:

  1. Establish a session with the Credential Service Provider via normal mechanisms.

  2. Without ForceAuthn enabled, initiate SAML SSO again. Verify that the existing CSP session is used and that the assessor is not forced to authenticate again.

  3. With ForceAuthn enabled, initiate SAML SSO again. Verify that reauthentication is required to complete the sign on.

6
isPassive Supported (isPassive_Supported_Step)

Does the CSP honor the isPassive flag within AuthnRequests? To perform this test, the assessor must initiate SAML SSO to the Credential Service Provider three times:

  1. With no prior session having been established with the CSP, initiate SAML SSO with the isPassive flag; verify an error occurs.

  2. Establish a session with the Credential Service Provider via normal mechanisms.

  3. With isPassive enabled, initiate SAML SSO again, verify that reauthentication is NOT required to complete the sign on.

7
Assertion Consumer Service URL (ServiceURL_Step)

Does the Credential Service Provider strictly use the Assertion Consumer Service URL established during trust establishment (ie. the ACS from SAML 2 Metadata and not the ACS transmitted within a SAML AuthnRequest)? To test this, the assessor will need to change the configuration of their test Service Provider to temporarily use a different ACS and make sure that the CSP produces an error.

8
Post Binding (Post_Binding_Step)

Does the Credential Service Provider transmit SAML Responses via the POST binding? Please provide a header trace.

Artifact
Header Trace

Please provide a text trace of the headers for the SAML POST event (use a tool such as Chrome's developer tools).

9
Is Issuer Populated Correctly (Issuer_Correct_Step)

Does the Credential Service Provider correct populate the Issuer field in the SAML Response? The Issuer must match the entityId in the SAML 2 Metadata exchanged to establish trust.

Artifact
SAML Response

Please provide a sample SAML Response (or reference one already uploaded for this evaluation).

10
Assertion Exists (Assertion_Exists_Step)

Does the Response include an Assertion or Encrypted Assertion?

Artifact
SAML Response

Please provide a sample SAML Response (or reference one already uploaded for this evaluation).

11
Assertion Signed (Assertion_Signed_Step)

Does the CSP correctly apply an XML Digital Signature to the SAML Assertion?

Artifact
SAML Assertion

Please provide a sample SAML Assertion (or a reference to another SAML Assertion or a Response that does not include an Encrypted Assertion).

12
Authentication Statement (Authn_Stmt_Step)

Does the SAML Assertion include a valid Authentication Statement including an SAML Authentication Context Class Reference?

Artifact
SAML Assertion

Please provide a sample SAML Assertion (or a reference to another SAML Assertion or a Response that does not include an Encrypted Assertion).

13
Valid Conditions (Valid_Conditions_Step)

Does the SAML Assertion include valid Conditions? This requires an appropriate Audience Restriction and validity time constraints.

Artifact
SAML Assertion

Please provide a sample SAML Assertion (or a reference to another SAML Assertion or a Response that does not include an Encrypted Assertion).

14
Attribute Statement (Attribute_Stmt_Step)

Does the SAML Assertion include an Attribute Statement (with no Encrypted Attributes)?

Artifact
SAML Assertion

Please provide a sample SAML Assertion (or a reference to another SAML Assertion or a Response that does not include an Encrypted Assertion).

Conformance Criteria (16)

SAML 2.0

CSPs must use the SAML 2.0 protocol.

Citation
FICAM-SAML-SSO
Section 2.1
Redirect Binding

CSPs must support the use of the SAML HTTP Redirect Binding for SAML SSO.

Citation
FICAM-SAML-SSO
Section 3.1 requirement 9
Verify Signature

CSPs must verify the digital signature on SAML Authentication Requests when present.

Citation
FICAM-SAML-SSO
Section 3.1 requirement 10
NameIDPolicy

CSPs must support urn:oasis:names:tc:SAML:2.0:nameid-format:persistent and urn:oasis:names:tc:SAML:2.0:nameid-format:transient Name ID Formats. Additionally, CSPs must honor the Name ID requested within an Authentication Context.

Citation
FICAM-SAML-SSO
Section 3.1 requirement 8
ForceAuthn

CSPs must support the ForceAuthn flag within Authentication Requests.

Citation
FICAM-SAML-SSO
Section 3.1 requirement 4
isPassive

CSPs must support the isPassive flag within Authentication Requests.

Citation
FICAM-SAML-SSO
Section 3.1 requirement 5
Use of Assertion Consumer Service URL

CSPs must only use the Assertion Consumer Service URL configured during Metadata Exchange and not the one specified in the AuthnRequest.

Citation
FICAM-SAML-SSO
Section 3.1 requirement 6
Post Binding

CSPs must be able to transmit SAML Responses via the SAML POST binding.

Citation
FICAM-SAML-SSO
Section 3.2 requirement 2
Issuer

CSPs must populate the Issuer within their SAML Responses with their trusted EntityId.

Citation
FICAM-SAML-SSO
Section 3.2. requirement 3
Assertion

CSPs must include a SAML Assertion in all successful SAML Responses (those not containing an error status code). This SAML Assertion may be encrypted as an EncryptedAssertion.

Citation
FICAM-SAML-SSO
Section 3.2 requirement 4
Digital Signature

SAML Assertions must be digitally signed with a valid and trusted key that has been pre-established as trusted (ie. is published in SAML 2 Metadata).

Citation
FICAM-SAML-SSO
Section 3.2 requirement 10
Authn Statement

SAML Assertions must include an AuthnStatement.

Citation
FICAM-SAML-SSO
Section 3.2 requirement 5
Authn Context

The AuthnStatement must include a valid Authentication Context Class Reference.

Citation
FICAM-SAML-SSO
Section 3.2 requirement 6
Subject

SAML Assertions must include a Subject with valid NameID of urn:oasis:names:tc:SAML:2.0:nameid-format:transient or urn:oasis:names:tc:SAML:2.0:nameid-format:persistent.

Citation
FICAM-SAML-SSO
Section 3.2 requirement 7
Conditions

SAML Assertions must include appropriate Conditions, this includes an appropriate Audience Restriction and validity time constraints.

Citation
FICAM-SAML-SSO
Section 3.2 requirement 9
Attributes

SAML Assertions must include an AttributeStatement that includes no Encrypted Attributes and only the Attributes requested by the Relying Party.

Citation
FICAM-SAML-SSO
Section 3.2 requirement 8

Metadata

Publication Date 2017-05-18
Trustmark Reference Attribute https://artifacts.trustmarkinitiative.org/lib/trustmark-definitions/ficam-saml-sso-for-csp/1.0//trustmark-reference/
Issuing Organization
No Responder support@trustmarkinitiative.org 404-407-8956 75 5th Street NW, Suite 900, Atlanta, GA 30308
Keywords FICAM, SAML, SSO, CSP, Credential Service Provider, IDP, Identity Provider, Single Sign On, Interoperability,
Supersedes
Issuance Criteria
yes(ALL)
Assessment Step Preface

This assessment is intended to be performed on Credential Service Providers that wish to use of ICAM conforming SAML SSO. To adequately perform these steps the assessor must possess a test SAML Service Provider as well as tooling to inspect messages that are passed through the browser. The following tools and/or browser plugins may be useful:

The assessor's test Service Provider must be configured to trust the CSP being evaluated. Additionally, the CSP being evaluated must be configured to trust the test Service Provider.

Target Stakeholder Organizations that have a vested interest in the U.S. Federal Identity, Credential, and Access Management (FICAM) program and its technical specifications.
Target Recipient Credential Service Providers that wish to provide their users with access to Relying Party services offered by U.S. federal government agencies and other organizations that have adopted the FICAM SAML SSO Profile.
Target Relying Party Relying Parties that wish to conform to the FICAM SAML SSO Profile and/or interoperate with Identity Providers that conform to the FICAM SAML SSO Profile.
Target Provider Trust Framework Providers (TFPs) that are approved FICAM TFPs.
Provider Eligibility Criteria Any organization or business entity may act as a Trustmark Provider for trustmarks under this Trustmark Definition.
Assessor Qualifications Any individual employed or contracted by the Trustmark Provider may act as the assessor for trustmarks under this Trustmark Definition.
Trustmark Revocation Criteria For any trustmark issued under this Trustmark Definition, the Trustmark Provider must revoke the trustmark upon any condition whereby one or more Conformance Criteria cease to be satisfied.
Extension Description This Trustmark Definition requires no extension data.
Legal Notice This document and the information contained herein is provided on an "AS IS" basis, and the Georgia Tech Research Institute disclaims all warranties, express or implied, including but not limited to any warranty that the use of the information herein will not infringe any rights or any implied warranties or merchantability or fitness for a particular purpose. In addition, the Georgia Tech Research Institute disclaims legal liability for any loss incurred as a result of the use or reliance on the document or the information contained herein.

Sources (1)

Terms (23)

Term Name Abbreviations Definition
Account

An account is used to associate transactional records with an end user or organization. Presence of an account does not necessarily mean that there are credentials (e.g., username and password) associated with the account.

Assert

To make a statement about the properties of a user or user's act of authentication.

Authentication Session

Period of time that an end user remains trusted after the end user authenticates. That is because an IDP typically does not require an end user to re-authenticate for every page requested. Each IDP defines its own authentication session duration. If an end user returns to the IDP and an earlier authentication session has expired, the IDP re-authenticates the end user even if single sign-on is in effect.

Binding

Mappings of SAML request-response message exchanges onto standard messaging or communication protocols.

Consolidated Metadata

A single XML file containing a top-level root <md:EntitiesDescriptor> containing multiple <md:EntityDescriptor> and/or <md:EntitiesDescriptor> elements.

Credential Service Provider CSP

For the purposes of SAML SSO, they are synonymous with Identity Providers.

Digital Encryption

Private key data encryption that converts data into a form that cannot be easily understood by unauthorized people. Decryption is the process of converting encrypted data back into its original form, so it can be understood. Within the FICAM SAML Profile, encryption pertains to SSL v3 or TLS 1.1 (and higher), encryption and/or XML encryption, depending upon the Level of Assurance.

Digital Signature

An asymmetric key operation where the private key is used to digitally sign an electronic document and the public key is used to verify the signature. Digital signatures provide authentication and integrity protection.

Discovery

Process of an end user finding a IDP and/or RP.

Extensible Markup Language XML

XML is a specification developed by the W3C that enables the definition, transmission, validation, and interpretation of data between applications and between organizations. In a nutshell, XML describes data and focuses on what data is. XML facilitates technical interoperability, and is used in identity management standards such as SAML (e.g., to convey information in a SAML assertion).

Federal Identity, Credential, and Access Management Trust Framework Solutions FICAM TFS

The Federal Identity, Credential, and Access Management (FICAM) Trust Framework Solutions (TFS) program is is the federated identity framework for the U.S. Federal Government. It includes guidance, processes, and supporting infrastructure to enable secure and streamlined citizen and business facing online service delivery.

Holder-of-Key Assertion

A holder-of-key assertion contains a reference to a public key (corresponding to a private key) or a symmetric key possessed by the end user. The RP requires the end user to prove possession of the private key or secret that is referenced in the assertion. In proving possession, the end user also proves that he or she is the rightful owner of the assertion.

Identity Provider IDP

For the purposes of SAML SSO, they are synonymous with Credential Service Providers. A kind of service provider that creates, maintains, and manages identity information for principals and provides principal authentication to other service providers (relying parties) within a federation, such as with web browser profiles.

Metadata

Information shared between endpoints (e.g., RP, IDP) necessary for technical interoperation.

Persistent

Ability to maintain data.

Protected Session

A session wherein messages between two participants are encrypted and integrity is protected using a set of shared secrets called session keys. A participant is said to be authenticated if, during the session, he, she or it proves possession of a long term token in addition to the session keys, and if the other party can verify the identity associated with that token. If both participants are authenticated, the protected session is said to be mutually authenticated. One way to implement a protected session is SSL/TLS, which is required for this Profile.

Pseudonymous Identifier

Private end user pseudonym that will only be used with one site. The site will always know it's you when you come back, but it won't be able to look up any other information about you, or correlate your profile with other sites.

Relying Party RP

A system entity (i.e., stand-alone system or group of applications that rely on a central authentication system) that decides to take an action based on information from another system entity. For example, a SAML Relying Party depends on receiving assertions from an asserting party (e.g., a SAML Identity Provider) about a subject. A Relying Party is also referred to as a Service Provider.

Security Assertion Markup Language SAML

The set of specifications describing security assertions that are encoded in XML, profiles for attaching the assertions to various protocols and frameworks, the request/response protocol used to obtain the assertions, and bindings of this protocol to various transfer protocols (for example, SOAP and HTTP). SAML addresses web single sign-on, web services authentication, attribute exchange, authorization, non-repudiation, and secure communications. SAML defines assertion message formats that are referenced in Liberty Alliance, Shibboleth, WS-Security, and other specifications. SAML has become the standard web SSO identity management solution. Several versions have been released to date, including SAML 1.0, SAML 1.1, and SAML 2.0. The Organization for the Advancement of Structured Information Standards (OASIS) oversees SAML.

Security Token Service STS

An STS provides a standards-based method of converting security tokens across different formats.

Service Provider SP

For the purpose of SAML SSO, they are synonymous with Relying Parties. Service Providers generate SAML AuthnRequests, provide users with discovery interfaces, consume SAML Responses, and generally provide some sort of service or capability for a user.

Signature Verification

The process of checking the digital signature by reference to the original message and a given public key, thereby determining whether the digital signature was created for that same message using the private key that corresponds to the referenced public key.

Single Sign-on SSO

Once an end user has authenticated their identity at an IDP, he or she may, by their choice, move among RPs that interoperate with the IDP without re-authenticating. In other words, the end user is seamlessly logged into any other RP that interoperates with the IDP. For privacy considerations, end users must take explicit actions to opt-in to SSO. In addition, SSO is in effect only for the duration of the end user's current browser session and authentication session.

Also available as XML or JSON