Hard commit for including this fix in 11.0.4, hopefully will fit into 12.0.1 as well.

The IdP side of the fix:

• A new setting has been created on the IdP side called "idpDisableNameIDPersistence", this new setting should disable the storage of the NameID values for all NameIDs issued by that IdP instance, as long as the NameID-Format is not "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent".
• The SP's existing "spDoNotWriteFederationInfo" setting has been repurposed: it no longer is specific to unspecified NameID-Formats, instead it will affect all non-persistent NameID-Formats similarly to the idpDisableNameIDPersistence setting in the IdP configuration.
• The NameID lookup mechanism has been modified so that it now only tries to look up existing NameID values for the user, if the NameID is actually persisted for the corresponding NameID-Format.
• The IDPAccountMapper interface has been extended with the following new method:

      /**
       * Tells whether the provided NameID-Format should be persisted in the user data store or not.
       *
       * @param realm The hosted IdP's realm.
       * @param hostEntityID The hosted IdP's entityID.
       * @param remoteEntityID The remote SP's entityID.
       * @param nameIDFormat The non-transient, non-persistent NameID-Format in question.
       * @return <code>true</code> if the provided NameID-Format should be persisted in the user data store,
       * <code>false</code> otherwise.
       */
      public boolean shouldPersistNameIDFormat(String realm, String hostEntityID, String remoteEntityID,
              String nameIDFormat);
  

  The default implementation of shouldPersistNameIDFormat in DefaultIDPAccountMapper first checks whether idpDisableNameIDPersistence is enabled in the hosted IdP configuration. If it's disabled, the logic will advance and have a look at the remote SP's "spDoNotWriteFederationInfo" as well.

The surrounding logic around NameID persistence can be summed up now with the following:

• persistent NameID -> The NameID MUST be stored
• transient NameID -> The NameID MUST NOT be stored
• ignored user profile mode -> The NameID CANNOT be stored (-> fails for persistent)
• for any other cases -> The NameID MAY be stored based on customizable logic

The SP side of the fix:

• Modified the contract for SPAccountMapper: it no longer needs to perform the reverse lookup based on the received NameID value, instead SPACSUtils now handles that if and when the NameID-Format should be persisted. This was done to ensure that NameID values are only persisted in the data store if it wasn't persisted already.
• The SP's existing "spDoNotWriteFederationInfo" setting has been repurposed: it no longer is specific to unspecified NameID-Formats, instead it will affect all non-persistent NameID-Formats.
• The SPAccountMapper interface has been extended with the following new method:

  /**
   * Tells whether the provided NameID-Format should be persisted in the user data store or not.
   *
   * @param realm The hosted SP's realm.
   * @param hostEntityID The hosted SP's entityID.
   * @param remoteEntityID The remote IdP's entityID.
   * @param nameIDFormat The non-transient, non-persistent NameID-Format in question.
   * @return <code>true</code> if the provided NameID-Format should be persisted in the user data store,
   * <code>false</code> otherwise.
   */
  public boolean shouldPersistNameIDFormat(String realm, String hostEntityID, String remoteEntityID,
          String nameIDFormat);
  

  The default implementation of shouldPersistNameIDFormat in DefaultLibrarySPAccountMapper checks whether spDoNotWriteFederationInfo in the hosted SP configuration has been enabled.

Fixed with R13887&R13888 R13889&R13890 and R13891&R13892