[OPENAM-3470] The SAML2 nameid should not be persisted if the nameid-format is not persistent Created: 18/Dec/13  Updated: 05/Mar/19  Resolved: 20/May/15

Status: Resolved
Project: OpenAM
Component/s: SAML
Affects Version/s: 11.0.0
Fix Version/s: 11.0.4, 12.0.3, 13.0.0

Type: Bug Priority: Major
Reporter: Zoltan Tarcsay Assignee: Peter Major [X] (Inactive)
Resolution: Fixed Votes: 2
Labels: EDISON, release-notes, test-candidate
Remaining Estimate: 0h
Time Spent: 31h
Original Estimate: 2h

Issue Links:
Depends
is required by OPENIG-3525 SamlFederationHandler should support ... Closed
Relates
relates to OPENAM-5986 SPACSUtils incorrectly determines Ign... Resolved
relates to OPENAM-6021 Document API & behavior changes intro... Resolved
relates to OPENAM-5160 Fedlet support non-transient (persist... Closed
Target Version/s:
Sprint: Sprint 81 - Sustaining, Sprint 82 - Sustaining
Support Ticket IDs:

 Description   

The SAML2 nameid gets persisted whenever the nameid-format is not transient. This has undesired side effects, such as when the nameid-format is emailAddress (mapped to the mail attribute for instance) and a user's email address changes, but the persisted sun-fm-saml2-nameid-infokey value will still contain the old value of mail.



 Comments   
Comment by Peter Major [X] (Inactive) [ 29/Jan/15 ]

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

Comment by Peter Major [X] (Inactive) [ 13/May/15 ]

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
Comment by Peter Major [X] (Inactive) [ 14/May/15 ]

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.

Comment by Peter Major [X] (Inactive) [ 20/May/15 ]

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

Generated at Mon Oct 19 16:17:19 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.