nerdexam
F5

304 · Question #49

To configure BIG-IP APM as a Service Provider (SP) with an external vendor IdP, what information is typically exchanged between the two systems to establish trust?

The correct answer is C. Metadata containing SP and IdP configuration details. Exchanging metadata is the standard mechanism for establishing SAML federation trust between an SP (BIG-IP APM) and an IdP. Metadata files are XML documents that contain each system's entity ID, endpoint URLs, supported bindings, and public signing/encryption certificates…

Section 1: Implement APM for Access

Question

To configure BIG-IP APM as a Service Provider (SP) with an external vendor IdP, what information is typically exchanged between the two systems to establish trust?

Options

  • AA shared secret for encrypting SSO requests and responses.
  • BAn SSL certificate for secure communication between SP and IdP.
  • CMetadata containing SP and IdP configuration details.
  • DA session token for maintaining user state during the SSO process.

How the community answered

(35 responses)
  • A
    9% (3)
  • B
    3% (1)
  • C
    74% (26)
  • D
    14% (5)

Explanation

Exchanging metadata is the standard mechanism for establishing SAML federation trust between an SP (BIG-IP APM) and an IdP. Metadata files are XML documents that contain each system's entity ID, endpoint URLs, supported bindings, and public signing/encryption certificates - everything the other party needs to recognize and communicate securely with it. Each side imports the other's metadata, which is why it's a bilateral exchange.

Why the distractors are wrong:

  • A (shared secret): SAML doesn't use shared secrets for SSO - it uses asymmetric key pairs (public/private certificates) embedded in the metadata, not a pre-shared symmetric secret.
  • B (SSL certificate alone): TLS certificates secure the transport layer (HTTPS), but they don't convey the SAML-specific configuration details (entity IDs, SSO endpoints, etc.) needed for federation trust. Certificates are included inside the metadata, making this partially true but incomplete.
  • D (session token): Session tokens are generated after trust is established and a user authenticates - they're an artifact of an active SSO session, not part of the initial trust setup.

Memory tip: Think of metadata as a "business card exchange" - before two systems can do business (SSO), they swap cards (metadata) so each knows who the other is, where to reach them, and how to verify their signature.

Topics

#SAML Federation#IdP Configuration#Metadata Exchange#Trust Establishment

Community Discussion

No community discussion yet for this question.

Full 304 Practice