Topic
9 replies Latest Post - ‏2012-10-17T17:55:10Z by dgowda
SystemAdmin
SystemAdmin
9855 Posts
ACCEPTED ANSWER

Pinned topic Determine request origin in ITIM 5.1 provisioning policy

‏2012-10-12T04:36:20Z |
Hi, I need to implement a different provisioning logic based on the origin of the request. That is, if the request is manually submitted by a user, all AD groups are allowed in the provisioning policy; however, if the request is originated by reconciliation (configured for correct non-compliance), only the existing AD groups in AD account (on ITIM side) are allowed so that any additional AD groups in AD account (on target side) will be removed.

Any idea how to determine the request origin (i.e. manually submitted or reconciliation) in ITIM provisioning policy? I know we can use something like process.getRootRequesterName() in ITIM workflow to achieve this, but not in ITIM provisioning policy.

Thanks.
Updated on 2012-10-17T17:55:10Z at 2012-10-17T17:55:10Z by dgowda
  • SystemAdmin
    SystemAdmin
    9855 Posts
    ACCEPTED ANSWER

    Re: Determine request origin in ITIM 5.1 provisioning policy

    ‏2012-10-12T05:40:02Z  in response to SystemAdmin
    This is very strange requirement IMHO.....

    You can control the ability of users to add groups to their accounts using ACIs - is that not the correct way to solve this issue ?

    Normally ITIM should be considered the "Master" - the requirement you propose would mean that the AD is the master and ITIM is a sub system to that - that is contrary to the design of ITIM.

    I do not believe you can solve it in Provisioning Policy logic - but you could solve it workflow operations - the change object combined with the process.getRootRequesterName() - but this is really not a good idea.

    HTH

    Regards
    Franz Wolfhagen
    • yn2000
      yn2000
      1075 Posts
      ACCEPTED ANSWER

      Re: Determine request origin in ITIM 5.1 provisioning policy

      ‏2012-10-12T14:02:41Z  in response to SystemAdmin
      So true. IBM uses the word 'Policy' in the name for a reason.
      Imagine this... My 'security badge' allows me to access to the 'computer lab', if I use front door. My 'security badge' denies my access to 'computer lab', if I enter from the parking garage.
      Rgds. YN.
      • SystemAdmin
        SystemAdmin
        9855 Posts
        ACCEPTED ANSWER

        Re: Determine request origin in ITIM 5.1 provisioning policy

        ‏2012-10-14T23:25:12Z  in response to yn2000
        I think there is some misunderstanding here. I should have described the issue in a better way. The main problem is that (i) there is a requirement to allow an admin to add/remove groups from accounts from ITIM console, while (ii) another requirement states any groups added to accounts in target side must be removed when running reconciliation (so basically enforcing correct non-compliance).

        One way to meet the first requirement is to set "allow all groups" in provisioning policy, however this will break the second requirement. Moreover, one way to satisfy the second requirement is to set "allow only existing groups in account" in provisioning policy, however this will violate the first requirement. Therefore, the real question is how to fulfill both requirements? Is there a solution for that?

        Thanks.
        • SystemAdmin
          SystemAdmin
          9855 Posts
          ACCEPTED ANSWER

          Re: Determine request origin in ITIM 5.1 provisioning policy

          ‏2012-10-15T06:41:54Z  in response to SystemAdmin
          I believe what you describe is what IBM calls the "hybrid" provisioning model - some part is RBAC (correct compliance) and some is request based. The problem is although that the hybrid model is easy to implement if you ensure that services is either request based or RBAC - but a challenge if you need RBAC and request based provisioning on the same service....

          Let me explain what we (the team I work in at IBM services) see as possibilities for AD (where it is "relatively easy" to implement) :

          First - to make this work we need to have "correct compliance" switched on as nothing works automatically if not...
          The next step is divide groups into a managed set (RBAC) and an unmanaged set (Request based). This is the trick...

          There are couple of possibilities :

          1.Use naming conventions - e.g. all managed groups is having a distinct prefix/suffix like RBAC_ or whatever... (this is not the best solution)
          2.Switch your AD group naming to DN and put you managed groups into specific OU (This is what we normally recommend).
          3.Some other creative way of partitioning your groups :-)

          Now - the last thing is now to build you provisioning policies that you basically allow all unmanaged groups - the easiest way to do so is to allow via a regular expression (and that is why dividing the managed groups into a specific naming scheme is way to solve the problem). Every other group should be default prohibited (null returned).

          As you can imagine this takes some effort to implement - especially if you go the DN way (which I recommend) as you have to go through and change all your current policies...

          HTH

          Regards
          Franz Wolfhagen
          • yn2000
            yn2000
            1075 Posts
            ACCEPTED ANSWER

            Re: Determine request origin in ITIM 5.1 provisioning policy

            ‏2012-10-15T13:28:49Z  in response to SystemAdmin
            It seems that there is another misunderstanding again here (or maybe I was the one that misunderstood again), because it sounds like...
            • Theoz posts a requirement to 'allow' change in ITIM, but 'not allow' change in AD (because any change in AD is to be corrected)
            • Franz solution is to 'allow' change in ITIM, but also 'allow' change in AD, where Franz uses a partitioning agreement between ITIM admin versus AD admin.

            For now, I am sticking with my opinion, where Security Policy is a central decision from the top.
            First, If nobody is allowed to change the group in AD, because ITIM will overwrite the change, why don't you just put ACL in AD, so that nobody is allowed to modify the group membership in AD in the first place? Second, I can accept Franz solution, but I still don't like the idea of everybody is allowed to modify group membership everywhere, because it is an auditing nightmare.

            Rgds. YN.
            • jmdennis
              jmdennis
              52 Posts
              ACCEPTED ANSWER

              Re: Determine request origin in ITIM 5.1 provisioning policy

              ‏2012-10-15T16:11:05Z  in response to yn2000
              I'm interpreting it as you have YN, or more simply:

              Theoz wants nobody but ITIM admins to change AD groups.

              As always, I think any solution needs to be documented and reviewed but here is an option:

              Controlling who can change the groups via ITIM is simple: create the ACI/group.

              The 2nd requirement is the tough one. As Franz indicated, this would be a hybrid approach combining request based provisioning and RBAC - always a headache. The key to this option is setting up a flag attribute that you could use to mark the accounts when they are created in ITIM. The account Add workflow would need to be modified to set the flag. (I'm not getting into details of adding a new attribute) On the provisioning policy you would add the AD groups parameter with Enforcement Type set to Excluded and Parameter Type set to JavaScript. In the JavaScript you would write your code to check the newly added creation flag and return the appropriate Boolean value. Theoretically, this option should result in policy enforcement to exclude groups not created via ITIM. There are of course, Pros and Cons to this.
              jdennis
              • SystemAdmin
                SystemAdmin
                9855 Posts
                ACCEPTED ANSWER

                Re: Determine request origin in ITIM 5.1 provisioning policy

                ‏2012-10-16T06:05:28Z  in response to jmdennis
                You cannot override any explicitly/implicitly allowed values using the excluded provisioning directive.... That is not how it works - currently exclude means that anything (implicitly allow) that is not excluded is allowed...

                Hence you need to work out the problem with allowed values vs. null in the policies.

                We really need a "override exclude" to make this easier - but that another story.

                As for YN's coment - we should not mix governance and the technical implementation - it is important that the implementation you choose supports any governance of groups as it may change over time - my point in the sketched solution is that you can based on the criteria you choose can move any group from the one set to another...

                But apart from that I agrre that governance should reside in ITIM - that is the whole purpose of the system....
                • jmdennis
                  jmdennis
                  52 Posts
                  ACCEPTED ANSWER

                  Re: Determine request origin in ITIM 5.1 provisioning policy

                  ‏2012-10-16T10:57:56Z  in response to SystemAdmin
                  Franz, Not sure what you mean by "You cannot override any explicitly/implicitly allowed values using the excluded provisioning directive". In the past, we've been able to exclude ranges of groups or specific groups using the exclusion directive while still allowing other groups. The set of groups we allowed were mutually exclusive to the groups not allowed. Can you clarify?

                  jdennis
        • dgowda
          dgowda
          42 Posts
          ACCEPTED ANSWER

          Re: Determine request origin in ITIM 5.1 provisioning policy

          ‏2012-10-17T17:55:10Z  in response to SystemAdmin
          It may sound very cumbersome, but I have a suggestion: Create a automatic provisioning policy and role for each AD group (or bunches of groups) and allow only those users in the roles (named after the AD groups) to be part of the defined AD group. When the admins want to add a user to a AD group, they add the appropriate role to the user, which will automatically add the group to the user's AD account. If you set the compliance to enforce and the system sees a user in a group without a corresponding role in their identity, it will automatically be stripped.