Security Considerations¶
In this section we describe some security considerations in the OIDC Federation scope.
Trust Marks as deterrent against abuses¶
The TM implementation and the filter on the TMs in the process of Federation Entity Discovery, turn out to be necessary against attacks aimed at the resource consumption. If an OP suffers an attack at the authorization endpoint and the attack consists of an high number of connections with fake client_id and authority_hints, then the OP, trying to find a path to the TA for establishing the trust with the requester, would produce several connections to third-party systems.
The OP MUST statically validate the TM or a-priori exclude the request whenever the TM is not present. In case the TM is not present or not valid, the procedure of Federation Entity Discovery MUST NOT be started and consequently MUST NOT create connections to third party systems.
Resolve endpoint¶
This endpoint MUST release the Metadata, the Trust Marks and the previously processed Trust Chain, and MUST NOT trigger a procedure of Federation Entity Discovery for each request arrival, unless this endpoint is secured with a client authentication mechanism, such as private_key_jwt [OIDC-CORE]. When using private_key_jwt the value in the sub parameter of the private_key_jwt MUST match the value sub in the request to the Resolve endpoint.
Best Practices¶
In this section we describe some best practices.
Specializing the OpenID Core and Federation public keys¶
It is a best practice to use public keys that are specialized for the two kinds of operations, Core and Federation.
Upgrading strategy of the OpenID Metadata¶
The interoperability among members works through the Metadata obtained from the Trust Chain calculation and preservation. This means that if an OP at the time T calculates the Trust Chain for an RP and this, at the time T+n, changes its own Metadata, the OP could consequently run into problems of validating the RP authorization requests, until the OP will have once again updated the RP-related Trust Chain.
A best practice to avoid service stops on the OIDC Core operations, is adding the new public keys inside the objects jwks without removing the previous values. Or, for example, the new redirect_uri.
In this way, after exceeding the maximum duration limit of the Trust Chain, defined in the claim exp and published in the TA Entity Configuration, it is certain that all the members have renewed their Trust Chain and it is possible, for the Leaf administrators, to remove the old definitions from the top of the list.