Oracle Identity Manager 11gR2-PS2 Hands-on Workshop · 2014-06-04 · Oracle Confidential – Do Not Distribute 14 • Inline with existing OIM Auditing Engine • Tweak the implementation

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

mailto:[email protected]

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


Agenda

• Extension Points • Additional Information in Request

• Request Validation Plug-in

• Request Pre-populate Plug-in

• Diagnostics and Monitoring

• Important Links


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.


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


Catalog Architecture


Catalog Configuration

8 Oracle Confidential – Do Not Distribute 8


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



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


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


11

Catalog Job


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.


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


• 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


Access Request and Workflow


OIM-SOA Interaction


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”.


SOA Composite


SOA Composite – BPEL Process


SOA Composite – Human Task


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.



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).



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))



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


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


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


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


Changes to Request Types (contd…)

Deprecated request types:

• All Self related request types(except Self-registration).

• All Resource related request types.


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.


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”.


Heterogeneous requests (contd…)


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.


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


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!!


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’).


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.


Request Profiles

• Visibility of the profile to users can be limited by using EL expression.


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.


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


• 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


• 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


• 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


• 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


• 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


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


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


View Provisioned Entitlement w/ Data

47


Provision Entitlement with Data

48


Track Request with Entitlement Data

49


Modify Entitlement Data

50


Form Generation Options

51


Form Regeneration Options

52


Entitlement – Account Dependency


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.


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.


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.


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.


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).


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



Documents

Oracle Identity Manager 11gR2-PS2 Hands-on Workshop · 2014-06-04 · Oracle Confidential – Do Not Distribute 14 • Inline with existing OIM Auditing Engine • Tweak the implementation