Conditionally sync based on role

This topic has 4 replies, 3 voices, and was last updated 6 years, 3 months ago by Andrew Potter.

  • Author
  • #11505

    Hi, if I want to conditionally sync users to AD is it using a role that’s the best way to achieve this?

    Say adding a ActiveDirectory role and then a Assignment of provision2AD. Then in the validSource look at provsion2AD if it’s true or not ?


    You can do something similar to this in validSource script:

    require(‘lib/lodash’).some(source.effectiveAssignments || [], { mapping: ‘nameOfYourAdMapping’ })

     Andrew Potter

    There are many ways to achieve it…what’s ‘best’ depends on many things.
    But… I’ve done the following in the past:
    – Ensure Managed User has a ‘userType’ field. This might be set to ‘internal’ or something else.
    Our business logic says that only ‘internal’ userTypes are provisioned to AD.
    – Therefore in the MU->AD mapping set a validSource such as source.userType=’internal’;

    Not better/best just another way.

    However, I would say that the ‘Assignments’ method is probably a misunderstanding of the Assignments capability. Assignments are typically used to provision actual entitlements such as AD attributes/group memberships. i.e. an Assignment is defined with specific AD group memberships. Then it is attached to a Role and a Mapping. Then anyone with that Role that is synced by the mapping will get provisioned with the AD attribute/group.

    Check out the sample for assignments:!/docs/openidm/4/samples-guide#more-sample-roles-prov
    And the integrators guide:!/docs/openidm/4/integrators-guide#working-with-role-assignments


    > However, I would say that the ‘Assignments’ method is probably a misunderstanding of the Assignments capability

    That is an interesting point of view and I hope that is not how it is. Using assignments as indication whether the user is eligible to have account in the integrated system is in my opinion basic RBAC feature.

     Andrew Potter

    Ok, let me rephrase that. Assignments in IDM *can* do more than just ‘indicate’. It has specific capability to provision specific attributes/group memberships in the mapped system based on the IDM roles assigned to the user.
    For example, a Role (‘Internal’) in IDM might have multiple Assignments. Assignment 1 might set an attribute and add the user to Group X in AD. Assignment 2 might ensure that the user is a member of Group A and B in LDAP. Assignment 3 might do something else in SQL.
    If I now add the ‘Internal’ role to a user in IDM it will ensure that the appropriate ‘entitlements’ as defined by the Assignments are set in the connected systems (AD, LDAP, SQL).
    You can of course use the membership of an IDM Role to determine whether a user should be included in the source of the mapping rather than an explicit attribute.
    Or feel free to use the Assignment (given that this is related to the Role) as you suggest as way of determining whether a user should be included. Like I say, there are many ways to do this! I just wanted to ensure the complete power of Assignments to provision ‘entitlements’ in IDM 4 is understood.
    It’s definitely worth working through the sample to grasp this power.

    One way of looking at it is that Assignments are designed to determine *what* a user should get when provisioned in the connected system. You can also use them to determine *whether* a user should be provisioned in the system or not – but there are lots of other ways to determine this too.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?