NIEF Simple Federation Assurance Profile for Identity Providers, v1.0
NIEF federation assurance profile for identity provider (IDP) systems. Derived from NIST Special Publication 800-63C requirements, excluding security controls. Intended for use in conjunction with appropriate NIEF profiles for security controls.
Identifier | https://trustmark.nief.org/tpat/tips/nief-simple-federation-assurance-profile-for-identity-providers/1.0/ | ||||
Publication Date | 2021-08-28 | ||||
Issuing Organization |
NIEF (https://nief.org/)
View Contact
|
||||
Keywords | NIEF, Federation Assurance, IDP, Identity Provider | ||||
Legal Notice | This artifact is published by the National Identity Exchange Federation (NIEF). This artifact and the information contained herein is provided on an "AS IS" basis, and NIEF 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, NIEF disclaims legal liability for any loss incurred as a result of the use or reliance on the document or the information contained herein. |
Loading...
Trust Expression:
TD_ref1 and (TD_ref2 or TD_ref3 or TD_ref4) and TD_ref5 and TD_ref6 and TD_ref7 and TD_ref8 and TD_ref9 and (TD_ref10 or (TD_ref11 and TD_ref12)) and (TD_ref13 or TD_ref14) and TD_ref15 and TD_ref16 and TD_ref17 and TD_ref18 and TD_ref19 and TD_ref20 and TD_ref21 and TD_ref22 and TD_ref23 and (TD_ref24 or TD_ref25) and TD_ref26 and TD_ref27 and (TD_ref28 or TD_ref29) and TD_ref30 and (TD_ref31 or (not contains(TD_ref30.fals_supported,"FAL2") and not contains(TD_ref30.fals_supported,"FAL3")))
References (31)
TD Federation - Protection of Assertion Signing and Encryption Keys as Per FIPS 140 Level 1 Where Required, v1.0 | |
---|---|
Description | Identity Providers must protect their assertion signing and encryption keys appropriately. This requires the use of FIPS 140 Level 1 for some AALs. |
ID | TD_ref1 |
Provider Reference |
TD Federation - Authorization of RPs via Whitelist, v1.0 | |
---|---|
Description | Identity Providers may establish a set of trusted RPs via a whitelist as long as the trusted RPs adhere to defined federation requirements. |
ID | TD_ref2 |
Provider Reference |
TD Federation - Authorization of RPs via Blacklist, v1.0 | |
---|---|
Description | Identity Providers may establish a set of RPs via a blacklist with whom they do not interoperate. |
ID | TD_ref3 |
Provider Reference |
TD Federation - Authorization of RPs via Runtime Decision by an Authorized Party, v1.0 | |
---|---|
Description | Identity Providers may allow authorized parties (usually a subscriber) to establish trust with an RP of their choosing at runtime. |
ID | TD_ref4 |
Provider Reference |
TD Federation - Limitations on IdP Transmission of Subscriber Information to RPs, v1.0 | |
---|---|
Description | Identity Providers shall not disclose subscriber information to RPs outside of well defined purposes, such federated authentication, related fraud mitigation, to comply with law or legal process, notification of security issues, or in the case of a specific user request, to transmit the information. |
ID | TD_ref5 |
Provider Reference |
TD Federation - Masking of Sensitive Information for Subscriber Privacy, v1.0 | |
---|---|
Description | Identity Providers must by default mask sensitive data (e.g. passwords) displayed to the subscriber, although it SHALL allow users to unmask such values if they subscriber so chooses. |
ID | TD_ref6 |
Provider Reference |
TD Federation - Redress of Subscriber Complaints or Problems, v1.0 | |
---|---|
Description | Identity Providers must have an effective mechanism for subscribers to report problems or complaints. |
ID | TD_ref7 |
Provider Reference |
TD Federation - Explicit Notice and Confirmation by Subscriber Prior to Attribute Release, v1.0 | |
---|---|
Description | Identity Providers must provide subscribers explicit notice and request confirmation prior to transmitting attributes to an RP. If possible, it should allow subscribers to selectively control the transmission of individual attributes. |
ID | TD_ref8 |
Provider Reference |
TD Federation - Secure Exchange of Cryptographic Keys During IdP-RP Registration, v1.0 | |
---|---|
Description | During federation registration events for IdPs and RPs, all key exchanges must be done using a secure method. If any symmetric keys are used, they must be unique for each IdP/RP pair. |
ID | TD_ref9 |
Provider Reference |
TD Federation - Acceptance of RP Registration Only via Manual Processes, v1.0 | |
---|---|
Description | Identity Providers that exclusively register Relying Parties manually must be sure to exchange all key material required for the trusted relationship in a secure fashion. |
ID | TD_ref10 |
Provider Reference |
TD Federation - Minimization of Dynamic Registration System Administrator Involvement, v1.0 | |
---|---|
Description | Identity Providers that support dynamic registration must make their configuration information available in a way that minimizes administrator involvement (such as dynamic registration endpoints). |
ID | TD_ref11 |
Provider Reference |
TD Federation - Support for Runtime Decisions on Release of Subscriber Information to Dynamically Registered RPs, v1.0 | |
---|---|
Description | Identity Providers that support dynamically registered RPs must allow subscribers to authorize these RPs before releasing user information to them. |
ID | TD_ref12 |
Provider Reference |
TD Federation - Privacy Analysis and Privacy Impact Assessment, v1.0 | |
---|---|
Description | Agencies engaging in federated activities must undergo a thorough privacy analysis and impact assessment publishing the results. |
ID | TD_ref13 |
Provider Reference |
TD Bona Fide Non-US Federal Government Agency or Organization, v1.0 | |
---|---|
Description | Used to demonstrate that an agency or organization is NOT part of the United States federal government, and therefore is not subject to certain rules and regulations that pertain to U.S. federal agencies. |
ID | TD_ref14 |
Provider Reference |
TD Federation - Communication of Authentication Event Time to RP, v1.0 | |
---|---|
Description | Identity Providers must send RPs information about the last time the subscriber authenticated to the IdP when engaging in federated login, this is particularly important if the IdP supports long-term sessions. |
ID | TD_ref15 |
Provider Reference |
TD Federation - No Assumption of Propagated Termination of Subscriber Sessions, v1.0 | |
---|---|
Description | Identity Providers must not rely on RPs to terminate subscriber sessions when the IdP terminates the subscriber session. It must not rely on such functionality for any security requirement. |
ID | TD_ref16 |
Provider Reference |
TD Federation - Baseline Assertion Metadata Requirements, v1.0 | |
---|---|
Description | Identity Providers must include ensure all assertions generated are unique and include fundamental metadata including, subject identifier, issuer identifier, audience, timestamps, a digital signature, and authentication time. |
ID | TD_ref17 |
Provider Reference |
TD Federation - No Use of Assertion Lifetime to Limit Length of Subscriber Session with RP, v1.0 | |
---|---|
Description | Identity Providers must generate all assertions with short lifetimes (minimize time between issuance and expiration time) to minimize the risk of replay attacks. |
ID | TD_ref18 |
Provider Reference |
TD Federation - Uniqueness of Assertion Identifier, v1.0 | |
---|---|
Description | All assertions must be uniquely identifiable, this may be accomplished using unique identifiers, nonces, and timestamps. |
ID | TD_ref19 |
Provider Reference |
TD Federation - Protection of Assertion Integrity via Digital Signature Using Approved Cryptography, v1.0 | |
---|---|
Description | All assertions must be digitally signed using approved cryptography. The entire assertion including all metadata must be signed. |
ID | TD_ref20 |
Provider Reference |
TD Federation - Use of Assertion Audience Restriction, v1.0 | |
---|---|
Description | All assertions must include audience restrictions so that RPs are able to verify they are an intended recipient of the assertion. |
ID | TD_ref21 |
Provider Reference |
TD Federation - Generation and Use of Pairwise Pseudonymous Identifiers, v1.0 | |
---|---|
Description | All pairwise pseudonymous subject identifiers must be opaque and should be uniquely issued for RPs. In the rare case where there is a legitimate need for shared pairwise pseudonymous identifiers, an IdP must take precautions to avoid the additional risk of fraud. |
ID | TD_ref22 |
Provider Reference |
TD Federation - Minimization of Attributes Transmitted, v1.0 | |
---|---|
Description | Identity Providers must only transmit attributes that are explicitly requested by RPs. |
ID | TD_ref23 |
Provider Reference |
TD Federation - No Support for Back-Channel Assertion Presentation with Assertion References, v1.0 | |
---|---|
Description | Identity Providers that do not allow direct RP to IdP communication must not use assertion references. |
ID | TD_ref24 |
Provider Reference |
TD Federation - Protection Against Tampering, Fabrication, and Unintended Use of Assertion References, v1.0 | |
---|---|
Description | Identity Providers that use assertion references (e.g. SAML Artifact Profile or OIDC) must protect assertion references and verify that when the reference is presented back to the IdP that the RP presenting it was the RP that was issued the reference (most typically by authenticating the RP). |
ID | TD_ref25 |
Provider Reference |
TD Federation - Use of Authenticated Protected Channels, v1.0 | |
---|---|
Description | Authenticated and Protected Channels will be used for all communication between the IdP, Subscriber, and RP. |
ID | TD_ref26 |
Provider Reference |
TD Federation - Support for Generation of Attribute References in Assertions, v1.0 | |
---|---|
Description | Identity Providers will support attribute references where feasible. Attribute references can be used to minimize revealing PII in cases where an RP only needs to broad issues, for example is the user over 18 as opposed to requesting the user's birthdate. |
ID | TD_ref27 |
Provider Reference |
TD Federation - Support for Generation of Bearer Assertions Only, v1.0 | |
---|---|
Description | Identity Providers supporting lower assurance levels need to support bearer assertions for federated login. |
ID | TD_ref28 |
Provider Reference |
TD Federation - Proper Generation of Holder-of-Key Assertions, v1.0 | |
---|---|
Description | Identity Providers operating at higher assurance levels must support holder of key assertions, which must not include an unencrypted private or symmetric key to be used with holder-of-key presentation |
ID | TD_ref29 |
Provider Reference |
TD Federation - Support for NIST SP 800-63C FALs, v1.0 | |
---|---|
Description | Identity Providers SHALL only operate at FALs for which they have demonstrated the ability to operate at appropriately. |
ID | TD_ref30 |
Provider Reference |
TD Federation - Protection of Assertion Confidentiality via Assertion Encryption, v1.0 | |
---|---|
Description | Identity Providers must encrypt assertions using approved cryptography. |
ID | TD_ref31 |
Provider Reference |
Sources (2)
NIEF | National Identity Exchange Federation |
NIST SP 800-63C | NIST Special Publication 800-63C, Digital Identity Guidelines: Federation and Assertions. June 2017. Available at https://doi.org/10.6028/NIST.SP.800-63c. |