Validation of SAD JWT:s will not work if a Proxy-IdP is used.

[martin-lindstrom]

The SAD specified in Signature Activation Protocol for Federated Signing is supposed to be verified by the recipient (i.e., an Signature Service). The Signature Service does that by performing the following steps:

1. Verify that JWT signature by using the IdP signature certificate(s) found in its metadata entry.
2. Assert that the aud (audience) claim equals the SAML entityID of the Signature Service.
3. Assert that the iss (issuer) contains the entityID of the issuing IdP.
4. Validate that the SAD has not expired by checking the exp and iat claims.
5. Assert that the irt (in response to) extension claim holds the ID of the AuthnRequest containing the SADRequest that the Signature Service sent to the IdP.
6. Assert that the ID of the reqid corresponds to the ID of the SignRequest that led to this communication.
7. Assert that the user-ID in the SAD (sub and attr) matches an attribute from the received Assertion.
8. Assert that the value of the loa claim matches what was received in the Assertion.

Suppose that the Signature Service communicates with a Proxy Service, P, that proxies the request to an IdP, X, that performs the user authentication, displaying of SignMessage and issuance of the SAD. The Proxy, P, will when it receives the SAML response from the IdP, create a new Assertion, include attributes issued from P, sign it with its own key and return the response to the Signature Service.

Now. Since the SAD attribute is proxied, the Signature Service will run into problems when verifying the SAD.

• Check number 1 will fail since the Signature Service will use the Proxy IdP's certificate(s) when verifying the signature. This will of course not work.
• Check number 2 will fail since the X IdP will set the aud claim to the entityID of the requester, which is the Proxy IdP.
• Check number 3 will fail since it will contain the entityID of IdP X. The Signature Service will assume that it is IdP P.
• Check number 5 will fail since the Proxy IdP created a new AuthnRequest (with another ID) when communicating with the X IdP.
• Check number 7 may fail if the Proxy IdP does not send this attribute back in its response.
• The LoA-check (8) may also fail if the X IdP and Proxy IdP works under different profiles.

[martin-lindstrom]

Possible solutions?

The first one is obvious, but probably not acceptable. We restrict the usage of SAD:s by banning Proxy-IdP solutions from supporting SADRequest messages.

Next. Can we require that Signature Service to obtain the metadata from the "real" IdP that issued the SAD? And if so, it should be able to verify the signature. But we don't even now if they are in the same federation, so this is not probably the way to go. Furthermore, it will not aid the Signature Service is succeeding with the other checks.

What if we require Proxy-IdP:s wanting to support the SAD/SAP specification to issue a proxy-SAD?

If the Proxy-IdP promises to verify a received SAD (the 8 checks above), it should be able to wrap the original SAD into a Proxy-SAD which can be verified by the Signature Service. The original SAD would still be there for proof. We would need to add an extra field to the seElnSadext claim - proxiedSad.

[Razumain]

SAD verification is done is a tamper resistent environment. It is therefore important that the SAD itself is simple and can be validate using fairly simple process.

I suggest a small change to the specification.

1. Add a request ID to the SAD request (SRID).
2. Change the "irt" parameter of the SAD to contain the SRID instead of the Authn Request ID.

If a proxy is used, the original SAD request is also proxied to the upstream IdP, preserving the SRID.

Add a new "Proxy section" stating that:

1. A proxy IdP may also proxy data that is useful to validate a SAD from an upstream IdP, such as the certificate for the SAD issuer as well as necessary information about attribute and LoA mapping between federations.
2. Providing such proxy information described in step 1 is currently outside the scope of this specification.

With these changes, all of the validation steps will pass even if proxy is used.

[Razumain]

Update after discussion today:

• In addition to the proposal above: Add new request param in SAD request expressing the ID of the requesting signing service.
• The current SAD parameter aud will contain the id of the requesting signing service
• Also add a simple way to proxy the SAD signing certificate from upstream IdP proving the SAD.