FICAM SAML Metadata Import and Consumption, v1.0

This Trustmark Definition defines the conformance and assessment criteria for Security Assertion Markup Language (SAML) Metadata Import and Consumption based on the Federal Identity, Credential, and Access Management (FICAM) SAML 2.0 Web Browser Single Sign-On (SSO) Profile Version 1.0.2, December 16, 2011.

Assessment Steps (10)

1
Metadata-Import-Local-Step (Metadata_Import_Local_Step)

Does the implementation import metadata from a local file obtained out of band?

Artifact
Metadata-Import-Local

Provide evidence (policies, procedures, etc.) that metadata is imported from file(s) obtained out of band.

2
Metadata-Import-Remote-Step (Metadata_Import_Remote_Step)

Does the implementation import metadata via a remote resource at a fixed location accessible via HTTP 1.1 over TLS 1.1 (and higher)?

Artifact
Metadata-Import-Remote

Provide evidence (policies, procedures, etc.) that metadata is imported from a remote resource at a fixed location (provide URL(s)) and that only HTTP connections over TLS 1.1 or higher are used.

3
XML-Signature-Verification-Step (XML_Signature_Verification_Step)

Do metadata consumers perform XML-signature verification at the root element level at consumption time?

Artifact
XML-Signature-Verification

Provide evidence (policies, procedures, code design documents etc.) that XML signature verification is performed at the root element level at consumption time.

4
Key-Trust-Direct-Step (Key_Trust_Direct_Step)

Do metadata consumers establish signature key trust at consumption time by direct comparison against preconfigured keys?

Artifact
Key-Trust-Direct

Provide evidence (policies, procedures, etc.) that consumers establish signature key trust by direct comparison against preconfigured keys at consumption time.

5
Key-Trust-Certificate-Based-Step (Key_Trust_Certificate_Based_Step)

Do metadata consumers establish signature key trust at consumption time via path-based certificate validation against one or more trusted root certificates?

Artifact
Key-Trust-Certificate-Based

Provide evidence (policies, procedures, code design documents, etc.) that consumers establish signature key trust via path-based certificate validation against one or more trusted root certificates.

6
CRL-Certificate-Checking-Step (CRL_Certificate_Checking_Step)

If root certificates are used for establishing key signature trust, is a certificate revocation list (CRL) used to ensure the certificate(s) validity?

Artifact
CRL-Certificate-Checking

Provide evidence (policies, procedures, code design documents, etc.) that a CRL is used to ensure certificates are valid.

7
OCSP-Certificate-Checking-Step (OCSP_Certificate_Checking_Step)

If root certificates are used for establishing key signature trust, is an online certificate status protocol (OCSP) responder consulted to ensure the certificate(s) validity?

Artifact
OCSP-Certificate-Checking

Provide evidence (policies, procedures, code design documents, etc.) that OCSP is used to ensure certificates are valid.

8
validuntil-Honored-Step (Valid_Until_Honored_Step)

Are validuntil attributes in both <md:EntityDescriptor> and <md:EntitiesDescriptor> elements honored?

Artifact
validuntil-Honored

Provide evidence (policies, procedures, code design documents, etc.) that validuntil attributes are honored in both <md:EntityDescriptor> and <md:EntitiesDescriptor> elements.

9
Refresh-Before-Expiration-Step (Refresh_Before_Expiration_Step)

Does the organization refresh metadata before it expires?

Artifact
Refresh-Before-Expiration

Provide evidence (policies, procedures, etc.) that metadata is refreshed before it expires.

10
Expired-Metadata-Risk-Decision-Step (Expired_Metadata_Risk_Decision_Step)

Does the organization make a risk-based decision whether or not to continue transacting with entities affected by expired metadata?

Artifact
Expired-Metadata-Handling

Provide evidence (policies, procedures, etc.) the organization makes risk-based decisions whether or not to continue transacting with entities affected by expired metadata.

Conformance Criteria (6)

Metadata-Import

Implementations MUST import metadata from a local file obtained out of band or via a remote resource at a fixed location accessible via HTTP 1.1 over TLS 1.1 (and higher).

Citations
FICAM-SAML-SSO
Section 3.3.3 Metadata Consumption
FICAM-SAML-SSO-REQS
Section 2.1.1 RP and CSP/TM Metadata Consumption Tests
XML-Signature-Verification

At consumption time, metadata consumers MUST perform XML-signature verification at the root element level.

Citations
FICAM-SAML-SSO-REQS
Section 2.1.1 RP and CSP/TM Metadata Consumption Tests
FICAM-SAML-SSO
Section 3.3.3 Metadata Consumption
Signature-Key-Trust

At consumption time, the metadata consumer MUST establish signature key trust by direct comparison against preconfigured keys or via path-based certificate validation against one or more trusted root certificates combined with either certificate revocation list (CRL) or OSCP.

Citations
FICAM-SAML-SSO-REQS
Section 2.1.1 RP and CSP/TM Metadata Consumption Tests
FICAM-SAML-SSO
Section 3.3.3 Metadata Consumption
validuntil-attribute

Implementations MUST honor the validuntil attribute in an <md:EntityDescriptor> or <md:EntitiesDescriptor>.

Citations
FICAM-SAML-SSO
Section 3.3.3 Metadata Consumption
FICAM-SAML-SSO-REQS
Section 2.1.1 RP and CSP/TM Metadata Consumption Tests
Refresh-before-expiration

Implementations MUST refresh metadata before it is expired.

Citations
FICAM-SAML-SSO
Section 3.3.3 Metadata Consumption
FICAM-SAML-SSO-REQS
Section 2.1.1 RP and CSP/TM Metadata Consumption Tests
Risk-based-determination-of-expired-metadata

The organization MUST make a risk-based determination whether or not to continue transacting with the affected entities if for some reason the metadata cannot be refreshed before it expires.

Citations
FICAM-SAML-SSO-REQS
Section 2.1.1 RP and CSP/TM Metadata Consumption Tests
FICAM-SAML-SSO
Section 3.3.3 Metadata Consumption

Metadata

Publication Date 2017-05-18
Trustmark Reference Attribute https://artifacts.trustmarkinitiative.org/lib/trustmark-definitions/ficam-saml-metadata-import-and-consumption/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, SAML Metadata, Trust Fabric, Automated Trust, Digitally Signed XML, Interoperability,
Supersedes
Issuance Criteria
( ( yes(Metadata_Import_Local_Step) OR yes(Metadata_Import_Remote_Step) ) AND yes(XML_Signature_Verification_Step) AND ( yes(Key_Trust_Direct_Step) OR ( yes(Key_Trust_Certificate_Based_Step) AND ( yes(CRL_Certificate_Checking_Step) OR yes(OCSP_Certificate_Checking_Step) ) ) ) AND yes(Valid_Until_Honored_Step) AND yes(Refresh_Before_Expiration_Step) AND yes(Expired_Metadata_Risk_Decision_Step) )
Assessment Step Preface

Assessment Steps

Target Stakeholder Organizations and relying parties interested in FICAM standards.
Target Recipient Organizations that desire to provide and/or consume services compliant with FICAM.
Target Relying Party Relying parties interested in compliance with FICAM standards.
Target Provider Trustmark Providers evaluating organizations for overall FICAM compliance.
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 (2)

Terms (25)

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.

Approved

Acceptance by ICAM to technically interoperate with other ICAM members.

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

Multiple <b><md:EntityDescriptor></b> or <b><md:EntitiesDescriptor><b> files into a single <md:EntitiesDescriptor> file.

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. In this 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.

NIEF

National Identity Exchange Federation.

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. SSO applies to assertion based ICAM member systems only. In addition, SSO is in effect only for the duration of the end user's current browser session and authentication session. An end user must opt-in to SSO each time he or she opens a new web browser session.

Also available as XML or JSON