Incorrect persistent NameID generation
When a SimpleSAMLphp Identity Provider is misconfigured, a bug in the software when trying to build a persistent
NameID to univocally identify the authenticating subject could cause different users to get the same identifier
generated, depending on the attributes available for them right after authentication.
Please note that even though this is possible thanks to a bug, an IdP must be misconfigured to release persistent
NameIDs even if it is not properly configured to generate them based on the specifics of the deployment.
NameIDs will typically be sent as part of the
Subject element of a SAML assertion, or as the contents of
eduPersonTargetedID attribute. Here is an example of such a
<NameID Format=“urn:oasis:names:tc:SAML:2.0:nameid-format:persistent“> zbonsm0Yn9Gnw14uQEEPr6AO7d+IvxwCQN3t+o24jYs= </NameID>
Some service providers will use this information to identify a user across sessions, because a persistent
never change for a given user. This could lead to different users accessing the same account in those service providers.
In order to be affected by this issue, the following circumstances must concur:
- SimpleSAMLphp acts as an identity provider.
- The service provider asking for authentication requests a persistent
saml:PersistentNameIDauthentication processing filter is configured (neither for the whole IdP, nor for a given SP).
simplesaml.nameidattributeconfiguration option is set (neither for the whole IdP, nor for a given SP).
- One of the following alternatives:
userid.attributeconfiguration option is set and the users don’t have an
eduPersonPrincipalNameattribute in the users backend, or
userid.attributeconfiguration option is set to an empty or missing attribute.
If all these requirements are met, the
SimpleSAML_Auth_ProcessingChain class will try to keep a unique user identifier
in the state array (
addUserID() method). Bear in mind that this code is executed before all the authentication
processing filters configured, meaning that only those attributes retrieved for the user during initial
authentication will be available. If no
userid.attribute configuration option is set, the default
eduPersonPrincipalName will then be used. However, since it is missing, no identifier will be kept. Alternatively, if
userid.attribute is set to a missing or empty attribute, the
addUserID() method will abort trying to register an
After executing all authentication processing filters, SimpleSAMLphp will build a SAML assertion. If the service
provider requests persistent
NameIDs, SimpleSAMLphp will attempt to generate one given that none is already
available (because the
saml:PersistentNameID filter was not used). At this point, the code will look for the
simplesaml.nameidattribute configuration option in either the local IdP metadata or in the remote SP metadata. If
none of them are configured, it will default to the unique user identifier previously registered by
SimpleSAML_Auth_ProcessingChain. If no identifier was kept there, the code will log an error message:
Unable to generate NameID. Check the userid.attribute option.
However, instead of aborting the
NameID generation at that point, it will go on and use a value missing from the
state array as the source for the computation, meaning the
null type will be used. Hence, all users connecting to a
given service provider will get the same
NameID generated, because all the input parameters will be the same:
- The SP’s entity identifier.
- The IdP’s entity identifier.
- The common secret salt from the main configuration.
All SimpleSAMLphp versions between 1.7.0 and 1.14.10, inclusive.
Those identity providers affected by this bug and misconfigured as previously described could be issuing SAML assertions
NameIDs for all or a subset of their users. If a service provider uses those
NameIDs to identify the
users of the affected IdP, all the users will be associated with the same user account at the service provider,
causing all sorts of potential security issues like information disclosure or unauthorized access.
While we can consider this unlikely to happen, some cases have been already observed. In particular, some identity providers using default configurations and consuming metadata automatically (i.e. using the metarefresh module) while using a user backend like Active Directory that does not populate eduPersonPrincipalName are particularly sensitive to this issue.
Upgrade to the latest version.
saml:PersistentNameID authentication processing filter
according to your needs. Remember to check that the attribute used as the source for the
NameID is present at
the moment the
saml:PersistentNameID filter is executed. The attribute used must be unique per user, and must
not change over time.