Anonymous_User Absent Member.
Absent Member.
278 views

Parameter-less SOAP driver Entitlement chokes RRS driver


Hi,

We recently decided to migrate our Role-Based entitlement setup to Roles
and Resources driver in an existing IDM 4.0.2 setup.
I seem to hit a strange IDM4 (JSON) parameter formatting problem in the
RRS Driver for a SOAP driver entitlement that I can't reproduce in the
AD driver, so I suspect the SOAP driver (version 3.5.7) to be broken, or
I miss some configuration or policy I'm not aware of?

The problem is as follows: I have a simple entitlement without
parameters in the SOAP driver. I created an EntitlementConfiguration.xml
by hand (the SOAP driver doesn't seem to be equiped to create this
itself?).
I map the simple entitlement to the Roles & Resources Driver by adding
this line, which is the most simple form of mapping as far as I
understand:

<entitlement data-collection="false" dn="CN=Zimbra
Email,CN=Zimbra,CN=driverset1,O=system" resource-mapping="true"
role-mapping="true" />

When I sync the Roles & Resource cache, I'm able to find the new
entitlement and assign it to a resource. After that, I assign a user to
the resource and then things start to go wrong.
The RRSD driver spits out the following error:

Driver: \SURF\system\driverset1\Role and Resource Service Driver
Channel: Subscriber
Status: Error
Message: Error processing request
DN: O=system\CN=driverset1\CN=User Application
Driver\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20141128151421-26a4ffd683dc451a8d6136f9412e25e5-0
Reason: java.lang.Exception: Error. Entitlement
parameter value is not in the expected JSON format, defined by the
entitlement configuration setting named parameter-format. This can
occur from malformed JSON in the parameter value, or an entitlement was
provisioned with a legacy parameter value before the entitlement
parameter support was upgraded to IDM4.
DN: O=system\CN=driverset1\CN=Zimbra\CN=Zimbra Email
Agent: UA
Parameter Value:

I've read 1001 pages on the Legacy to IDM4 migration issues, but there
seems to be a fundamental problem here: there is no paramater, but it's
still incorrect encoded. I assign a test user that has all RBS
entitlements removed before the assignment so there are no legacy xml
entitlements.

If I recreate this scenario in the AD driver by adding a simple
parameter-less entitlement and add the entitlement to the
EntitlementConfiguration resource in the driver in the same way, resync
user app and add the entitlement to a resource, and add a user, the
output of the RRS driver is:

Driver: \SURF\system\driverset1\Role and Resource Service Driver
Channel: Subscriber
Status: Success
Message: Transitioned request status from 30 to 50
DN: O=system\CN=driverset1\CN=User Application
Driver\CN=AppConfig\CN=RoleConfig\CN=ResourceRequests\CN=20141128150034-4d9d8ed59eb54f229f2912b830558bf3-0

Both drivers werre added in Designer and originate from the same 4.0.2
installation. I would expect both drivers to be IDM4 entitlement
parameter format compatible?
What am I missing?

Best regards,
Martin


--
mrvanes
------------------------------------------------------------------------
mrvanes's Profile: https://forums.netiq.com/member.php?userid=4768
View this thread: https://forums.netiq.com/showthread.php?t=52317

Labels (1)
0 Likes
11 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Parameter-less SOAP driver Entitlement chokes RRS driver

mrvanes <mrvanes@no-mx.forums.netiq.com> wrote:
> Hi,
>
> We recently decided to migrate our Role-Based entitlement setup to Roles
> and Resources driver in an existing IDM 4.0.2 setup.
> I seem to hit a strange IDM4 (JSON) parameter formatting problem in the
> RRS Driver for a SOAP driver entitlement that I can't reproduce in the
> AD driver, so I suspect the SOAP driver (version 3.5.7) to be broken, or
> I miss some configuration or policy I'm not aware of?
>
> The problem is as follows: I have a simple entitlement without
> parameters in the SOAP driver. I created an EntitlementConfiguration.xml
> by hand (the SOAP driver doesn't seem to be equiped to create this
> itself?).


If one copies across the same itp/otp entitlement policies as used in the
ad driver, they don't work correctly when triggered by a code-map refresh.
I have a SR and bug raised against this.

That is a valued query based entitlement (where the policies fabricate a
value based on a driver activation ping) - same as the AD-user account
entitlement.

Not sure if that is the same issue.


--
If you find this post helpful and are logged into the web interface, show
your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Parameter-less SOAP driver Entitlement chokes RRS driver


Hi Alex,

I never copied itp/otp rules from AD driver into the SOAP driver and the
Entitlement doesn't depend on policy created values. The code map
generation for the entitlement succeeds and is "empty".

The definition of empty seems to be what's biting me here. On a
sidenote: having an entitlement with administrator prefilled values
results in the same error, except when I create a json encoded value and
a parameter transformation in the
EntitlementConfiguration.xml. Which is good for entitlements with
prefilled values, but not for a parameter-less entitlement.

Regards,
Martin


--
mrvanes
------------------------------------------------------------------------
mrvanes's Profile: https://forums.netiq.com/member.php?userid=4768
View this thread: https://forums.netiq.com/showthread.php?t=52317

0 Likes
Knowledge Partner
Knowledge Partner

Re: Parameter-less SOAP driver Entitlement chokes RRS driver

On 11/28/2014 11:48 AM, mrvanes wrote:
>
> Hi Alex,
>
> I never copied itp/otp rules from AD driver into the SOAP driver and the
> Entitlement doesn't depend on policy created values. The code map
> generation for the entitlement succeeds and is "empty".
>
> The definition of empty seems to be what's biting me here. On a
> sidenote: having an entitlement with administrator prefilled values
> results in the same error, except when I create a json encoded value and
> a parameter transformation in the
> EntitlementConfiguration.xml. Which is good for entitlements with


An Entitlement with a payload that is meaningless and is ignored by the
policies in your SOAP driver that implement the policy is the same as an
empty value.

Make the value the email address or the CN or something vaguely
meaningful.

Your key point is, entitlements with no payload cause an issue for RRSD.
If you force a nonsense value in, it is fine. If your policies do not
pay attention to it, it i sfine.

So there is a workaround, but clearly seems like it is a problem, not
being able to handle empty entitlements.

Bet if your EntitlementConfiguration object, if you set the
parameter-format="legacy" inside the <entitlement> node.

So it looks more like:

<entitlement data-collection="false" dn="CN=Zimbra
Email,CN=Zimbra,CN=driverset1,O=system" resource-mapping="true"
role-mapping="true" parameter-format="legacy" />

The legacy format does not try to parse a JSON string, which "" or null
fails. (Should be {} I guess for null).

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Parameter-less SOAP driver Entitlement chokes RRS driver

Geoffrey Carman wrote:

> An Entitlement with a payload that is meaningless and is ignored by the policies in your SOAP driver that implement the policy is the same as an empty value.


Not entirely meaningless, it is usefull to have a value that is somewhat meaningful on the odd chance you end up implementing reporting later.

> Bet if your EntitlementConfiguration object, if you set the parameter-format="legacy" inside the <entitlement> node.
>
> So it looks more like:
>
> <entitlement data-collection="false" dn="CN=Zimbra
> Email,CN=Zimbra,CN=driverset1,O=system" resource-mapping="true"
> role-mapping="true" parameter-format="legacy" />
>
> The legacy format does not try to parse a JSON string, which "" or null fails. (Should be {} I guess for null).


Would try to make the idm4 style format work rather than stay with legacy format.

Also,

If I recall correctly, admin-defined values regardless of format are not officially supported with IDM4 parameter format.
One can make it work: I wrote about that here: https://forums.netiq.com/showthread.php?998-parameter-format-quot-idm4-quot-and-administrator-defined-values but it isn't recommended.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Parameter-less SOAP driver Entitlement chokes RRS driver

On 11/28/2014 12:33 PM, Alex McHugh wrote:
> Geoffrey Carman wrote:
>
>> An Entitlement with a payload that is meaningless and is ignored by the policies in your SOAP driver that implement the policy is the same as an empty value.

>
> Not entirely meaningless, it is usefull to have a value that is somewhat meaningful on the odd chance you end up implementing reporting later.


We come back to the root cause, this is all a black box, whose
input/outputs are not defined. If they want to leave a black box, fine.
But document in/out formats.

Otherwise document how it works. Strange oversight.

> Would try to make the idm4 style format work rather than stay with legacy format.


Agreed.

> If I recall correctly, admin-defined values regardless of format are not officially supported with IDM4 parameter format.
> One can make it work: I wrote about that here: https://forums.netiq.com/showthread.php?998-parameter-format-quot-idm4-quot-and-administrator-defined-values but it isn't recommended.


In that article you say a step:
2. In entitlement object, specify the value in JSON format, for example:
{"ID":"an_entitlement_value"}

By Entitlement object you mean the DirXML-Entitlement object and a line
like:
<value>{"ID":"Value1"}</value>


Or did you mean in the UA, when you assign a Resource to an Entitlement,
define the Admin value as {"ID":"Value1"} ?


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Parameter-less SOAP driver Entitlement chokes RRS driver

Geoffrey Carman wrote:

> In that article you say a step:
> 2. In entitlement object, specify the value in JSON format, for example:
> {"ID":"an_entitlement_value"}
>
> By Entitlement object you mean the DirXML-Entitlement object and a line like:
> <value>{"ID":"Value1"}</value>
>
>
> Or did you mean in the UA, when you assign a Resource to an Entitlement, define the Admin value as {"ID":"Value1"} ?


I meant in the DirXML-Entitlement object and yes a series of lines like that.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Parameter-less SOAP driver Entitlement chokes RRS driver


Had a backoffice mail chat with another IdM Guru and he tipped me to
SOAP driver 4.0.0.0 currently in restricted field test and that fixed
part of my problems!
The parameter-less entitlement is fixed, the simple-list version still
needs some love.

All thanks for your input!

Have a nice weekend
Martin


--
mrvanes
------------------------------------------------------------------------
mrvanes's Profile: https://forums.netiq.com/member.php?userid=4768
View this thread: https://forums.netiq.com/showthread.php?t=52317

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Parameter-less SOAP driver Entitlement chokes RRS driver

mrvanes wrote:

>
> Had a backoffice mail chat with another IdM Guru and he tipped me to
> SOAP driver 4.0.0.0 currently in restricted field test and that fixed
> part of my problems!
> The parameter-less entitlement is fixed, the simple-list version still
> needs some love.


Good to know, that's the version I've been using since it's release, I'd assumed you were running that already. Bad assumption.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Parameter-less SOAP driver Entitlement chokes RRS driver

On 11/28/2014 5:44 PM, mrvanes wrote:
>
> Had a backoffice mail chat with another IdM Guru and he tipped me to
> SOAP driver 4.0.0.0 currently in restricted field test and that fixed
> part of my problems!


What part does it fix? Specifically, the valueless entitlement is an
RRSD issue, not a SOAP driver issue.


> The parameter-less entitlement is fixed, the simple-list version still
> needs some love.


Fixed where? By statically defining a value?


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Parameter-less SOAP driver Entitlement chokes RRS driver


SOAP driver DOES fix the valueless entitlement error in RRSD driver!
It's only apparent in the SOAP driver (3.5.7) like I said in the first
post and AD driver didn't have this problem at all!
I got to fix the administrator defined values problem tonight by
supplying the values as the JSON strings like this:

{"ID":"first value"}
{"ID:"second value"}
etc.

The EntitlementConfiguration for this valued entitlement is:

<entitlement data-collection="false"
dn="CN=DistributionLists,CN=Zimbra,CN=driverset1,O=system"
parameter-format="idm4" resource-mapping="true" role-mapping="true" />

Mind that I DIDNT need a parameter conversion from ID to value for this
transformation to work like I thought based on this example in
http://tinyurl.com/nnsf8ar. It ONLY works when you use "ID" as the key
value.

I thought to be smart and made my JSON values like this first:

{"DL":"first value"}

Because the Entitlement is about Distribution Lists and have a parameter
conversion configuration like this:

<entitlement ....>
<parameters>
<parameter mandatory="false" name="DL" source="value"/>
</parameters>
</entitlement>

This DOES NOT WORK (results in JDBC errors while updating the code map)!
The parameter element is pointless and I need to use "ID".
That's all it takes. My RRSD driver now happily accepts all user
assignments!

I'm less than amused about the abysmal documentation and extremely
unintuitive configuration (changes) needed to make this transition work.
Ugh!


Best regards,
Martin


--
mrvanes
------------------------------------------------------------------------
mrvanes's Profile: https://forums.netiq.com/member.php?userid=4768
View this thread: https://forums.netiq.com/showthread.php?t=52317

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Parameter-less SOAP driver Entitlement chokes RRS driver


alexmchugh;251574 Wrote:
> Geoffrey Carman wrote:
> Also,
>
> If I recall correctly, admin-defined values regardless of format are not
> officially supported with IDM4 parameter format.
> One can make it work: I wrote about that here:
> http://tinyurl.com/nnsf8ar but it isn't recommended.

It's exactly this post that inspired me to test the JSON encoded
variation of the simple administrator provided parameter setup. So, yes
there is a workaround if we ignore the "meaningless" value in the
policies, but I bet it will raise questions from the client when using
the R&R's afterwards. Hard to explain they're looking at a workaround
for a buggy product they just bought? 😕


--
mrvanes
------------------------------------------------------------------------
mrvanes's Profile: https://forums.netiq.com/member.php?userid=4768
View this thread: https://forums.netiq.com/showthread.php?t=52317

0 Likes
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.