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…
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)- A9% (3)
- B3% (1)
- C74% (26)
- D14% (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
Community Discussion
No community discussion yet for this question.