Oracle Identity Manager 11gR2-PS2 Hands-on Workshop
Tech Deep Dive – Catalog, Access Request and Approval Workflow [email protected]
Principal Product Manager, Oracle Identity Governance
2 Oracle Confidential – Do Not Distribute
Agenda
• Catalog Concepts • Catalog Harvesting - Building Initial Catalog
• Ongoing Synchronization
• Data Enrichment
• Extend Catalog
• Catalog Security
• Request Profile
• Hierarchical/Browsable Catalog/Catalog Taskflows
• Catalog Audit
• OIM-SOA interaction
• Build and Deploy Approval Workflows
• Concepts – SOA Composite, BPEL process, Human Task, Serial/Parallel Assignment,
Callback, OWSM protection
• Request Management configurations in OIM - Approval Policies
3 Oracle Confidential – Do Not Distribute
Agenda
• Extension Points • Additional Information in Request
• Request Validation Plug-in
• Request Pre-populate Plug-in
• Diagnostics and Monitoring
• Important Links
4 Oracle Confidential – Do Not Distribute
Introduction to Catalog
• What is Catalog?
• Collection of Request able Entity like:
• Role
• Entitlement
• Application Instance
• Shopping card paradigm.
• User can search for the items and make request for himself and for
others.
5 Oracle Confidential – Do Not Distribute
Key Features - Catalog
• Extensible Catalog schema that allows administrators to add additional
attributes and specify how the attribute is rendered using a simple
browser-based UI.
• Automated harvesting of roles, applications, and entitlements
• Automated loading of Catalog metadata using a CSV file
• Powerful search using keywords with support for complex search
operators
• Flexible categorization model that allows the Catalog to be organized
based on customer choice
• Catalog search results secured based on viewer privileges of the
requester
• Catalog item data available via a web service for use in workflows
8 Oracle Confidential – Do Not Distribute 8
Catalog Configuration
Harvesting
Process of populating Catalog
Base Entity creation
Role - Create, OIA Integration can bring roles into OIM
App instance – Created by the admin
Entitlement
Have app instance created for underlying IT resource
Ensure form properties are set - Entitlement = true
Connector lookup recon, bring in LKU
ENT synch job
Navigate to app instance, open entitlements and describe
Catalog Harvesting
Role, App instance – automatic
Entitlement - Catalog synch scheduled task
9 Oracle Confidential – Do Not Distribute 9
Catalog Configuration
Extend Catalog
Add UDF on catalog form using form designer
UI customization of catalog page, add field
Data Enrichment (empower tagged searches, filtered by category, risk flagged by colors)
Manual - catalog admin role. Edit Category, Audit Objective, Risk Level and User Defined Tags attributes. Name, display name and Description comes from base entity.
Bulk - check IT resource key, prepare CSV, run catalog synch (metadata mode)
API
Configure Security
Publish catalog (base entities) to respective organizations
Roles
Application Instances (with or without Entitlements)
Specific Entitlements
10 Oracle Confidential – Do Not Distribute
Seeding Hierarchical Information
• Hierarchical Information is populated in Catalog_hierarchical_ATTR table, by
running Catalog Synchronization job.
• Mode for Running job is “Technical Glossary”
• Parameters it take is the path of Directory which contains XML file.
• It creates two directory in the directory containing XML to be processed,
they are:
• XMLProcessedLogs
• This has logs which informs any failure related to processing.
• archive
• Any file that has been processed is moved to this directory with
timestamp attached to the name.
10
12 Oracle Confidential – Do Not Distribute
12
Job Parameters
• Mode
• Full
• Incremental
• Metadata
• Recalculate tags
• Technical Glossary
• Update Date
• Date after which data will be picked for processing. Can be left blank for Complete processing.
• Process Entitlement
• Yes
• No
• Process Role
• Yes
• No
• Process Application Instance
• Yes
• No
• File path
• Complete file path with file name from where file will be picked for processing.
13 Oracle Confidential – Do Not Distribute
Requirement • Auditing support for “Access Request Catalog” level sensitive data changes for e.g. below is list of few
attribute where changes needs to be Audited
Approver, Certifier and Fulfillment User
Approver, Certifier and Fulfillment Role
Risk Level
• Capability of ‘who have change what and when’ in catalog
Deliverable • NO OOTB Reports
• Catalog Audit Database schema/table structure is documented this will be used to generate report through BI.
Catalog Audit
14 Oracle Confidential – Do Not Distribute
• Inline with existing OIM Auditing Engine
• Tweak the implementation by avoiding initial snapshot. This way we have avoided the performance issue which exists in OIM auditing engine.
• Used existing J2EE resources which leads no Installer impact.
• On demand(Enable/Disable capability through ‘Catalog Audit Data Collection’ system property.)
• No upgrade impact
Catalog Audit Architecture & Highlighted points
17 Oracle Confidential – Do Not Distribute
SOA Composites Basics
• OOTB SOA Composites have a BPEL Process and a
Human task.
• Serial/Parallel Assignment
• Payload structure • String Type: RequestID, RequestModel, RequestTarget, URL
• XML Element: RequesterDetails, BeneficiaryDetails, ObjectDetails, OtherDetails
• Last step in the Composite should be invocation of
Request CallbackService with the outcome.
• Outcome should be one of “approved, rejected”.
21 Oracle Confidential – Do Not Distribute 21
Approval Workflow Configuration
Same SOA based technology for both scenarios
Request Approval
Disconnected resource fulfillment
Best Practices adoption
"Generic" composite, model "business process" irrespective of "IT facts" (Active directory, EBS, Database).
Approvals driven by "compliance objectives" and "data ownership", leveraging the enriched catalog metadata - Risk level, audit objective, approver, manual
Business agility - Business analysts can edit approval workflow logic without development/IT involvement/redevelopment/redeployment. Done through SOA composer
Effectively leveraging Open stds & SOA technology - Web services, XSDs, WS-Security, Business rules.
Request Web service (reqsvc)
XSDs - User, Role, Org, Request (request and general request), App Instance, Entitlement, Resource, Account, Catalog item, Fault data
WSDL - Operations to get data for all the above mentioned entities in the same datastructure as defined by the XSD files
Secured by default with username token policy and exposes CSF key to clients.
22 Oracle Confidential – Do Not Distribute 22
Approval Workflow Configuration
0. Add WSDL amnd XSDs w.r.t the request web service to the project. Also add BusinessRule XSD which has the data structure defined to capture details of actual approval/human task which should get invoked.
1. Partner link to OIM Request webservice, client side security configurations
2. Assign activity, for setting request webservice URL to partner link
3. oim request paylod sent to soa, having basic request + catalog data. Assign activity to take request key from payload and pass it to Invoke Request Details operation
4. Invoke Request Details operation calls OIM request webservice thru partner link and get ALL possible Request data (RequestData)
5. Assign Activity to take Catalog entity key and entity type from request data and pass it to Invoke Catalog Details operation
6. Invoke Catalog Details operation calls OIM request webservice thru partner link and get ALL possible Catalog entity data (CatalogData)
7. Assign activity to take ALL possible Catalog entity data (CatalogData) and assign it to global variable "catalogData".
8. Create variable "workflowstage", datatype as StageOutput (BusinessRules xsd).
23 Oracle Confidential – Do Not Distribute 23
Approval Workflow Configuration
9. Create a business rule, "workflow selection" and have the following conditions modeled in there. Input is variable "catalogData" and output is variable "workflowStage"
IF
catalog item == ROLE
AND
IF
risk == 3 (low)
THEN
stageType = Auto
IF
catalog item != ROLE
AND
IF
risk == 3 (low)
THEN
stageType = Manager
IF
risk == 5 (medium)
THEN
stageType = Parallel (Beneficiary Manager (User) || Audit Review Team(Role))
IF
risk == 7 (High)
THEN
stageType = Serial (Beneficiary Manager (User) Audit Review Team(Role))
24 Oracle Confidential – Do Not Distribute 24
Approval Workflow Configuration
10. Switch activity After the business rule for workflow selection- conditions a)Manager, b)Parallel and c)Serial approval. Conditions met when StageOutput received from business rule.
11. Add Human task for each condition 11.1 Set task params
11.2 Actionable notfn. Escalation reminders
11.3 Parameterized Task details
11.2 Add stages to the Human task based on the desired logic.
11.4 In each stage, connect that to a business rule, which should
IF (any task)
THEN CORRESPONDING APPROVER (user)
12. Define source values for Task parameters, using what we have from payload
13. Set identification key as request ID
14. Map output to the response.
15. Deploy workflow
16. Create Approval policies (IT details agnostic ), no logic in rules, use them as dummy connection between OIM SOA Composite
25 Oracle Confidential – Do Not Distribute
Access Request - What’s more new in R2?
• Empowered by catalog, support for multiple first class entries
• Request Lifecycle & Heterogeneous requests
• Adoption of a unified Security Model
• SOA Tasklist (taskflow) adoption in Task assignment UI - Unified Inbox
• Edit Approval workflows via browser - using Composer
• Approval Policy enhancements
• Request editing capability for approvers
• Request Profiles
25
26 Oracle Confidential – Do Not Distribute
New entities exposed on Access Request UI
End user can access catalog to raise request for:
• Roles
• Application Instances
• Entitlements
• Can be extended in future, to any other entity managed within Access
Catalog. E.g. Application Roles.
26
27 Oracle Confidential – Do Not Distribute
Changes to Request Types
New request types:
• Provision Application Instance
• Revoke Account
• Delete Account
• Disable Account
• Revoke Account
• Provision Entitlement
• Revoke Entitlement
• Heterogeneous request
27
28 Oracle Confidential – Do Not Distribute
Changes to Request Types (contd…)
Deprecated request types:
• All Self related request types(except Self-registration).
• All Resource related request types.
29 Oracle Confidential – Do Not Distribute
Request Lifecycle
• An operation performed by user may/may not require approvals based
on his/her access permissions.
• Bulk operation always requires approval(s).
• Operations performed by ‘Entity Authorizer’s do not require approvals.
• Future effective date – requires approval
• Request dataset management through form designer.
30 Oracle Confidential – Do Not Distribute
Heterogeneous requests
• Request access for heterogeneous entities (any of
ApplicationInstance/Entitlement/Role) in a go.
• An account in the Target is required before requesting access to the
Target’s Entitlements.
• Heterogeneous request split to individual request types after Request
level approval.
Eg: If a user requests access to an ApplicationInstance & an Entitlement,
after Request level approval, it would be split into child requests of
types “Provision ApplicationInstance” and “Provision Entitlement”.
32 Oracle Confidential – Do Not Distribute
Adoption of a Unified Security Model
• Unlike 11GR1, R2 introduces request engine leveraging the same OES
based Security architecture used by other modules of the OIM.
• <Entity> Viewer Admin Role members and Org members
• Can access catalog and request for published entities
• Approval gets kicked off.
• <Entity> Authorizer/Administrator Admin Role members request
Access for <Entity>, no approval.
33 Oracle Confidential – Do Not Distribute
SOA Tasklist adoption in Task assignment UI Unified Inbox
• OIM 11gR2 directly renders in its UI:
• SOA Tasklist UI with tasks (requests) listed with actions available in dropdown.
• SOA Taskflow with complete graphical display of approval path.
• Same tasklist UI used for the scenarios
• Request Approval
• Manual fulfillment of disconnected applications access
• Certification tasks
• File attachments can be added with the request • Requestor can do it after request submission
• Approver can do the same
34 Oracle Confidential – Do Not Distribute
Editing Approval workflows on browser Using Composer
• Edit workflow Using SOA Composer UI
• Any approval workflow human task basic information can be edited.
• Assignment and Routing policy
• Escalation/Reminder policy.
• Notification – attach at a new stage, edit existing, change recipient, change format,
make actionable, attachments, secure
• If the approval workflow uses Business Rules, even the logic can be
updated – both IF conditions and THEN assertions!!
35 Oracle Confidential – Do Not Distribute
Approval Policy enhancements
• Auto-registration of Approval processes/SOA composites while approval
policy creation Ease of SOA composite/workflow registration.
• Support for new request types:
• Provision Entitlement
• Revoke Entitlement
• Heterogeneous request (only at Request level)
• Rules can be created based on Catalog metadata (say ‘Item Risk’).
36 Oracle Confidential – Do Not Distribute
Request Profiles
• It’s a saved cart, containing related entities and optionally, form data for
the entities.
• Can be used to raise Access requests alone.
• Created by Catalog Administrators and accessible to all users.
Pros:
- Simplified Access request creation for end-users.
- Re-usability of saved carts.
- Avoid human errors while filling form data.
37 Oracle Confidential – Do Not Distribute
Request Profiles
• Visibility of the profile to users can be limited by using EL expression.
38 Oracle Confidential – Do Not Distribute
Request Editing Capability
• Approvers can edit any field in the form data.
• Addition/removal of Target users/ entities is not allowed.
• “approver-only” property has been deprecated.
• Cannot modify entitlement data.
• Request data would be re-validated before persisting the changes.
39 Oracle Confidential – Do Not Distribute
Prior to R2 PS2, requester cannot save the request in draft mode. Requester may
want to get additional details before raising the request, so requester can save the
request data in draft mode. Later requester can modify and submit the draft request.
This feature is available for any end-user who can raise request.
Draft Request – Problem Statement
40 Oracle Confidential – Do Not Distribute
• All kind of request(except self registration) can be saved in draft mode.
• Once a request is saved in draft mode, its status is set to “Request Draft Created” and
a request id is generated which is used throughout the request lifecycle.
• Once saved, the drafted request can be updated multiple times until submission.
• The sensitive data is not stored while saving/updating the draft request.
• No validation is enforced while saving/updating the draft request.
• The drafted request can be tracked only by the requester.
• There is provision to delete the draft request and it can be deleted only by the
requester who has drafted the request.
Draft Request - Salient Feature
41 Oracle Confidential – Do Not Distribute
• The operation will always be request even if the requester is admin/authorizer.
• Once the drafted request is submitted –
• Validation is performed
• Request date is updated with current date
• It follows the normal request flow
Draft Request - Salient Feature
42 Oracle Confidential – Do Not Distribute
• Provide ability to specify the context for request – through UI
customization
• Enable customer to allow OIM users specify/view/update Additional
information at:
• Request level
• Cart-item/Entity level
• Support this across all operations which go through Request
Additional Information for Request – Requirement
43 Oracle Confidential – Do Not Distribute
• Request Engine support for Additional information at Request level as
well as Entity/Cart-item level
• Catalog UI support to Specify/View/Update additional information -
through customization
• UI support to Save/Update additional information as part of Draft
request
Additional Information for Request - Salient Feature
44 Oracle Confidential – Do Not Distribute
• Add custom link/button in Cart submission page and link it to custom
taskflow/form
• Custom taskflow/form launched as pop-up
• Customer can have custom managed bean/logic to achieve the
following:
• Selectively display the Additional Info link, based on selected cart
item
• Dynamically choose the custom taskflow to be launched, based on
selected Cart-item
• Display “Update” button in Approval details screen - for approver
update
Additional Information for Request – Customization Options
45 Oracle Confidential – Do Not Distribute 45
Overview of Complex Entitlements
• What is a complex entitlement?
• Entitlements are named privileges in targets eg – Ebiz
Responsibilities, SAP Roles, AD Groups
• Complex entitlements: additional data eg – Ebiz Responsibility
(Effective Start Date/Effective End Date), Database privilege grants,
ACLs
• Existing Entitlement Request Limitations:
• Could not handle providing additional attribute data for Complex
Entitlements.
• No support for modifying Entitlement Data
46 Oracle Confidential – Do Not Distribute
Overview of Functional Changes in R2 PS2
• Add ability to provision entitlements with data
• Add ability to modify provisioned entitlement’s data
• Generate entitlement forms
• Choose pre-defined templates with generating account forms
• New functionality available only upon regeneration of forms
• Upon regeneration new forms show up in all relevant client interfaces
54 Oracle Confidential – Do Not Distribute 54
Limitations of Entitlement Request
• Provision Entitlement request limitations:
• Entitlement can be provisioned only on “Primary” Account. No way to
choose target account if there are multiple provisioned to the user.
• Fails if user does not have an account.
• How do customers work around this:
• Use APIs to provision Account in an event handler.
• Tricky and failure cases cannot be handled properly.
• Account provisioning does not go via Request.
• No way of specifying Account data for requester.
• To provision to non-Primary account, customers use “Modify
Account” and add the entitlement as child table data.
• Entitlement request semantics does not apply.
55 Oracle Confidential – Do Not Distribute
Requirements
• If a provision entitlement request is raised for a beneficiary who does
not have the account, the system should ensure that an appropriate
account request is raised.
• If a provision entitlement request is raised for a beneficiary who has
multiple accounts, the system should allow the requester to choose the
Account for the entitlement grant.
• When an account is selected for entitlement request, catalog should
show only those entitlements defined in the application instance as that
of the selected account.
56 Oracle Confidential – Do Not Distribute
Solution in brief
• Single and multiple beneficiary requests handled differently.
• U/I is more “intelligent” for single beneficiary requests since end-user requesting is the more common case.
• Backend logic handles all cases of multiple beneficiaries and API calls.
• Three cases: • End user does not have Account : 0-CASE
• End user has a single Account : 1-CASE
• End user has multiple Accounts : N-CASE
• Basic Idea: • 0-CASE: Ensure (via requester action or automatically) to add the AppInstance in the request and
create cart-level dependency. Provide mechanism to provide account data (in the U/I or via SOA Human Task)
• 1-CASE: Choose existing Account, or add a new one via U/I.
• N-CASE: Allow requester (during request creation or later via SOA Human Task) to pick the Account.
57 Oracle Confidential – Do Not Distribute
Single Beneficiary Solution
• Applies to single/bulk entitlement requests, in same or across different
AppInstances
• 0-CASE: U/I will add AppInstance to the cart and create cart-level dependency between
AppInstance and Entitlement. Single AppInstance added for multiple entitlements in
same target.
• 1-CASE: U/I will allow requester to pick the existing account, or add an AppInstance to
the cart and create cart-level dependency.
• N-CASE: U/I will allow requester to pick one of the existing accounts (for each
entitlement in request), or add an AppInstance to the cart and create cart-level
dependency.
58 Oracle Confidential – Do Not Distribute
Multiple Beneficiaries Solution
• All multiple beneficiary cases handled in backend. U/I does not enforce
anything.
• 0-CASE:
• System will automatically add AppInstances to the request (one per unique
Beneficiary + Entitlements + AppInstance combination) and setup Request
Dependency.
• Account Request will create a SOA Human Task and assign it to the
Requester to collect the Account Data.
• Entitlement Request will trigger upon completion of Account request (Provide
Data => Approval => Fulfillment).
59 Oracle Confidential – Do Not Distribute
Multiple Beneficiaries Solution contd..
• 1-CASE:
• System will automatically detect that Beneficiary has a single Account and
implicitly associate it with the Entitlement Request. Request data will be updated
with the Account ID.
• Entitlement Request has all requisite data for fulfillment and will proceed through
its Approval/Fulfillment stages.
• N-CASE:
• System will invoke SOA composite and assign the Human Task to the requester
for picking the Account.
• Upon picking the Account, the Entitlement Request is updated with the Account ID
and its processing triggered.
• Entitlement Request has all requisite data for fulfillment and will proceed through
its Approval/Fulfillment stages.
59