Table of Contents
Overview
Quick Post about a latest finding of an Issue when using NetScaler as OAuth IdP (doesn’t matter with which SP) and there is the need of sending some User-Attributes to the SP.
Update – Solved
Finally the Firmware for the Fix is released today (April 23rd) in 14.1 21.57, see the release notes, fixed issues:
Issue
You’re having the need to send some previously extracted LDAP User-Attributes via OAuth from NetScaler (acting as IdP) to an OAuth SP for a successful OAuth-Flow.
In this example we are extracting three Attributes (cn, extensionAttribute1 and extensionAttribute2) from a LDAP No-Auth action and storing these Attributes to NetScaler for further processing on the OAuth IdP Policy:
The Attribute-Configuration is on the last part of the Authentication OAuth IDP Profile:
Our example has the following syntax:
cn=AAA.USER.ATTRIBUTE(1)@@@extensionAttribute1=AAA.USER.ATTRIBUTE(2)@@@extensionAttribute2=AAA.USER.ATTRIBUTE(3)
So what effect does the error have if one of the user attributes to be sent is empty? Oh that’s pretty simple, NONE of all configured Attributes are sent, the Attribute-String is completely empty, resulting in an unsuccessful OAuth response from the SP.
This could be fixed if it would be possible to bind OAuth IdP Policies within a nFactor Flow, so you could filter on empty Attributes, but as long as OAuth IdP Policies need to be bound directly to an AAA vServer, that’s unfortunately not possible, yet.
When NetScaler is acting as OAuth SP, you are able to bind these policies inside your nFactor flow without any limitations.
Also, this issue is NOT happening when NetScaler is acting as SAML IdP. With SAML, it’s no problem when there are some empty Attributes. NetScaler will send all filled Attributes to the SP and just ignoring the empty ones (what we would also expect with OAuth).
Solution
The Issue is tracked as NSHELP-36533 and the fix is expected in 14.1-21.x firmware build which will be available around end of April 2024. Same fix will be available in 13.1-53.x releasing in May 2024.
For this reason we have been using the ALT expression in all cases for defining these attributes with a default value:
cn=AAA.USER.ATTRIBUTE(1)@@@extensionAttribute1=AAA.USER.ATTRIBUTE(2) ALT “unknown”@@@extensionAttribute2=AAA.USER.ATTRIBUTE(3) ALT “unknown”
Thanks for that Workaround, Frank!