Canonical name ‘vs’ User ID

Issue:
Recently I worked on a customer issue where in they were seeing an error when the user logged into their AIR client on MAC and was unable to access the application.

The error seen was :
LC_AuthenticateUser Error: com.adobe.idp.um.api.UMException| [com.adobe.idp.um.api.impl.AuthenticationManagerImpl] errorCode:16386 errorCodeHEX:0x4002 message:user_identifier:Z027223 domain:DefaultDomcom.adobe.idp.common.errors.exception.IDPException| [com.adobe.idp.um.businesslogic.directoryservices.DirectoryServicesManagerBean] errorCode:13316 errorCodeHEX:0x3404 message:user_identifier: Z027223 domain:DefaultDom; 

Below is the end to end description for the authentication process which customer had implemented –

– User double clicks to launch the AIR/Flex application on MAC.
– AIR/Flex application calls .NET webservice for Authentication.
– User profile under which AIR/Flex app is running sends user login id in transport layer of webservice call.
– .NET server/application is configured to grab user login id from transport layer.
– .NET uses livecycle authenticationmanagerservice API to call ‘getAuthResultOnBehalfOfUser’ method passing grabbed login id as canonicalName, ‘DefaultDom’ as domain and null as context. This call uses livecycle id with admin privileges.
– Livecycle returns auth token back to .NET.
– .NET returns auth token  received to AIR/Flex application. [authResult.assertion].
– This auth token is further used as password for further livecycle API call. [ user id :-‘ _LC_SAML_LOGIN_’ and password = authtoken received earlier]

The issue seen was that when the user logged into the AIR/Flex app, they would see the above error and not be able to access the application

The user would then login to LC Workspace and then retry logging into the AIR/Flex app and this time, the login would succeed.

Trouble-shooting:

1. When users login via Mac AIR App then canonicalName sent is not same as the actual canonicalName case-wise, hence users are not found.
2. When they login via Workspace then UM cache get populated with key which is in all uppercase
3. Then subsequent calls made from Air app gets passed as user look up first happens in cache with key used is in all uppercase and user is found

We could deduce basaed on above hypothesis that there is some difference in the case of the canonicalName, when .Net app grabs the user loginId from the transport layer.

The following was happening:
– On Mac – User A logs on to AIR app – Does not get authenticated
– On Mac – User A then logs in via LC Workspace and then logs back in via AIR App – Does get authenticated
– On Windows – User A logs on to AIR app – Does get authenticated

From AIR app following sequence is done
– User double click to launch the CP AIR/Flex application.
– AIR/Flex application calls .NET webservice for Authentication.
– User profile under which AIR/Flex app is running sends user logon id in transport layer of webservice call.
– .NET server/application is configured to grab user logon id from transport layer.
– .NET uses livecycle authenticationmanagerservice API to call ‘getAuthResultOnBehalfOfUser’ method passing grab logon id as canonicalName, ‘DefaultDom’ as domain and null as context.  This call uses livecycle id with admin privileges.
– Livecycle returns auth token back to .NET.
– .NET returns auth token  received to AIR/Flex application. [authResult.assertion].
– This auth token is further used as password for further livecycle API call. [ user id :-‘ _LC_SAML_LOGIN_’ and password = authtoken received earlier]

The user error indicated the below:
– User logs in via AIR app sees following exception on .Net side errorCodeHEX:0x3404 message:user_identifier: Z027223 domain:DefaultDom
– User logs in via workspace does not see any exception. User id used is z027223 .  Note that userid used here is having a different case which was the same as in database

To summarize the issue – When the user was logging into the AIR/Flex app via MAC (using login ID – z027223 for example), the login ID that was passed to .Net app was getting modified into all UPPERCASE (so the ID was being sent as Z027223 instead of z027223). .Net app would use this all UPPPERCASE to make a call to LC using the ‘getAuthResultOnBehalfOfUser’ method. But since all comparisons on LC end when using the canonicalName are done in a case-sensitive manner, the authentication would fail.

Resolution:
To resolve the issue, the userID captured by the .Net app was first used to get the canonicalName for that user and then this was used in the ‘getAuthResultOnBehalfOfUser’ method to set the SAML token.

Key things to take away from this issue:
When making calls using
1. canonicalName then user are searched in case sensitive way
2. userId then users are searched in case insensitive way
3. UM maintains a cache whose key is either of
     a. userId in UPPERCASE, DomainName
     b. canonicalName in UPPERCASE , DomainName

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 9.0/10 (5 votes cast)
Canonical name 'vs' User ID, 9.0 out of 10 based on 5 ratings

About Ameeth Palla

Ameeth Palla is a Technical Account Manager for the Adobe Digital Enterprise Platform team. Previously he was in the role of a Technical Expert for LiveCycle for the the Technical Response Team (what is now the Sr.Support Architect role). In both roles, Ameeth handled several technical issues for various customers and worked closely to aid with Sales POC's, Development/Implementation and Manitenance of LiveCycle/ADEP Projects. In the current role he handles several high profile customer accounts and provides guidance in all aspects of LiveCycle/ADEP. Also he is a Certified LiveCycle ES2.5 Process Management Expert. He was nominated for the 'Adobe Founders Award' and the 'Excellence Matters' award for LiveCycle/ADEP BU.
This entry was posted in Adobe LiveCycle ES2 (9.0.x), Adobe LiveCycle ES3 and tagged , , , , . Bookmark the permalink.

Comments are closed.