SSCP Access Controls Practice Question

A software company wants outside contractors to reach a single internal source code repository without creating accounts in the company directory. The identity team proposes using the Security Assertion Markup Language so that contractors authenticate against their own employer's identity provider. Which statement describes the trust relationship that must exist for this to work?

⚠ Common exam trap

The trap here is assuming federation requires local accounts or shared directories, when it actually depends on a configured trust in the partner's signed assertions.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The company's service provider must trust assertions signed by the contractor's identity provider.

Federated authentication succeeds only when the relying party trusts the assertions issued by the partner identity provider, typically established by exchanging metadata and trusting the provider's signing certificate. Once that trust exists, contractors authenticate at their own employer and the repository consumes the signed assertion, so no local accounts are needed. This design keeps user lifecycle management with the employer while giving the company a verifiable basis for granting access.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Both organizations must share a single directory database that is replicated between their networks.
Why it's wrong here
Federation operates through exchanged metadata and signed assertions, not through shared or replicated directory databases. Replicating a directory across organizational boundaries would create serious security, privacy, and operational problems, and it is not how the standard works. The trust is cryptographic and contractual, allowing each party to retain control of its own user store.
✓
The company's service provider must trust assertions signed by the contractor's identity provider.
Why this is correct
In a Security Assertion Markup Language exchange, the relying party accepts authentication statements only if it trusts the issuing authority. The company's repository acts as the service provider, and the contractor's employer acts as the identity provider, so a configured trust with the provider's signing certificate is mandatory. Without that trust relationship, the repository would treat incoming assertions as untrusted and deny access regardless of the contractor's credentials.
✗
The contractor's identity provider must create shadow accounts for each user in the company directory.
Why it's wrong here
The stated goal is to avoid creating accounts in the company directory, and the whole point of federated authentication is to eliminate that duplication. The identity provider issues assertions about users it already manages, and the service provider consumes them without provisioning local identities. Requiring shadow accounts would reintroduce the administrative burden and lifecycle risk the company is trying to eliminate.
✗
The repository must issue a client certificate to each contractor before any assertion is accepted.
Why it's wrong here
Client certificates are a separate authentication mechanism and are not required for assertion-based federation, which relies on signed messages and established trust metadata. Requiring individual certificates for every contractor would recreate the provisioning overhead the company wants to avoid. The trust decision is made by validating the identity provider's signature, not by verifying a per-user certificate on the repository side.

Go deeper

SSCP Access Controls Practice Question

Why each option matters

Option-by-option breakdown

Related to this question