5 Replies Latest reply: Feb 19, 2013 12:37 AM by User253154 RSS

    Design Considerations

    user10136614
      Hi,

      I am trying to develop a automated process in OIM where I have the below envrionment -

      Organizations
      Org1 to Org40 (40 Organizations). There are 40 diff organizations created in OIM

      Roles
      X1 to X40 (Organization specific roles). There are 40 standard roles created in OIM

      Groups in target ldap
      X1 to X40 (groups in target). There are 40 groups in ldap. The role name in OIM and the groups in the ldap are same

      Now I am trying to achive the below requirements -

      1. Roles should be assigned to the user depending on the org.
      Example: If a user is created in org1, role X1 in OIM should be automatically assigned to the user.

      2. All users should be provisioned with a ldap account

      3. Users should be assigned to appropriate group in the target ldap.
      Example: If a user is created in org1 user should be assigned to X1 role in OIM and should be assigned to X1 group in target ldap

      what should be the design in the above scenario?
      1 - can be achieved using membership rules.
      2 - provisioning to a ldap resource can be initiated with access policy
      3 - How should this be handled? Since groups can be mapped in child entries while creating access policy, is it a good design to create multiple access policies?
      For example in this scenario will it be good to create 40 access policies where I assign the appropriate group to the child form while selecting the
      resource to be provisioned?

      Please help.


      Thanks
        • 1. Re: Design Considerations
          user10136614
          Can anyone please provide inputs or share their thoughts?
          • 2. Re: Design Considerations
            Suren.Khatana
            Hi,
            Yes, you should use Access Policies , membership rules ,Roles to achieve the use case and in different Access Policies you can specify the different LDAP groups that needs to be provisioned .
            This is a standard design .


            Thanks
            Suren
            • 3. Re: Design Considerations
              user10136614
              So does that mean here in this case I should go ahead creating 40 access policy and even more if required in future? Creating access policy is time consuming. What is I develop an event handler and add use it to grant/provision group in target? In this case only one access policy is required.

              which will have more weightage in terms of design? and which one is a suggested approach? Please advice
              • 4. Re: Design Considerations
                user10136614
                So does that mean here in this case I should go ahead creating 40 access policy and even more if required in future? Creating access policy is time consuming. What is I develop an event handler and add use it to grant/provision group in target? In this case only one access policy is required.

                which will have more weightage in terms of design? and which one is a suggested approach? Please advice
                • 5. Re: Design Considerations
                  User253154
                  I would say creating access policy would be better , since it is an expandable framework . Technically it may work with event handler but you will have to do assignment - de assignment etc ..all on your own .
                  Ideally when we to create large number of Access policies , better write an utility and give it a feed in terms of Role, resource , child table grp etc and it will generate APs for you . Anyhow , it just an one time activity .


                  Thnx
                  Suren