...
To make the examples clearer, parts of the XML not relevant to illustrating the problem, such as non-relevant element content and namespace declarations, will be omitted.
SAML Metadata Problem Example
This SAML metadata example illustrates the starting problematic case.
...
In the example above, entity https://www.example3.org does not contain a KeyName and may be impersonated by anyone with a certificate issued by one of the CA's enumerated by the KeyAuthority elements.
Mitigation Approaches
The best mitigation is to upgrade the IdP to version 2.4.4 or greater.
If upgrading the software is not possible, then there are several mitigation approaches: one involving disabling all PKIX trust engines and several involving editing and/or restructuring of the metadata.
Approach 1: Disable PKIX trust engines
This approach involves changing the IdP's configuration to disable use of PKIX trust engines. Do this ONLY if it is known that the IdP does not need to interact with any SP's whose trust is established based on the PKIX trust model, or if temporary loss of access to such SP's is acceptable.
...
Unless configuration reloading of relying-party.xml is enabled, the IdP will need to be restarted for this change to take effect.
Approach 2: Add KeyNames for all entities
This approach involves ensuring that all entities have at least one KeyName for every KeyDescriptor that they contain.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- The top-level entities group containing globally-scoped key authorities. -->
<md:EntitiesDescriptor name="allEntities">
<!-- All entities within this EntitiesDescriptor are within the scope of these key authorities. -->
<md:Extensions>
<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
</md:Extensions>
<!-- For clarity, other entities not shown. -->
<md:EntityDescriptor entityID="https://www.example1.org/sp"> ... </md:EntityDescriptor>
<md:EntityDescriptor entityID="https://www.example2.org/sp"> ... </md:EntityDescriptor>
<!-- This entity has a key specified by an X509Data element for use with the explicit key model.
A KeyName has been added and it is no longer vulnerable to this issue. -->
<md:EntityDescriptor entityID="https://www.example3.org/sp">
<md:SPSSODescriptor>
<md:KeyDescriptor>
<ds:KeyInfo>
<ds:KeyName>www.example3.org</ds:KeyName>
<ds:X509Data> ... </ds:X509Data>
</ds:KeyInfo>
</md:EntityDescriptor>
</md:EntitiesDescriptor> |
Approach 3: Split the metadata
This approach involves splitting the metadata source document into 2 distinct documents: 1) one containing the KeyAuthority elements and any entities which rely on the PKIX model 2) one containing no KeyAuthority elements and only entities which rely on the explicit key model only. A new metadata provider is then defined which consumes the new PKIX-only metadata source document.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- The top-level entities group containing globally-scoped key authorities. -->
<md:EntitiesDescriptor name="pkixEntities">
<!-- All entities within this EntitiesDescriptor are within the scope of these key authorities. -->
<md:Extensions>
<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
</md:Extensions>
<!-- This entity has only a KeyName and uses the PKIX trust model. -->
<md:EntityDescriptor entityID="https://www.example1.org/sp">
<md:SPSSODescriptor>
<md:KeyDescriptor>
<ds:KeyInfo>
<ds:KeyName>www.example1.org</ds:KeyName>
</ds:KeyInfo>
</md:KeyDescriptor>
</md:SPSSODescriptor>
</md:EntityDescriptor>
</md:EntitiesDescriptor> |
Approach 4: Move PKIX entities to a dedicated group
This approach involves moving the entities which rely on the PKIX trust model to a dedicated EntitiesDescriptor, along with the relevant KeyAuthority elements. This "scopes" the KeyAuthority elements so that they only apply to those entities which are descendents of their owning EntitiesDescriptor.
...
| Code Block | ||||
|---|---|---|---|---|
| ||||
<!-- The top-level entities group containing mixed entities. There are no global key authorities. -->
<md:EntitiesDescriptor name="allEntities">
<!-- This entity has a key specified by an X509Data element for use with the explicit key model.
It also has a KeyName. It is not vulnerable to this issue. -->
<md:EntityDescriptor entityID="https://www.example2.org/sp">
<md:SPSSODescriptor>
<md:KeyDescriptor>
<ds:KeyInfo>
<ds:KeyName>www.example2.org</ds:KeyName>
<ds:X509Data> ... </ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
</md:SPSSODescriptor>
</md:EntityDescriptor>
<!-- This entity has a key specified by an X509Data element for use with the explicit key model.
It does not have a KeyName but is no longer vulnerable to this issue. -->
<md:EntityDescriptor entityID="https://www.example3.org/sp">
<md:SPSSODescriptor>
<md:KeyDescriptor>
<ds:KeyInfo>
<ds:X509Data> ... </ds:X509Data>
</ds:KeyInfo>
</md:EntityDescriptor>
<!-- New entities group containing only entities which use the PKIX model, along with the relevant key authorities. -->
<md:EntitiesDescriptor name="pkixEntities">
<!-- All entities within this EntitiesDescriptor are within the scope of these key authorities. -->
<md:Extensions>
<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
<shibmd:KeyAuthority> ... </shibmd:KeyAuthority>
</md:Extensions>
<!-- This entity has only a KeyName and uses the PKIX trust model. -->
<md:EntityDescriptor entityID="https://www.example1.org/sp">
<md:SPSSODescriptor>
<md:KeyDescriptor>
<ds:KeyInfo>
<ds:KeyName>www.example1.org</ds:KeyName>
</ds:KeyInfo>
</md:KeyDescriptor>
</md:SPSSODescriptor>
</md:EntityDescriptor>
</md:EntitiesDescriptor>
</md:EntitiesDescriptor> |
Approach 5: Move KeyAuthority elements down to individual entities
This approach involves moving/copying the KeyAuthority extensions down to appear under each EntityDescriptor which uses the PKIX model.
...