1 / 54

ITIM 4.6 - Common Lifecycle Operation Modifications

ITIM 4.6 - Common Lifecycle Operation Modifications. Agenda. Introductions Basic overview of Lifecycle Operations and Entitlement Workflows Overview of the Workflow Designer and components Scenarios Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows.

roderick-jake
Download Presentation

ITIM 4.6 - Common Lifecycle Operation Modifications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ITIM 4.6 - Common Lifecycle Operation Modifications

  2. Agenda • Introductions • Basic overview of Lifecycle Operations and Entitlement Workflows • Overview of the Workflow Designer and components • Scenarios • Techniques for troubleshooting problems with Lifecycle Operations and Entitlement Workflows.

  3. Introductions • Fon KwokUS: ITIM L2 Support Engineeremail: fkwok@us.ibm.comphone: 714-438-5112

  4. Basic Overview of Lifecycle Operations and Entitlement Workflows • Similarities: • Approvals, RFI’s, WorkOrders. These nodes are available in all operations. • Scripting (data manipulation, etc). • Modifying the behavior of ITIM (doesn’t require writing custom Java code). • Differences: • Lifecycle Operations: any action on Accounts and Person objects • Entitlement Workflows: only for Add/Modify on Account objects. • Lifecycle Operations: effective after saved, and profile cache is refreshed. • Entitlement Workflows: only effective, after added to a Provisioning Policy, and only effects those Accounts that are associated with that Policy. • “Subprocess”, can only be called in an Entitlement Workflow. • Only Lifecycle Operations can be used with a Lifecycle Rule.

  5. Overview of the Workflow Designer and components • Workflow Designer is a Java Applet that is used to configure the Lifecycle Operations and Entitlement Workflows. • Components: • Nodes: • Approval: requires approval/rejection from participant • RFI: requires information from participant • Operation: calls an existing Operation (Person>Modify from Account>Add). • Loop: loops until conditions are met • Extension: performs a single action (modifyAccount, suspendPerson, etc). • Script: JavaScript • Work Order: sends notification to a participant, and can create a To-Do Item. • Subprocess (only available in Entitlement Workflows): Calls an Entitlement Workflow, from another Entitlement Workflow. • Transitions: • The connectors between nodes. • Are used to route the request through the Operation/Workflow. • Can contain JavaScript.

  6. Overview of the Workflow Designer and components (cont.)

  7. Overview of the Workflow Designer and components (cont.) • Data • Input Parameters: data that enters into the workflow/operation, and is used to perform the function. (Static) • Output Parameters: Only supported in Entitlement Workflows. The resulting data of the workflow. • Relevant Data: global variable data within the Workflow/Operation. Can be used to pass data from one activity to the next. JavaScript can be used to retrieve/modify/set Relevant Data. • Accessed by clicking the “Properties” button in the Workflow Designer • The default Input/Output Params and Relevant Data, will differ between Entities, Operations, Workflows.

  8. Overview of the Workflow Designer and components (cont.)

  9. JavaScript methods • JavaScript methods used in the scenarios: • x.get(); retrieves the object • x.getProperty(‘attributeName’); retrieves the attribute value • x.setProperty(‘attributeName’,value); sets an attribute value • x.set(y); pushes the object back into the workflow for later use • process.requestorType; returns the type of requestor (system, user) • process.getRootRequesterName(); name of the requestor for root request • PersonSearch().searchByFilter(profile,filter,scope); searches for (and returns) a person object.

  10. Overview of the Scenarios: • Case 1: Sponsor lookup during BPPerson dataload. • Case 2: Dynamically change Service data, while processing requests. • Case 3: Update Person object with Account data. • Case 4: Dynamically change account data during requests. • Case 5: Prevent the ITIM System from deleting accounts.

  11. ITIM Entities

  12. Scenario 1: Sponsor lookup during BPPerson dataload. • The Sponsor (erSponsor) attribute on BPPerson objects, behaves similar to the Supervisor attribute on Person objects. This attribute contains a DN that points to another BPPerson object. • Previously a bug existed where ITIM does not handle the lookup of erSponsor’s value during datafeed, as it does erSupervisor’s. (NOTE: this has been fixed in ITIM 4.6 IF10 APAR IY80890) • Previously, in order to get the erSponsor value loaded successfully, you would have to pass a valid DN for this attribute in the feed. For Person objects, you can use a common name or an attribute/value pair. • In this scenario, we use a Script node to perform the same type of lookup for the erSponsor, as ITIM would normally do for the erSupervisor attribute. • This scenario will show how to modify the ITIM Operations to workaround bugs/limitations.

  13. Add BPPerson Workflow (before and after)

  14. Sponsor Lookup Script

  15. Sponsor Lookup Script • In this script the following occurs: • Check for the requestor type (ie is this a system generated request or a manual user request?). Specifically not U (which means that a user is triggering an event. We want it to be looking for datafeed processes) • Get the Person entity • Get the Person’s Sponsor value (which is a filter such as “employeenumber=55555”) • Search for the Sponsor’s DN using that filter value. • Return the new Sponsor DN in the Sponsor attribute

  16. End Result for Scenario 1 • Run the datafeed again with user Tom Jones • The script finds the corresponding sponsor value.

  17. Scenario 2: Dynamically change Service data, while processing requests. • Some Services contain parameters to help limit the management scope of that service on the remote platform. Normally, a separate service for each scope would have to be created, in ITIM. • This scenario will show how to dynamically modify Service parameters, at runtime, in order to limit/expand the management scope of the Service on the remote platform. • Most commonly used with AD and RACF Service types. • AD: Base Point, Domain ID/PWD. • RACF: RACF ID….

  18. Existing AD Service Base Point

  19. Add AD Account Workflow (before and after)

  20. Set Basepoint Script

  21. Set Basepoint Script • The script will do the following: • Get the Account owner (Person) • Get the Service entity • Get the owner’s title • Check if the title is a Contractor, and if so, set a new basepoint

  22. End Result for Scenario 2 • Add a new AD account for a Person who’s title is Contractor • The new AD account will be created in the “Contractors” container

  23. Scenario 3: Update Person object with Account data. • In most Customer environments, Person data needs to be updated with information that was not available during the DataFeed.Example: Most Person data is loaded into ITIM without a valid email address. The email address is usually created when the Person’s email account is provisioned (via ITIM). • This scenario will show how to update a Person object with a valid email address, once the Person has been provisioned an email account (ADAccount). • This can be used to update the Person object with virtually any Account data (example: erUid -> erAliases).

  24. Add AD Account Workflow (before and after)

  25. Update Person Email Script

  26. Update Person Email Script • This script does the following: • Get the Account entity • Get the Account owner (Person) • Get the Account’s mail property • Populate this into the owner’s mail property

  27. Add AD Account Workflow

  28. Modify Person Operation

  29. End Result for Scenario 3 • A new AD account is created for a Person. This account contains a new email address • The email address is now populated in the Person object under the “Communications Information” tab

  30. Scenario 4: Dynamically change account data during requests. • This scenario will show how to dynamically modify account data, during a request, based on the request data. • Quite a few customers have requested that ITIM expire account passwords, whenever Help Desk/Admins/etc. reset passwords for a user. But if the owner of the account resets their account password, the password should not be expired. • Based on the requester of changePassword, the Operation will either cause the account’s password to be expired….or will leave the password active.

  31. Setting up AD Account Change Pwd Workflow

  32. Adding Relevant Data objects

  33. Adding Relevant Data objects

  34. Change AD Account Password Workflow (before and after)

  35. Check Requestor Script

  36. Check Requestor Script • The script does the following: • Get the Account entity • Gets the owner of the Account (Person entity) • Gets the Person’s cn • Sets the Person relevant data object • Gets the Account’s service name • Sets the Account relevant data object • Gets the process’s requestor name • Compare it to the Person’s cn, and set the isOwner flag accordingly.

  37. Change AD Account Password Workflow

  38. Workflow with all relevant data objects added

  39. Change AD Account Password Workflow (before and after)

  40. Transition Node • If the person requesting the AD password change is the owner, then go to the “End” of workflow.

  41. Transition Node • If the person requesting the AD password change is not the owner, then go to the change password node.

  42. End Result for Scenario 4 • Logged in as “ITIM Manager”, we change the AD password for Chuck Wilson • Check the Chuck Wilson account in Active Directory, and you will see that the “User must change password at next logon” is enabled.

  43. Scenario 5: Prevent the ITIM System from deleting accounts. • In order to keep accounts compliant with the ITIM Policies, the Policy Enforcement Action must be set to “Correct”. • The risk of this configuration, is that ITIM will deprovision accounts that are found to be “not allowed”. • Many customers do NOT want ITIM to deprovision accounts, unless specifically requests by a user/admin (non-system). • Customers could replace the ‘deleteAccount’ extension (in the ‘delete’ Operation), with a ‘suspendAccount’ extension….but this would prevent even manual delete requests from deprovisioning accounts. • This scenario shows how to configure the ‘delete’ Operation to allow manual delete requests, but prevent the ITIM System from automatically deleting accounts.

  44. Setting up AD Account Delete Workflow

  45. Adding Relevant Data objects

  46. Delete AD Account Workflow (before and after)

  47. Check Requestor ID script • This script checks the requestor type. If it is System (S), then set the String relevant data object accordingly (this will be processed by the Transition node)

  48. Delete AD Account Workflow

  49. Transition Node • If the requestor is the System, then go to the “End” of workflow. • If the requestor is an ITIM user, then go to the Delete account node

  50. End Result for Scenario 5 • The Person object “Chuck Wilson” belongs to the “AD Users” organization role. This allows him to have an AD account. • We remove Chuck from this organization role. • ITIM normally deletes the account (based on Correct Noncompliance). However, the workflow will find that the requestor was System, and will leave the account under Chuck Wilson as “Not Allowed”

More Related