Can't read DirXML-EntitlementRef in LoopBack driver

Hi,

since a few weeks, probably since the upgrade to Identity Manager 4.7, the attribute DirXML-EntitlementRef can no longer be read in the LoopBack driver. That put us in a lot of trouble.
A rights problem can be excluded, the driver runs in security equivalence to the admin user. It seems to work in the other driver types used. The current workaround is an LDAP query into the identity vault to get the attribute.
Has anyone else had similar experiences and an idea of what is behind it?

Thanks,
Robert
  • On 6/13/2018 8:26 AM, rhaeber wrote:
    >
    > Hi,
    >
    > since a few weeks, probably since the upgrade to Identity Manager 4.7,
    > the attribute -DirXML-EntitlementRef- can no longer be read in the
    > LoopBack driver. That put us in a lot of trouble.
    > A rights problem can be excluded, the driver runs in security
    > equivalence to the admin user. It seems to work in the other driver
    > types used. The current workaround is an LDAP query into the identity
    > vault to get the attribute.
    > Has anyone else had similar experiences and an idea of what is behind
    > it?


    So you think it is shim or engine? I.e. Port the code into some oether
    driver, does it work?

    David Gersic ran into an issue where DirXML-Associations and
    DirxML-AssociationsLite do not query quite correctly, the engine tries
    to help by cleaning up. Entitlemet Ref would make sense to do something
    similar.



  • Sorry, I was wrong. The issue is that the result of a query for the attribute DirXML-EntitlementRef contain now only the values with reference to the drivers own entitlements.
    Since there are no entitlements defined at our LoopBack driver, nothing is returned.

    At the one hand this makes it much more manageable to read a trace (not for me because I had already created a package to filter DirXML-EntitlementRef values :cool:), at the other hand it's now more difficult to deal with entitlements of other drivers like the LoopBack does, which provides for us the functionallity of an self made entitlement service driver for linked User and Organizational role objects. But the ldap query will be a good workaround.
  • On 6/13/2018 2:24 PM, rhaeber wrote:
    >
    > Sorry, I was wrong. The issue is that the result of a query for the
    > attribute DirXML-EntitlementRef contain now -only the values with
    > reference to the drivers own entitlements-.
    > Since there are no entitlements defined at our LoopBack driver, nothing
    > is returned.
    >
    > At the one hand this makes it much more manageable to read a trace (not
    > for me because I had already created a package to filter
    > DirXML-EntitlementRef values :cool:), at the other hand it's now more
    > difficult to deal with entitlements of other drivers like the LoopBack
    > does, which provides for us the functionallity of an self made
    > entitlement service driver for linked User and Organizational role
    > objects. But the ldap query will be a good workaround.


    So similar to David's issue they tried to help, in the engine. Which in
    general is useful, except for when it isn't.

    I would report this in an SR. Some kind of per query add on would be
    useful to enable it. (Not an ECV, since to be most useful you would want
    to use both approaches in one driver)


  • rhaeber wrote:

    > At the one hand this makes it much more manageable to read a trace (not
    > for me because I had already created a package to filter
    > DirXML-EntitlementRef values :cool:), at the other hand it's now more
    > difficult to deal with entitlements of other drivers like the LoopBack
    > does, which provides for us the functionallity of an self made
    > entitlement service driver for linked User and Organizational role
    > objects. But the ldap query will be a good workaround.


    I also created a policy/package to filter unnecessary entitlements/assocs (that
    dn't relate to current driver)
    However this can be useful sometimes and absolutely needs to be an option to
    query *everything* even if the default is to filter.

    --
    If you find this post helpful, and are viewing this using the web, please show
    your appreciation by clicking on the star below
  • geoffc;2482434 wrote:
    On 6/13/2018 8:26 AM, rhaeber wrote:
    >
    > Hi,
    >
    > since a few weeks, probably since the upgrade to Identity Manager 4.7,
    > the attribute -DirXML-EntitlementRef- can no longer be read in the
    > LoopBack driver. That put us in a lot of trouble.
    > A rights problem can be excluded, the driver runs in security
    > equivalence to the admin user. It seems to work in the other driver
    > types used. The current workaround is an LDAP query into the identity
    > vault to get the attribute.
    > Has anyone else had similar experiences and an idea of what is behind
    > it?


    So you think it is shim or engine? I.e. Port the code into some oether
    driver, does it work?

    David Gersic ran into an issue where DirXML-Associations and
    DirxML-AssociationsLite do not query quite correctly, the engine tries
    to help by cleaning up. Entitlemet Ref would make sense to do something
    similar.


    Yeah, that was fun. I was trying to work around a problem introduced by somebody else's business logic that removes the DirXML-Associations attribute on user terminate. (Side note: I hate this idea, please don't do this.) To get around it, I decided to stash a copy of this driver's association in the DirXML-AssociationsLite attribute, then if I get an unassociated modify, grab the stashed association value, and put it back in to the event so that the otherwise orphaned user in the connected system gets updated correctly.

    The problem is that if you query for DirXML-AssociationsLite, the engine tries to help, and instead of giving you what you asked for, it gives you the values of DirXML-Associations. (Side note: I hate it when technology tries to "help" like this. If I asked for a fork, don't give me a claw hammer and claim to have "helped" me.) So, because DirXML-Associations has been removed, my query returned nothing.

    Turns out that if you query for DirXML-AssociationsLite and DirXML-Associations, that bypasses the engine being helpful and you get what you asked for. That's an undocumented feature, at least as of when I was working on this.
  • Verified Answer

    In IDM 4.7, the treatment of this attribute is changed. By default, any driver would receive events only on the changes of that driver’s entitlements. If you want a driver to receive events on other driver’s entitlements, set the ECV( Ignore Entitlement Changes of other drivers) to false for that driver(LoopBack driver in this case).

    Regards,
    Mahesh
  • On 6/21/2018 1:54 PM, rmkreddy wrote:
    > n IDM 4.7, the treatment of this attribute is changed. By default, any
    > driver would receive events only on the changes of that driver�s
    > entitlements. If you want a driver to receive events on other driver�s
    > entitlements, set the ECV( Ignore Entitlement Changes of other drivers)
    > to false for that driver(LoopBack driver in this case).


    I was afraid this was the case.

    On the one hand, I do like this feature. I do like that it is
    configurable, however, I would love a tiny bit more subtlety in the
    configuration.

    On the one hand, doing it per driver is one thing, but I would prefer, a
    way, in a query, perhaps a pseudo attribute that would tell the engine
    to return all.

    I.e. Query for DirXML-EntitlementRef and return attribute [AllDrivers]
    or somesuch to allow you to override it for a specific query. That
    would be helpful.

  • rmkreddy wrote:

    > By default, any
    > driver would receive events only on the changes of that driver�s
    > entitlements.


    So even for existing drivers you default to filtered events? That this would
    break a lot driver logic seems obvious, almost all of my customers have at
    least one driver that reads other driver's associations.
    I'd really prefer to see this as a default for new drivers only while any
    existing updated driver should stick with the old behavior.

    --
    http://www.is4it.de/en/solution/identity-access-management/

    (If you find this post helpful, please click on the star below.)
  • Lothar Haeger <lothar.haeger@is4it.de> wrote:
    > rmkreddy wrote:
    >
    > So even for existing drivers you default to filtered events? That this would
    > break a lot driver logic seems obvious, almost all of my customers have at
    > least one driver that reads other driver's associations.
    > I'd really prefer to see this as a default for new drivers only while any
    > existing updated driver should stick with the old behavior.
    >


    This spears to only be for entitlements. At least as mentioned here.

    David confused the issue talking about the engine changes for
    dirxml-associationslite. Which is a completely different change that
    shipped in an earlier IDM release.
  • Geoffrey Carman <geoffreycarmanNOSPAM@NOSPAMgmail.com> wrote:
    > On 6/21/2018 1:54 PM, rmkreddy wrote:
    >> n IDM 4.7, the treatment of this attribute is changed. By default, any
    >> driver would receive events only on the changes of that driver�s
    >> entitlements. If you want a driver to receive events on other driver�s
    >> entitlements, set the ECV( Ignore Entitlement Changes of other drivers)
    >> to false for that driver(LoopBack driver in this case).

    >
    > I was afraid this was the case.
    >
    > On the one hand, I do like this feature. I do like that it is
    > configurable, however, I would love a tiny bit more subtlety in the
    > configuration.
    >
    > On the one hand, doing it per driver is one thing, but I would prefer, a
    > way, in a query, perhaps a pseudo attribute that would tell the engine
    > to return all.
    >
    > I.e. Query for DirXML-EntitlementRef and return attribute [AllDrivers]
    > or somesuch to allow you to override it for a specific query. That
    > would be helpful.
    >


    I am super happy with this change as-is. It will fix a lot of odd issues in
    edge case scenarios.