I wrote a series of articles about this stuff and am too lazy right now to look them up.

Basically the <param> node of the DirXML-EntitlementRef (as stored on User) and nrfEntitlementRef (stored on Resource) format has changed over the years.

"Legacy" format is a simple string. Either a GUID or a DN or somethning.

"idm4" format is JSON and each driver is a tad different.  Usually have 2 values ID with the association value in the remote system (so often GUID like) and ID2 with a DN or human readable equivalent.  I have an entitlemnt on a driver i made with 4 params.  It all works.

That the Resource values have switched inditcates a possible config issue.

Look at the drivers EntitlementConifguration object in eDir.  (Every driver with Resource support makes one of these as a child of the Driver object).  Look at the XML for the <entitlement> node and see if the XML attr for format is legacy or idm4.

There are GCVs in the standard packages that control this value so a GCV change + driver restrt should help.

Good thought on the EntittlementConfiguration.  The two drivers I am looking at both have parameter-format="idm4".  This is why I wondered if there was an intentional change in how the user app does it.  Are you seeing the idm4 json format if you create a new mapping in 4.8.x?

Thus my reference to the articles...  There are many layers to this onion to unpeal.

EntitlementConfiguration is read by UA via LDAP, parsed to know what to qiuery.  The <parameter> nodes inside the <entitlement> nodes tells it waht to set as ID and ID2.  What are your <parameter> nodes looking like?

I searched for your articles related to this and couldn't pinpoint which one it was.

My parameter node looks like this on the drivers (AD and edir drivers in three environments):

<parameters>
<parameter mandatory="true" name="ID" source="association"/>
<parameter mandatory="true" name="ID2" source="src-dn"/>
</parameters>

That looks like correct parameter nodes.  So you have the proper entitlementConfiguration, but still getting the wrong data in the <param> node. Tricky.

Ok, so when your driver does the Code Map Refresh query (search level three trace for Injecting XDS and look at the query).  Is the <instance> returning a proper <instance> node with a src-dn and association value?

There is a SOAP call to get an Entitlement value from the Resource endpoint, checkCodeMapValueStatusRequest that lets you specify and entitlement and in theory get back the key values...  Might be worth querying your UA to see what the code map contains?  (Also can look at the DB direct, but I do not recall the proper tables to look at).

I pulled it from the REST API (grabbed the call from user app):

POST xxxxxxxx/.../listV2

{"id":"CN=Group,CN=IDV to AUTH - eDirectory,CN=driverset1,O=system","hasLogicalSystem":false}

Response:

{
"nextIndex": 0,
"arraySize": 4,
"entitlementValues": [
{
"name": "cn=test_group,ou=dealer,ou=groups,o=data",
"description": "This is a test",
"value": "{\"ID\":\"4BBC32AAFD646E4FB6824BBC32AAFD64\",\"ID2\":\"cn=test_group,ou=dealer,ou=groups,o=data\"}",
"id": "cn=Group,cn=IDV to AUTH - eDirectory,cn=driverset1,o=system",
"entitlementName": "eDirectory Groups"
},
{
"name": "cn=location-acs_test_building,ou=org,ou=groups,o=data",
"description": "ACS/Test Building (refid=ACS/Test Building)",
"value": "{\"ID\":\"B0A937990D61C14CAC98B0A937990D61\",\"ID2\":\"cn=location-acs_test_building,ou=org,ou=groups,o=data\"}",
"id": "cn=Group,cn=IDV to AUTH - eDirectory,cn=driverset1,o=system",
"entitlementName": "eDirectory Groups"
},
{
"name": "cn=test_group2,ou=dealer,ou=groups,o=data",
"description": "This is a test2",
"value": "{\"ID\":\"793BC921619F184782C9793BC921619F\",\"ID2\":\"cn=test_group2,ou=dealer,ou=groups,o=data\"}",
"id": "cn=Group,cn=IDV to AUTH - eDirectory,cn=driverset1,o=system",
"entitlementName": "eDirectory Groups"
},
{
"name": "cn=erp-erp_task_tester_execute,ou=groups,o=data",
"description": "Allows access to application Task Testing (Merlin).",
"value": "{\"ID\":\"F30C0ABEA90442449B1BF30C0ABEA904\",\"ID2\":\"cn=erp-erp_task_tester_execute,ou=groups,o=data\"}",
"id": "cn=Group,cn=IDV to AUTH - eDirectory,cn=driverset1,o=system",
"entitlementName": "eDirectory Groups"
}
]
}

They look normal to me.  When I add one of these as a mapped resource on a role in user app it just adds the DN as the value.

I'll have to dig through the UA logs... 

That is interesting...  So the CM table looks good. 

How are you 'looking' at the Entitlement value?  You show a screen shot of what is shown, if so, that is 'incomplete'.

What does the DirXML-EntitlementRef on a user assigned this Resource, and the nrfEntitlementRef on the Resource itself look like via LDAP?

Interesting...

DirXML-EntitlementRef on a test user shows:
cn=Group,cn=IDV to AUTH - eDirectory,cn=driverset1,o=system#1#<?xml version="1.0" encoding="UTF-8"?><ref>
<src>UA</src>
<id/>
<param>{"ID":"4BBC32AAFD646E4FB6824BBC32AAFD64","ID2":"cn=test_group,ou=dealer,ou=groups,o=data"}</param>
</ref>

nrfEntitlementRef on the Resource request shows:

cn=Group,cn=IDV to AUTH - eDirectory,cn=driverset1,o=system#0#<?xml version="1.0" encoding="UTF-8"?><ref>
<src>UA</src>
<id/>
<param>{"ID":"4BBC32AAFD646E4FB6824BBC32AAFD64","ID2":"cn=test_group,ou=dealer,ou=groups,o=data"}</param>
</ref>

So those look like I would expect.  Yet when I query the REST API it shows this:

POST /IDMProv/rest/catalog/roles/mappedResources/list

One that shows the value in idm4 format in the user app shows this in the api response:

That is very interesting...  So it looks like some are broken...  I assume you normalized all the names to the same DN for privacy. 

This makes me wonder, in the case where the REST API returns only one value, what the value in:

nrfEntitlementRef (since this is basically copied into an assigned user when Resource is assigned) on the Resource.

DirXML-EntitlementRef on a user

and the checkCodeMapValueStatusRequest call for that Entitlement as well.

In the end, if it works both ways, fine. If it does not, seems like you might need to find all the broken ones, and recreate them.

All of the examples above were for cn=test_group.  I didn't change the DN.  The LDAP attributes were generated when I assigned the role with mapped resource to a test user.  That resource mapping was created this week in user application.  The last output in from the API that shows idm4 format above was an assignment for this same test_group to a different role in 2016.

It seems like the REST API is translating the value so that it is stored in idm4 format in the directory.  I will test creating resource mappings both ways via the API to verify.