Vice Admiral
Vice Admiral
1691 views

OAuth userinfo endpoint attribute format and NAM 4.5 SP3

Jump to solution

Yesterday evening we've patched NAM 4.5 from SP2 to SP3.

Today morning hell breaked loose because users of all applications that are using NAM as OpenID Connect IDP were not able to properly use applications.

What went wrong.

Before patching, userinfo endpoint returned attributes in following format:

{
    "sub": "427af3bea271854489ef427af3bea271",
    "website": "**PERSONAL INFORMATION REMOVED**",
    "OperationsID": "8005",
    "given_name": "GivenName",
    "employeeNumber": "21030",
    "CustomID": "10044659",
    "nickname": "username",
    "claims": [],
    "family_name": "Lastname"
}

After SP3 patch, attributes were in following format:

{
    "sub": "37dcb0db77bba240970937dcb0db77bb",
    "website": [
        "**PERSONAL INFORMATION REMOVED**"
    ],
    "OperationsID": "8005",
    "given_name": [
        "GivenName"
    ],
    "employeeNumber": [
        "21030"
    ],
    "CustomID": "8704058",
    "nickname": [
        "username"
    ],
    "claims": [],
    "family_name": [
        "Lastname"
    ]
}

As you can see, every attribute that is define as multi-valued attribute in backend userstore, is now returned as an array, not string. As an result, applications using NAM as OpenID Connect as authentication source have problem extracting information.

Searching through documentation (SP3 readme) there is a bug mentioned:

Bug ID: 218453

When a client application uses the Authorization Code flow and sends the access token to the userinfo endpoint, the attribute type of the query result is not consistent. If the attribute contains a single value, it is sent as a string, and if it contains multiple values, it is sent as an array.

 

But "standard" documentation regarding attribute sets still says that if attribute has only one value, it will be returned as string, if it has multiple values, it will be returned as array.

Currently I have created a dirty workarround to get those values as strings, but there are my questions:

  • How can I revert NAM to send attributes in format as mentioned in documentation? (as in SP2) Is there a hidden parameter I can use?
  • Why documentation still says that attributes with single value should be returned as string, although they are returned as arrays with one value?
  • Why nobody put a HUGE warning in SP3 readme that format of attributes will be changed?

 

Any info appreciated.

 

Kind regards,

Sebastijan

Labels (1)
0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

This issue is fix and available as engineering build. Please raise a SR and contact support to get the build.

View solution in original post

15 Replies
Vice Admiral
Vice Admiral

For somebody else with similar problem, let me describe workarround.

 

First I tried to fix stuff by creating a virtual attribute that will convert array into string and assign that as attribute source in attribute set.

Simple enough, so I've created this:

p1.jpg

But that did not help. Attribute was still sent as array with one value.

 

To make it work I needed to add additional attribute, which was single valued and user had a value there:

p2.png

Although that second attribute was not used in Javascript modification function it was enough to force NAM to present attribute as string, not array with one value.

Please note that if user did not have second attribute set in backend directory, workarround did not work.

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

The fix provided for bug 218453 will check the LDAP attribute schema data type.  If attribute data type is single valued it will return as String, if the attribute data type is multi valued the userinfo endpoint will return it as String array. 

Are these attribute's schema data type is single valued or multi-valued attribute. Which user-store is used it is eDirectory or AD?

 

Attribute SchemaAttribute Schema

Vice Admiral
Vice Admiral

Hi!

 

All attributes converted to array are multi-valued (backend store is eDirectory).

And I understand that "old way" was a bit confusing. We had quite a lot of talks with different developers complaining that they don't understand why for example custom roles attribute is sometimes returned as string (when there's only one value) and why sometimes as an array (when there are multiple values). And we needed to explain it to them that this is how NAM currently works. And of course, "new way" is much more consistent.

But if you're going to change behavior for existing product we need to have possibility to enable that in small steps.

Every developer of app that is using openid connect needs now to change their application to differently parse data. Since we have multiple applications, we cannot assure that all developers will be able to change their application at the same time, so we must be able to enable new behavior by application, not for whole IDP at the same time. Not to mention that changing application means a lot of testing, QA and other stuff, before put into production.

But more pressing, is there a setting (tomcat.conf, or web.xml, or whatever) to persuade NAM 4.5 SP3 to behave as SP2?

 

Thanks and kind regards,

Sebastijan

 

Micro Focus Frequent Contributor
Micro Focus Frequent Contributor

Hi,

Unfortunately there is so such settings available for this in 4.5 SP3 to behave it like 4.5 SP2. May be engineering fix can be provided to behave like 4.5 SP2 in this case.

 

 

Vice Admiral
Vice Admiral

I see. I will open service request with highest priority.

On the other hand, it would be best if we would be able to select the behaviour for each mapping in attribute set. That way we could also "hide" that some attributes are multi-valued, even though they are used mostly as single valued (e.g. given name).

Thanks for quick reply!

Kind regards,

Sebastijan

0 Likes
Vice Admiral
Vice Admiral

If you can help, SR# is 101306588411

 

Thanks, Sebastijan

0 Likes
Commodore
Commodore
Sebastijan,
Did you solve this with engineering ?
Having exactly the same problem, even constants are sent as arrays .
//Magnus
Vice Admiral
Vice Admiral

Hi Magnus!

 

Still waiting for fix that would allow us to use "old" behavior. In consequence, we have stopped upgrades to 4.5.3 at all other customers.

In mean time we must live with workaround I've described in this post, but that is not something I'd like to do with a lot of users and attributes...

 

Kind regards,

Sebastijan

Commodore
Commodore

Luckily this is only dev environment, but we have lots of developers that can't use OIDC now. 

Unfortunately, your fix with virtual attributes is not working for me.  Value is still sent as an array... 

This is a big issue for everyone using NAM as IDP, I think MF should withdraw sp3, or at least make a huge disclaimer.  

 

//Magnus

0 Likes
Micro Focus Frequent Contributor
Micro Focus Frequent Contributor
Hi,
Yes, it is a good idea to have it configure in each attribute while creating the attribute set or similar functionality in virtual attribute. May be this can be filed as an Idea in the Ideas portal.
0 Likes
Micro Focus Expert
Micro Focus Expert

This issue is fix and available as engineering build. Please raise a SR and contact support to get the build.

View solution in original post

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.