IDM 4.7 Custom Entitltments

Okay, I really need some help from the members of this forum.

I am thoroughly confused and frustrated with trying to get a simple custom entitlement working with a REST Driver. I have followed the documentation (https://www.netiq.com/documentation/identity-manager-47/entitlements/data/identity-manager-entitlements.html) step by step but can not seem to get this working.

I am just trying to create a simple entitlement that does not require a value. I have installed the "Custom Entitlements" package on the driver, set the proper GCV value, created the entitlement object and deployed the driver. The new entitlement successfully shows up in Role
  • On 11/15/2018 11:16 AM, DTesenair wrote:
    >
    > Okay, I really need some help from the members of this forum.
    >
    > I am _thoroughly__confused and frustrated with trying to get a simple
    > custom entitlement working with a REST Driver. I have followed the
    > documentation
    > (https://www.netiq.com/documentation/identity-manager-47/entitlements/data/identity-manager-entitlements.html)
    > step by step but can not seem to get this working.
    >
    > I am just trying to create a simple entitlement that does not require a
    > value. I have installed the "Custom Entitlements" package on the


    2 options for unvalued entitlements:
    1) Change the format to legacy instead of IDM4. (This is in the
    entitlementConfiguration objects entitlement node that defines this
    entitlement. Then empty is allowed.

    2) Provide a Admin provided value of {} open/close curly brace, since
    that is a valid JSON null, instead of null itself.

    Honestly this should just be fixed in RRSD. But easy enough to work around.


    > driver, set the proper GCV value, created the entitlement object and
    > deployed the driver. The new entitlement successfully shows up in Role
    >
  • DTesenair <DTesenair@no-mx.forums.microfocus.com> wrote:
    >

    Okay, I really need some help from the members of this forum.
    >
    > I am _thoroughly__confused and frustrated with trying to get a simple

    custom entitlement working with a REST Driver. I have followed the
    documentation
    (https://www.netiq.com/documentation/identity-manager-47/entitlements/data/identity-manager-entitlements.html)
    step by step but can not seem to get this working.
    >
    > I am just trying to create a simple entitlement that does not require a

    value. I have installed the "Custom Entitlements" package on the
    driver, set the proper GCV value, created the entitlement object and
    deployed the driver. The new entitlement successfully shows up in Role
  • geoffc;2490907 wrote:

    2 options for unvalued entitlements:
    1) Change the format to legacy instead of IDM4. (This is in the
    entitlementConfiguration objects entitlement node that defines this
    entitlement. Then empty is allowed.

    2) Provide a Admin provided value of {} open/close curly brace, since
    that is a valid JSON null, instead of null itself.

    Honestly this should just be fixed in RRSD. But easy enough to work around.


    Geoff, Thanks for replying so quickly.

    Option 1: If I modify the EntitlmentConfiguration object, it gets overwritten when the driver restarts. I can't find any where else on the driver (or in the documentation!!!) that explains how to do this without it getting overwritten. There seems to be some reference in the startup policy to a GCV value but that doesn't exist. Do I have to manually create it? If so, why is that not documented?

    Option 2: I have no idea where to do this. I've tried editing the entitlement in Designer and adding values but that's when the Code Map refresh fails on my entitlement.

    Ugh.... why is this so difficult???!?! Sorry for my frustration. :(
  • > Geoff, Thanks for replying so quickly.
    >
    > Option 1: If I modify the EntitlmentConfiguration object, it gets
    > overwritten when the driver restarts. I can't find any where else on


    True. So I am not familiar with the specific package you are using.

    Generally there is a GCV for all the settings used in
    entitlementConfiguration.

    You could disable the policy that recreates the object on every restart,
    and then edit the entConf object directly.

    > the driver (or in the documentation!!!) that explains how to do this


    What you think they are documenting this package? If so, please let me
    know where!

    > without it getting overwritten. There seems to be some reference in the
    > startup policy to a GCV value but that doesn't exist. Do I have to
    > manually create it? If so, why is that not documented?



    > Option 2: I have no idea where to do this. I've tried editing the
    > entitlement in Designer and adding values but that's when the Code Map
    > refresh fails on my entitlement.
    >
    > Ugh.... why is this so difficult???!?! Sorry for my frustration. :(


    Define the Entitlement like this, I think: Just made one in Designer.

    <?xml version="1.0" encoding="UTF-8"?><entitlement
    conflict-resolution="priority" description="Test" display-name="Test">
    <values multi-valued="false">
    <value>{}</value>
    </values>
    </entitlement>

  • DTesenair <DTesenair@no-mx.forums.microfocus.com> wrote:
    >

    geoffc;2490907 Wrote:
    >
    >> Honestly this should just be fixed in RRSD. But easy enough to work

    > around.
    >>

    >
    > Geoff, Thanks for replying so quickly.
    >
    > Option 1: If I modify the EntitlmentConfiguration object, it gets

    overwritten when the driver restarts. I can't find any where else on
    the driver (or in the documentation!!!) that explains how to do this
    without it getting overwritten. There seems to be some reference in the
    startup policy to a GCV value but that doesn't exist. Do I have to
    manually create it? If so, why is that not documented?
    >


    Most times Iâ€Tmve seen people disable the relevant startup policy (after it
    runs once) and just modify the entitlement config object manually. Not
    saying this is the best approach long term but it should work.

    Note that the packages you are using arenâ€Tmt documented in the link you
    referenced.

    >
    > Ugh.... why is this so difficult???!?!
    >


    Because the vendor wants you to use idm4 valued entitlements as they work
    best with RRSD, reporting and default policies.

    Also arenâ€Tmt the custom entitlements (part of the old PCRS) deprecated and
    going away in favour of the more streamlined CPRS option that lacks the
    ability to create

    Regarding option #2 - that requires switching over to “administratively
    defined values” and that comes with own set of wrinkles (especially in that
    it is rarely used these days).
  • DTesenair <DTesenair@no-mx.forums.microfocus.com> wrote:
    >

    geoffc;2490907 Wrote:
    >
    >> Honestly this should just be fixed in RRSD. But easy enough to work

    > around.
    >>

    >
    > Geoff, Thanks for replying so quickly.
    >
    > Option 1: If I modify the EntitlmentConfiguration object, it gets

    overwritten when the driver restarts. I can't find any where else on
    the driver (or in the documentation!!!) that explains how to do this
    without it getting overwritten. There seems to be some reference in the
    startup policy to a GCV value but that doesn't exist. Do I have to
    manually create it? If so, why is that not documented?
    >


    Most times Iâ€Tmve seen people disable the relevant startup policy (after it
    runs once) and just modify the entitlement config object manually. Not
    saying this is the best approach long term but it should work.

    Note that the packages you are using arenâ€Tmt documented in the link you
    referenced.

    >
    > Ugh.... why is this so difficult???!?!
    >


    Because the vendor wants you to use idm4 valued entitlements as they work
    best with RRSD, reporting and default policies.

    Also arenâ€Tmt the custom entitlements (part of the old PCRS) deprecated and
    going away in favour of the more streamlined CPRS option that lacks the
    ability to create

    Regarding option #2 - that requires switching over to “administratively
    defined values” and that comes with own set of wrinkles (especially in that
    it is rarely used these days).