[OPENIG-409] Fedlet should support nameid-format:persistent Created: 01/Dec/14  Updated: 05/Mar/19  Resolved: 19/Mar/18

Status: Resolved
Project: Identity Gateway
Component/s: SAML
Affects Version/s: 2.1.0, 3.0.0
Fix Version/s: Not Applicable

Type: Improvement Priority: Major
Reporter: Steven Jarosz Assignee: Unassigned
Resolution: Expired Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


Issue Links:
relates to OPENAM-5160 Fedlet support non-transient (persist... Closed
relates to OPENIG-3525 SamlFederationHandler should support ... Closed


This issue is being opened regarding customers who may want to use Fedlet for configurations that do not allow transient and demand on persistent for nameID:format. This issue is more important for OpenIG where OpenIG implements Fedlet and supports IDPs other than OpenAM, but the same holds true for OpenAM IDPs that choose not to implement Transient but want to enable Fedlets. For Fedlet's the notion of Persistent would need to be custom development for on the SP application and in the case of OpenIG, persistent may mean integration with some IDM system (which could be ForgeRock, but where OpenIG is the SP). Point is that the limitation of Transient only should be addressed.

I have noted that for OpenAM this fix involves a fix to the fedletSSOInit.jsp and for OpenIG for the FederationServlet.java. Both have a section that is similar to this:


Changing that to default to NAMEID_TRANSIENT if a URL parameter request override is not present. If parameter in URL then add parameter's nameID format to the list instead.

Once the SAML Authentication request is made and the IDP responds with Persistent, the next issue is that there exists no ID Mapper class. This issue can be resolved by user adding a custom account mapper class to the SAML metatdata and implementing that class.


<Attribute name="spAccountMapper">         

Because a return value of true for accountmapper is basically the same as an OpenAM IDP chosing ignore profile, then the logic of ignore persistent, but ability to request is accomplished.

This is a very plausible use-case especially IDP is out of control of the SP and IDP demands persistent even though from the SP perspective, persistent is not needed.

Comment by Steven Jarosz [ 01/Dec/14 ]

It should be noted that the custom account mapper is not requested as part of this RFE, but rather up to customer to implement the custom account mapper, if they want to take advantage of non-tranistent nameID

Comment by Mark de Reeper [ 01/Dec/14 ]

Another short term option is to update the SP extended metadata to enable this property:

        <Attribute name="useNameIDAsSPUserID">

This change will mean that if the user is not found in the user store (always returns null in Fedlet case) then trigger the default SP account mapper to use the NameID value from the IDP.

Comment by Ludovic Poitou [ 01/Dec/14 ]

Is there an issue opened in the OpenAM project ? The Fedlet is a module of OpenAM that is consumed by OpenIG.
Based on the description, it looks like to me that this issue requires new feature in the Fedlet, thus there should be a OpenAM issue for that and the OpenIG one should depend on it.

Comment by Steven Jarosz [ 01/Dec/14 ]

Mark. Great comment on the SP MetaData fix. I did not know that was an option. So, that fixes the need for a custom account mapper class, which is good. I am going to try that out for my case.

That means only the outgoing AuthN request needs to be enhanced to support requests other than transient.


Comment by Steven Jarosz [ 01/Dec/14 ]


I did also open a case for Fedlet on OpenAM OPENAM-5160

However the codebase is only shared to a point in that the Fedlet has a JSP and OpenIG has a functionally similar Servlet implementation. So, I think the issue needs to be addressed in both, but if there is a way to address consistently that would be better.

Comment by Matthew Swift [ 15/Dec/14 ]

Re-evaluate for 4.0.0

Comment by Steven Jarosz [ 31/Mar/15 ]

Currently working large opportunity that would require OpenIG to consume external IDP that must have NameID Persistent. This makes the current fedlet assumption of Transient go away. The fact that a persistent store is not a function of OpenIG is irrelevant as the end result of the OpenIG handler will integrate with systems that will provision. Can we look again at making these changes so the authentication request can support persistent and the return mapping is handled rather than bombs? Thanks

Comment by Hodari McClain [X] (Inactive) [ 18/Dec/15 ]

Thanks for pushing this Steve. We could use this. Workaround in the meantime.

Comment by Mark de Reeper [ 31/Mar/16 ]

The change in OPENIG-509 to make use of more recent OpenAM federation libraries opens the door to making use of OPENAM-3470 which allows for flexibility around disabling persistence. This means that we could at least allow the NameID format to be overridden by a parameter and falling back to transient if it is not specified.

This still does not solve the case where NameID format is persistent since there is no local storage available to store the linkage.

Comment by Steven Jarosz [ 01/Apr/16 ]

Agree, in the context of OpenIG that persistance cannot be handled by OpenIG, however there are deployment scenarios where OpenIG consumes the SAML with a persistence directive. OpenIG should not reject assuming there exists a down-stream WAM and/or provisioning process that handles the RelayState.

Think an OpenIG handled SAML request that then passes in header the user to a third-party WAM product that has an OpenAM like feature that performs Dynamic Profile creation, or RelayState app(OpenIDM or third-party) wants to perform a provisioning request to OpenAM's OpenDJ instance.

Currently the assumption is to reject persistent because OpenIG by (or even legacy fedlet) cannot handle by itself. The request is to assume something else can handle if allowed to pass-through

Comment by Guillaume Sauthier [ 21/Apr/17 ]

Re-evaluate for 5.5

Comment by Joachim Andres [ 19/Mar/18 ]

In consequence of OPENAM-5160 being expired.

Generated at Mon Sep 21 15:49:59 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.