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
  • 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...

  • 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

  • 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).

  • 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.
  • 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"} ?


  • 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.

  • 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

  • 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

  • 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

  • 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.