X hits on this document





16 / 28


For HR events that represent other types of updates, such as add and modify requests, the Directory Update Application must filter those requests against the Block List to ensure that people who have been blocked byway of the Emergency Block process are not inadvertently added back to the Master Directory.

Likewise, when the Emergency Block Application is used to unblock an employee, the Directory Update Application must be able to restore the person's entry when they are removed from the Block List, allowing for normal HR feeds for this person.

The logic regarding which events should be filtered and not filtered can become complex. This is why the individual trusted sources for personnel information should not be given direct access to the Master Directory. Instead, the Directory Update Application should be the only application with authority to change the Master Directory. The Directory Update Application becomes both a centralized place to enforce blocking logic and audit checkpoint to log the receipt and processing of HR update events.

HR event broadcasting process

The changes made by the Directory Update Application to the Master Directory represent the changes that need to be reflected across the IT environment. In particular, when a person's UID is removed from the Master Directory, a trigger for an offboarding event for IT systems that have accounts and credentials for that person must be initiated.

There may be many changes to the Master Directory due to other HR processes that are not relevant to offboarding. The on/offboard trigger process filters the Master Directory change log and builds the appropriate on/offboarding events, which are then passed to the On/Offboarding Service Bus.

The On/Offboarding Service Bus maintains a list of subscribing Identity Management Servers to ensure delivery of the on/offboarding events to each of the subscribers. The delivery mechanism may involve either push or pull mechanisms. The On/Offboarding Service Bus is also an important audit check point. It must store audit records into the Offboarding Event Audit Server for every on/offboarding event it receives and it must create an audit event for each HR event successfully delivered to an Identity Management Server.

Given the fact that the On/Offboarding Service Bus must interact with so many different IT systems, it is important that it is designed to support asynchronous message transfer and message queuing.

Also, because the HR events may contain sensitive information, the storage and transmission of the on/offboarding events through the service bus to the Identity Management Servers should be encrypted to ensure that administrators do not see which employees have been blocked or offboarded.

Identity management processes

The identity management processes are responsible for interacting with IT systems and making modifications/additions/deletions to user registries and credential systems in response to the on/offboarding events.

Identity Management Servers

Identity Management Servers are responsible for interacting with IT changes to add/change/delete accounts and entitlements in the IT systems they manage. An Identity Management Server may be the authoritative account change source for one or more IT systems.

Using the IBM Security Blueprint to Address Business Risks for Employee Offboarding

Document info
Document views67
Page views68
Page last viewedWed Oct 26 07:48:38 UTC 2016