JWT Bearer Grant flow failed with Bad Request 400 error after upgrade to 3.2.1

Products

• VIP Authentication Hub

Issue/Introduction

After upgrading VIP Authentication Hub from 2.2.6 to 3.2.1, previously working JWT Bearer Grant flow failed. Running the JWT Bearer Grant flow, i.e. sending external ID Token to /token endpoint, failed with Bad Request 400 error with the following 'invalid assertion' message.

{
    "clientTxnid": null,
    "error": "invalid_request",
    "error_description": "Invalid assertion"
}

Looking at azserver pod's log, there was "Unable to locate LDAP user in id store" error message like below and LDAP search filter is formed with 'null'

Unable to locate LDAP user in id store matching filter search query '(&(objectClass=inetorgperson)(null=<xyz>))'.

The following are set in the LDAP configuration

        "ldapQueryStart": "(displayName=",
        "ldapQueryEnd": ")"


        "attributeMapping": "user_loginid=cn,family_name=sn,given_name=givenName,email=mail,phone_number=telephoneNumber,user_universalid=cn,status=employeeType,memberof=memberof,consumer_username=displayName"

Environment

VIP Authentication Hub 3.2.1

Cause

In the previous VIP Authentication Hub 2.2.x version, it had very loose model for mapping, resulting potential mistakes such as mis-wired mapping covering ZFP (Zero Foot Print) and non ZFP flows. In VIP Authentication Hub 3.1.x onward, to prevent this issue it is required for spMappingAttribute to be set for mapping in Identity Provider configuration and also logical to physical mapping for attribute being used in the LDAP filter.

Resolution

In this case, do the following steps to resolve the problem

1. As "displayName" is the attribute being used in the LDAP filter, set the spMappingAttribute value to "displayName" in the Identity Provider configuration

        "idpTokenSubjectClaim": "consumer_username",
        "idpSubjectClaimSource": null,
        "spMappingAttribute": "displayName"

2. Add Logical attribute to physical attribute mapping in the attributeMapping for displayName, i.e. map "displayName" to "displayName" in the LDAP configuration

        "attributeMapping": "user_loginid=cn,family_name=sn,given_name=givenName,email=mail,phone_number=telephoneNumber,user_universalid=cn,status=employeeType,memberof=memberof,displayName=displayName,consumer_username=displayName"