• State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 94 subscribers
  • Views 1686 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Manual provisioning integration with target systems

akuzmin
over 5 years ago

Hi,

now we have a case where we have to integrate a system with One Identity Manager through manual provisioning. For example, a user create a request for access to the system, and when a request is approved the administrator of a system give an access for the user in a system manually, IDM doesn't make a provisionong operations in a system.

Now we see two way for solve this case:

1. When a request approved of all approvers the request come to the last step of approval workflow (Admins of a custom system). Admins make a changes in a system manually and then "approve" this request on their step.

2. When a request approved of all approvers provisioning processes start (for example processes of event Insert to ADSAccountInADSGroup table). In that processes we create a request to the Admins of a system to make a changes.

What way do you prefer? What are the best practice for this case? What do you think?

Thank you.

  • 0 over 5 years ago

    I don't think there is a single best practice for manual provisioning, as it depends on your requirements.

    For a manually-provisioned application you could simply define resources or system roles as requestable items and use Option 1. This has an advantage of being easy to setup. Another advantage is that the admins receiving 'provisioning approvals' will see all tasks that have passed the approval steps, even where valid from dates are in the future, and can thus plan work accordingly. A downside is that getting any KPIs for approvals becomes harder as you're approval combines both approval and provisioning.

    With option 2 you are responding to a completed request and leveraging an OotB or custom target system. Custom processes react to provisioning changes to the target system, such as a change to group membership. The advantage of modelling the application within a 1IM target system is that you can treat it like any other application from the perspective of disabling accounts, attestation, reporting, SoD rules etc. A downside of this is that provisioning tasks are only actioned after the valid from has passed, which means that the recipient may not receive their access in a timely manner wher applications have long provisioning SLAs.

    With either approach you'll need to define a robust, generic approach for identifying the admins for a particular application so that you can reuse this approach for multiple applications whilst minimising the number of customisations, e.g. mail templates, workflows, and processes.