[OPENAM-11474] Custom IDP Attribute mappers may cause failures after upgrade Created: 03/Aug/17  Updated: 24/Aug/20

Status: Open
Project: OpenAM
Component/s: None
Affects Version/s: 13.5.1, 14.0.0, 14.1.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: C-Weng C Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: EDISON, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Target Version/s:
Support Ticket IDs:

 Description   

Bug description

After upgrading from 13.5.0 -> 13.5.1 and likely 14.0 it is possible that user extended libraries from DefaultLibraryIDPAttribytMappers. The reason is some of the internal of the these classes changed and in fact the it possible that

1) Old implemenation fails to run
2) Or old Implmentation behaves badly as the old isDynamicalOrIgnoredProfile(realm) is gone and replaced with isIgnoredProfile(Object session, String realm). And depending on which implementation was extended, it os possible that the default value of "true" is returned and hence "profile" data is ignored (ie: User attributes are not mapped in SAML).

May need to document or release note this or put by the old interface to 13.5.1/14.0.0 for old code

How to reproduce the issue

1. Extend a custom adapter from DefaultLibraryIDPAttributeMapper with no implementation, So then there is no profile data for this

public class DummyAttributeMapper extends DefaultLibraryIDPAttributeMapper
{

    public DummyAttributeMapper() {
    }

    protected boolean isDynamicalOrIgnoredProfile(String realm) {
        return SAML2PluginsUtils.isDynamicalOrIgnoredProfile(realm);
    }
}

2. Create a SAML federation (one IDP and SP)

3. Create some profile mapping from IDP (say uid. and mail)

4. Enable Federation debug. Do a SAML federation can check the SAML
payload that the attribute is sent to SP

5. Now change the IDP Attribute mapper to the DummyAttributeMapper
Restart and repeat to federation login. Observe that you may have no attributes from profile and the Federation logs have

DefaultLibraryIDPAttributeMapper.getAttributes: mail string value map was empty or null.
libSAML2:08/03/2017 01:27:59:661 PM SGT: Thread[http-nio-8080-exec-10,5,main]: TransactionId[0b3fb264-00f0-4692-b0d6-c5f1b60a7c7b-269]
DefaultLibraryIDPAttributeMapper.getAttributes: User profile does not have value for mail, checking SSOToken.
Expected behaviour

All the SAML attributes is sent in the Authn response.

Current behaviour

User profile attributes is missing.

Work around

Revisit all the old code that implements or extends from the SAML DefaultLibraryIDPAttributeMapper. and change code.
You may want to extend from DefaultIDPAttributeMapper instead if possible (but you need to use OpenFM.jar as DefaultLibraryIDPAttributeMapper happens to be there (if 6.x)

<dependencies>
        <dependency>
            <groupId>org.forgerock.am</groupId>
            <artifactId>OpenFM</artifactId>
        </dependency>
    </dependencies>

 
otherwise if using openam-federation-library, for your custom modules if you start fresh to implement

    protected boolean isDynamicalOrIgnoredProfile(String realm) {
...
    }

Code analysis

Due to OPENAM-9143

 

Side note

Should DefaultLibraryIDPAttributeMapper be relocated under openam-federation-library



 Comments   
Comment by Chris Lee [ 16/Apr/18 ]

Hi Jonathan, I'll loop Gene Hirayama in, the Sustaining Docs Lead. One for the next 13/14 releases Gene?

Comment by Jonathan Thomas [ 15/Nov/19 ]

The issue here was highlighting that the change in method name from isDynamicalOrIgnoredProfile to isIgnoreProfile may cause problems on upgrade.

 

One way to help avoid this, or at least make it more manageable,  is to extend from DefaultIDPAttributeMapper, not DefaultLibraryIDPAttributeMapper  as this has a correctly.

We should endure that documentation is in line with this as well.

Generated at Sun Sep 27 23:15:31 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.