OIA administration

Oracle Identity Analytics 11gR1:
Administration
Student Guide

D68340GC20
Edition 2.0
December 2010
D71223

Authors Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

Disclaimer
Steve Friedberg
David Goldsmith This document contains proprietary information and is protected by copyright and
other intellectual property laws. You may copy and print this document solely for your
own use in an Oracle training course. The document may not be modified or altered
Technical Contributors in any way. Except where your use constitutes "fair use" under copyright law, you
and Reviewers may not use, share, download, upload, copy, print, display, perform, reproduce,
publish, license, post, transmit, or distribute this document in whole or in part without
Neil Gandhi the express authorization of Oracle.
David Goldsmith The information contained in this document is subject to change without notice. If you
Stephan Hausmann find any problems in the document, please report them in writing to: Oracle University,
Stephen Man Lee 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not
warranted to be error-free.
Harsh Patwardhan
Restricted Rights Notice
Editors
If this documentation is delivered to the United States Government or anyone using
Vijayalakshmi Narasimhan the documentation on behalf of the United States Government, the following notice is
PJ Schemenaur applicable:

U.S. GOVERNMENT RIGHTS
Graphic Designer The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or
disclose these training materials are restricted by the terms of the applicable Oracle
Satish Bettegowda license agreement and/or the applicable U.S. Government contract.

Trademark Notice
Publishers
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names
Syed Ali may be trademarks of their respective owners.
Sumesh Koshy

Contents

1 Introducing Oracle Identity Analytics 11gR1
Objectives 1-2
Organizational Pressures 1-3
Controlling System Access 1-4
Achieving Compliance 1-6
Manual Processing 1-7
Problems with This Approach 1-8
Roles 1-9
Role Benefits 1-10
Enterprise Roles 1-12
Enterprise Role Management 1-14
Enterprise Role Management Categories 1-15
Oracle Identity Analytics 1-17
Oracle Identity Analytics Features 1-18
Architecture 1-20
Sample Deployment 1-21
Integration with Provisioning Systems 1-23
Functionality Matrix 1-24
Implementation Methodology 1-26
Oracle Identity Management 1-27
Available Documentation 1-29
Summary 1-30
Practice 1 Overview: Installing the Software 1-31

2 Building the Identity Warehouse
Objectives 2-2
Terms Used in Oracle Identity Analytics 2-3
Identity Warehouse 2-5
Identity Warehouse Contents 2-7
Business Structures 2-8
Users 2-9
Roles 2-11
Role Hierarchy 2-13
Audit Policies 2-14
Segregation of Duties (SoD) 2-15
SoD Matrix 2-16

iii

Applications 2-17
Resources 2-18
Attributes 2-19
Populating the Identity Warehouse 2-20
Populating Data Manually 2-21
Adding Additional Data Elements 2-22
Importing Data (Bulk Load of Data) 2-23
Configuring a Provisioning Server 2-24
Provisioning Server Parameters 2-25
Importing from File Processing 2-27
Importing from File: Rules 2-29
Debugging Import Errors 2-30
Debugging Import Errors Exception 2-31
Job Scheduling 2-32
Job Scheduling Through the GUI 2-33
Job Scheduling Through Direct Edit 2-34
Database Entries for Job Scheduling 2-37
Summary 2-39
Practice 2 Overview: Importing and Setting Up Identity Warehousing 2-40

3 Configuring Security
Objectives 3-2
Oracle Identity Analytics Users (OIA Users) 3-3
Oracle Identity Analytics Roles (OIA Roles) 3-5
OIA Role Creation 3-7
OIA Role Visibility 3-8
OIA Users/Roles Database Tables 3-9
Proxy Assignments 3-10
Alternate Credential Store 3-11
Summary 3-12
Practice 3 Overview: Configuring Security 3-13

4 Configuring Identity Certification
Objectives 4-2
Security Challenges 4-3
Identity Certification 4-4
Automated Certification: Benefits 4-5
Certification Environment 4-6
Certification Process 4-8
Phase 1: Preparation 4-9
Phase 2: Pilot 4-13

iv

Phase 3: Validation 4-14
Phase 4: Certification 4-15
Phase 5: Remediation 4-17
Certification Dashboard 4-19
Closed-Loop Remediation 4-21
Best Practices 4-22
Metrics 4-24
Return on Investment 4-25
Summary 4-26
Practice 4 Overview: Configuring Identity Certification 4-27

5 Configuring Auditing
Objectives 5-2
Identity Auditing 5-3
Product Capabilities 5-4
Audit Rules 5-5
Audit Policy 5-6
Actors 5-7
Policy Violations 5-8
Audit Scans 5-10
Dashboard: Overview 5-11
Dashboard 5-12
Policy Violation States 5-13
Audit Policy Actions 5-14
Job Scheduling 5-15
Event Listeners 5-16
Summary 5-17
Practice 5 Overview: Configuring Auditing 5-18

6 Performing Role Mining
Objectives 6-2
Role Management 6-3
Role Mining (Role Discovery) 6-4
Approaches to Role Mining 6-5
The Wave Methodology 6-7
The Wave Methodology (Step 1 of 7) 6-8

v

Accessing Role Mining 6-21
Performing Role Mining 6-22
Role Mining: Minable Attributes 6-23
Role Mining: General Information 6-25
Role Mining: User Selection 6-26
Role Mining: Basic Parameters 6-27
Role Mining: Advanced Parameters 6-28
Role Mining: Preview 6-30
Role Mining: Execution 6-31
Role Mining: Users In Roles 6-32
Role Mining: Classification Rules 6-33
Role Mining: Mining Statistics 6-34
Role Mining: Roles 6-35
Role Mining: Role Mining Reports 6-37
Entitlements Discovery 6-38
Accessing Entitlements Discovery 6-39
Performing Entitlements Discovery 6-40
Entitlements Discovery: Strategy 6-41
Entitlements Discovery: Role/Users 6-42
Entitlements Discovery: Entitlements 6-43
Entitlements Discovery: Verification 6-45
Best Practices 6-46
Summary 6-47
Practice 6 Overview: Role Engineering 6-48

7 Performing Role Lifecycle Management
Objectives 7-2
Role Management Activities 7-3
Role Lifecycle Management 7-4
Role Engineering (Definition) 7-5
Role Maintenance (Refinement) 7-6
Examples of Change Events 7-7
Role Certification (Verification) 7-8
Workflows 7-9
Default Workflows 7-10
Editing Workflows 7-11
Custom Role Modification Workflow 7-13
Processing Role Changes 7-14
Role Modification 7-15
Workflow Status 7-16

vi

Pending Requests 7-17
Modification Details 7-18
Role Versions 7-19
Role History 7-20
Best Practices 7-21
Summary 7-22
Practice 7 Overview: Performing Lifecycle Management 7-23

8 Generating Reports
Objectives 8-2
Reports 8-3
Reporting Categories 8-4
Accessing Reports 8-5
Report Dashboard 8-6
Business Structure Reports 8-7
Business Structure Roles Report 8-8
Creating Custom Reports 8-9
Executing Custom Reports 8-11
Summary 8-12
Practice 8 Overview: Generating Reports 8-13

vii

Introducing Oracle Identity Analytics 11gR1

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

Objectives

After completing this lesson, you should be able to:
• Identify the business drivers for role management
• Describe methods for meeting compliance
• Describe how a role management solution streamlines the
process
• Describe the features and components of Oracle Identity
Analytics
• Describe an Oracle Identity Analytics implementation


Objectives
Discussion: The following questions are relevant to understanding the topics covered in this
lesson:
• How are regulatory compliance mandates affecting companies today?
• How are companies dealing with compliance?
• What is a role and how can role-based access control solutions help achieve compliance?
• What is the difference between a role management solution and a user provisioning
solution?

Oracle Identity Analytics 11gR1: Administration 1 - 2

Organizational Pressures

Companies are faced with: Security:
Minimize
• A growing number of Reduce
Risk

applications Business:
Costs
Open
• A constantly Access Sarbanes
-Oxley
changing user
population
Gramm-
Improve
• The need to prevent Leach-
Bliley The Enterprise Quality of
or detect inside threats Act Service

European Health Insurance
• The need to meet Data Protection Portability &
Directive
regulatory compliance Acct Act (HIPAA)

How can you achieve an acceptable balance between
functionality, risk, and cost?


Organizational Pressures
Companies face multiple, multifaceted business challenges in which the management of
employees’ and partners’ access to enterprise resources is vital. Foremost among these is the
challenge of complying with an ever-growing number of regulations that govern the integrity
and privacy of enterprise data. With the need to protect data comes the need to closely manage
access to it. This involves knowing at all times who has access to corporate resources and
whether their access is appropriate. Companies then need to provide documentation of this
information in the event of an audit.
Compliance is not the only challenge in today’s enterprise. Even more critical is the need to
operate an agile business that can respond quickly and competitively to business opportunities
and competitive threats. Operating such a business while remaining compliant is a tall order. A
major concern is how to achieve a balance between implementing new functionality while
managing risk and still keep costs under control. Companies are looking to spend “just enough”
to pass an audit and lower their risk. Companies want to reduce existing costs associated with
audits while still making the process more efficient, accurate, and repeatable, thereby balancing
their efforts.


Controlling System Access

• Insider Threats
– Loss of business continuity
– Loss of trade secrets
– Loss of sensitive customer or employee data
• Regulatory pressures
– The Sarbanes-Oxley Act of 2002
– The Graham-Leach-Bliley Act
– The Health Insurance Portability and Accountability Act
– The Payment Card Industry Data Security Standard


Controlling System Access
Studies have shown that 70 percent of all security threats are caused by insiders (employees or
contractors). This number consists of breaches that were caused by employees with malicious
intentions, as well as by well-intentioned personnel who simply made mistakes. Irrespective of
the nature of the breach, companies must control access to system resources in order to
protect their business, corporate information, or even trade secrets.
Concerns about threats from insiders fall into three main categories:
• Loss of Business Continuity
Disruptive events such as hardware failures, an act of nature such as a flood, or even
denial-of-service attacks impact a company’s ability to maintain business flow. When such
an event occurs, companies face large losses because they are not able to process
orders or access vital resources.
• Loss of Trade Secrets
Companies have a responsibility to their shareholders, employees, and customers to
protect corporate assets. This involves trade secrets, proprietary processes, or
information that provides an advantage over competitors. Companies spend billions of
dollars on research and development, only to find themselves engaged in battles to
protect their proprietary information.


Controlling System Access (continued)
• Loss of Sensitive Customer or Employee Data
Protection of customer or employee data is one of the main drivers of regulatory
compliance, and companies have a fiduciary responsibility to protect this information.
However, more and more companies are making headlines as sensitive personal
information is stolen, lost, or inadvertently published to corporate Web sites. Companies
realize they need adequate access control practices to reduce these risks.
In addition to insider threats, companies are forced to comply with one or more regulations that
require a review of access and access control processes. In essence, companies are being
forced into compliance. Regardless of whether a company must adhere to SOX/Cobit, PCI,
HIPAA, GLBA, or Basel II, it needs to understand the current access held by individuals inside
and outside the company, and the current access control process. It also needs to be able to
rapidly generate the evidence and related artifacts to determine user access and pass an audit.


Achieving Compliance

• A common theme behind compliance involves
identification and management of user access rights.
– What resources does a user have an account on?
– Does the user require an account on that system?
– What are the user’s capabilities on that resource?
– Who authorized or created the user’s account?
– Does the user’s presence violate any business or security
policies?
• How do companies determine this information today?


Achieving Compliance
A common theme behind a company’s ability to achieve compliance involves its ability to
ascertain all the systems that a user has access to, what capabilities or access rights the user
has on those systems, and who authorized or created the account on that system. Additionally,
a company needs to determine whether the user actually requires access to those systems to
perform his or her job and whether his or her presence on one or more of those systems
violates any business or security policies.
So how do companies determine this information today? The next few pages show one such
solution.


Manual Processing

• Use spreadsheets to store roles and entitlements.
• Interview managers and business owners.
• Dump the systems (accounts and entitlements).
• Manually correlate accounts.
• Compare accounts and entitlements to standards.
• Identify violations.
• Periodically review role definitions.


Manual Processing
Historically, companies have implemented manual processes for achieving compliance. These
companies share several traits, as shown in this slide.


Problems with This Approach

• Error prone and time intensive
• Minimal process ownership (or involvement)
• Difficult to manage spreadsheets
– Time consuming
– No version control
• Continuous monitoring of exceptions impossible
• Difficult to manage user access rights
• Performing defined versus actual analysis impossible


Problems with This Approach
This slide shows some of the problems associated with using a manual approach to
compliance.
• Manual processes lead to human errors and extra work.
• Reviews are not performed in a timely manner and, in general, managers do not seem to
want to be involved in the process.
• Spreadsheets are difficult to manage, are time consuming, do not easily allow for version
control, and do not provide a method for looking back in time to determine who had
access at that time.
• It is extremely difficult or impossible to perform continuous monitoring of exceptions when
information is kept in a spreadsheet.
• It is difficult to assign roles to existing users and remove exceptions when violations are
detected.
• There is no way to perform a role versus actual analysis and no way to easily certify that
role definitions are correct.


Roles

Abstraction layer: Branch
Manager
Bank
Teller

• Provides access rights
grouping mechanism
• Contains systems and
privileges
• Makes assignments based
on job function
• Provides mechanism for
detecting violations
Role 1 Role 2


Roles
A role is a grouping of entitlements across a set of resources. This grouping mechanism
enables you to associate access rights to computing resources based on a user’s job function.
In a financial institution, for example, roles might correspond to job functions such as bank
teller, loan officer, branch manager, clerk, accountant, or administrative assistant. Persons in
these job functions require access to a specific set of resources to perform their jobs, and their
privileges on these resources might differ based on their job function as well.
Roles can be shared among users as necessary. In this slide, the Branch Manager has access
to the systems defined within two different roles (Role 1 and Role 2). The Bank Teller, however,
has access only to the systems defined in Role 2. Assignment of multiple roles to a user is
acceptable as long as that assignment does not violate any corporate business or security
policies.


Role Benefits

• Provide an understandable model for access
• Provide an efficient definition of processes and policies
• Reduce auditing efforts
• Provide a common language between business and
information technology
• Provide consistent, known controls for defining access
• Facilitate access requests more easily


Role Benefits
A role-based access control (RBAC) model provides a structure that can be used to address
compliance. By coupling access requirements to users based on organizational information
(such as job title, employee code, or business unit), roles enable business managers to provide
users with the access they need without violating business or security policies.
Roles provide the following benefits. Roles:
• Define the model for access. Access requirements are often difficult to understand.
Managers simply do not know which groups within Active Directory their employees need
to perform their duties, and employees do not know what level of access to request.
• Define the structure for access. A role can encapsulate access requirements for a
particular job function (Business Role), an application function such as “create vendor” (IT
Role), or a temporary project membership (Auxiliary Role). In all cases, when the role
content is agreed upon by the business, the business owners can also define the “friendly
description,” the owner, and even the population who can have or request the role. All
these items make it easier to understand access.
• Are efficient. Defined roles can be utilized throughout a company’s identity and access
management program. Roles make all operations easier to develop, maintain, and
understand.


Role Benefits (continued)
• Provide evidence of compliance. Auditors need to easily understand the access controls
and processes in your organization. Having a defined set of roles (that is utilized across
the identity and access management program) will greatly advance your ability to prove
that you have compliant processes.
• Bridge the gap between business and information technology. Roles bridge the
communications gap between business and IT. The role definition process itself requires
input from both business and IT personnel, and the result is a defined set of roles that
encapsulates business requirements.
• Provide controls. Roles provide known and approved levels of access for a job title or job
function. Because roles are engineered and reviewed, they should not provide any
access that violates separation of duties (SoD) policies. Additionally, with defined roles,
provisioning operations and services could be limited to allow only role-based access
allocation, thereby increasing control and decreasing risk.
• Facilitate valid requests from employees. With clearly defined roles, employees can easily
understand and request access to the applications and data that they need. For example,
Bob might be added to Project Team 7 and need to request access defined for that
project, or he might want read-only access to product-line financial data to perform some
analysis. These roles (business or IT) should be available and understandable.


Enterprise Roles

IT Ops & Security Business Managers Audit & Compliance

•Managing access •Acquiring and •Mapping control
control across the providing access objectives into security
enterprise quickly and access policies
•Enforcing and •Understanding and •Lacking IT knowledge
proving compliance attesting to access to automate critical
access controls


Enterprise Roles
Utilization of roles across the enterprise provides benefits across multiple lines of business.
• Information Technology (IT)
The IT department can use roles during the provisioning process to ensure that users
have access to the correct resources. During provisioning, an automated or manual
process can assign access based on roles. This makes access assignment logic easier to
develop and maintain, and makes self service requests for access by employees easy to
understand.
Additionally, IT departments can control access to systems based on role definitions.
During policy evaluations for real-time access management, being able to define policies
based on roles is more efficient than policies based on fine-grained attributes.
Finally, roles reduce the risk associated with access control. IT is often responsible for the
risk associated with access control. With well-defined roles, access control increases, and
risk decreases.


Enterprise Roles (continued)
• Business Managers
Business managers are often tasked with requesting and approving access to resources
for their direct reports. In many cases, the business managers do not understand what
access is actually required or even appropriate. This leads to copy/paste entitlements
(access based on another user’s rights) or an accumulation of entitlements over time.
Roles provide a method for defining resource access based on business terminology
rather than technical terms. When they request or approve access, business managers
can be assured that the access would be adequate based on their needs, and that it
would be provided in a timely manner.
Business managers can also be assured that during the audit process, they can better
understand access requirements and can attest to access based on role definitions
already in place.
• Auditors
Auditors, like employees, need to understand how access is defined, granted, and
removed, and a business-friendly context is easier to understand than the cryptic IT
entitlements.
When determining access control compliance, auditors can review the defined roles, an
individual’s assigned roles, and an individual’s assigned access outside of the defined
roles. This makes the review process more efficient and accurate.
By defining, utilizing, and periodically verifying roles, you are establishing controls that
prove to auditors that a repeatable, sustainable process for access control exists.


Enterprise Role Management

Who is accessing
what data and
which applications? HP

Who approved the
access assigned to
users? IBM

How can access
control policies be
enforced? Oracle

Employees Access Management Apps & Data


Enterprise Role Management
Enterprise role management (ERM) provides a strong technology solution for access certification
and segregation of duties enforcement. With such a solution in place, you can drastically reduce
the cost for audit preparation by easily answering the questions most often asked by auditors.
• Who is accessing what data and applications?
To improve security, you must first understand your current level of security as it pertains to
entitlements. After locating where inappropriate access is present, you can determine how it
was granted and adjust the processes that provisioned the access. This gives you the ability
to evolve your controls and increase your proactive and reactive security processes.
• Who approved the access assigned to users?
Improved security lowers your risk and protects your company from threats originating from
inappropriate access (such as data breaches). Strong access control governance through
roles is a key component in protecting critical applications and data from both internal and
external threats.
• How can access control policies be enforced?
Having a strong compliance program can also be utilized internally and externally to promote
goodwill.


Enterprise Role Management Categories

• Role mining
• Attestation
• Role management
• Provisioning integration


Enterprise Role Management Categories
Enterprise Role Management consists of four main categories:
• Role Mining
Role mining is the widespread discovery of application-level entitlements. The role mining
process discovers relationships between users based on similar access permissions that
can logically be grouped to form a role. Role engineers can specify the applications and
attributes that will return the best mining results. Role mining is also called role discovery.
• Attestation
Attestation is the process of certifying access and entitlements across one or more
resources. Attestation involves a certification review process where an individual
(business manager or resource owner) confirms that the right users have the right access
on the right resources. Organizational changes should be reflected in a user’s
entitlements because the user is either granted additional access or denied access due to
job changes. As such, attestation should be performed on an ongoing basis and should
be automated where possible.


Enterprise Role Management Categories (continued)
• Role Management
Role management involves the grouping and management of application-level
entitlements into enterprise roles. Role definitions consist of the grouping of entitlements
across one or more resources. These roles are then associated with organizational
structures such as job titles, employee codes, or departments. A user is granted access to
resources based on a role definition and as such, roles themselves need to be
periodically reviewed and recertified.
• Provisioning Integration
Integration with provisioning systems such as Sun Identity Manager provides both a
proactive and reactive mechanism for achieving compliance. Account provisioning
systems should utilize roles defined in a role provisioning system to ensure that access is
granted properly. Alternatively, violations detected during the attestation process should
interface to an account provisioning system in order to address the violation in a timely
manner.


Oracle Identity Analytics

Features:
• Role Engineering
• Role Maintenance
• Role Certification
• Access Certification
• SoD Policy Enforcement
• Securely automates and
simplifies compliance
processes, and aligns with
business drivers


Oracle Identity Analytics
Oracle Identity Analytics (formerly Sun Role Manager, before that Vaau’s RBACx product)
provides comprehensive role lifecycle management and identity compliance capabilities to
streamline operations, enhance compliance, and reduce costs. Created and developed by
Vaau in 2001, Oracle Identity Analytics was the first comprehensive solution in the market.
Sun’s acquisition of Vaau in 2007 added a world-class role management solution to its already
impressive arsenal of identity management products.
The Oracle Identity Analytics open architecture is both robust and scalable, and has the highest
number of managed users for a single deployment (1.1 million identities at a large financial
services company). The solution has been audited by all the major audit and regulatory bodies,
and is tightly coupled with best practices and proven methodologies.
The Oracle Identity Analytics software has been implemented at numerous client sites across
different industries, and analysts such as Gartner and Forester agree that Oracle Identity
Analytics is the leading identity compliance and role management solution on the market today.


Oracle Identity Analytics Features
A Complete Solution for Simplified Access Control Compliance

Role Life–Cycle Management Identity Compliance
Role Framework Role Mining Access Certification Policy Enforcement

Role Maintenance Role Certification Dashboard/Analytics Activity Monitoring

Identity Warehouse
BU Model | App Metadata | Glossary

Users, Entitlements, Roles, Policies

Identity & Access Mgmt Integration Extract, Transform, & Load (ETL)

IAM Systems Application Infrastructure


Oracle Identity Analytics Features
The first key feature to look at is the Identity Warehouse, where users, entitlements, roles, and
policies are stored. The warehouse imports this data from identity and access management
(IAM) systems using the out-of-the-box connections to such systems and directly from the
application infrastructure by using extract, transform, and load (ETL) processes.
The warehouse also serves as the entitlements and roles repository for the enterprise. On top
of the user information, you can model business units. Oracle Identity Analytics provides a
flexible way to build business units on any logical data construct derived from user identity data.
Customers have found this organizational grouping to be very useful to model several business
structures or hierarchical business units to meet different needs. For example, a large credit
card company decided to model one business structure based on business processes and
another based on an organizational chart. The business unit data can be provided as a service
to external applications.


Oracle Identity Analytics Features (continued)
The next key feature of the warehouse is application metadata, to which it attributes its
flexibility. The metadata is the definition of attributes and the security structure of applications in
the infrastructure. The metadata enables you to define the security structure of any application,
platform, or database without any coding. You can then define parameters and include
constraints on each of the data attributes, which enable you to control how the data will be
used. For example, you might import 200 attributes from Microsoft Active Directory, but display
only the five key attributes in your certification.
The next key feature is the Glossary, which is highly recommended for certifications. The
Glossary is a business-friendly description of entitlement values that can be managed from the
user interface of the Identity Warehouse.


Architecture


Architecture
Oracle Identity Analytics is a Java 2 Platform, Enterprise Edition (J2EE platform) Web
application. As such, it is deployed to the Web container of an existing application server.
Access to the Oracle Identity Analytics user interface is made through a standard Web browser
that uses the HTTP protocol over a particular port (in this case, port 80).
Oracle Identity Analytics data (business structures, users, roles, policies, applications, and
resources) is contained in its Identity Warehouse. The Identity Warehouse is an RDBMS that is
not included with the Oracle Identity Analytics product. Oracle Identity Analytics does not
provide any database services such as replication, backups, and so on. Instead, the database
administrator uses the native database tools for this purpose.
The Oracle Identity Analytics software enables you to interface with some resources (such as
databases, flat files, and directory servers) through an adapter. Adapters are written in the Java
programming language and implement protocols such as Java Database Connectivity (JDBC)
and Lightweight Directory Access Protocol (LDAP). Additionally, Oracle Identity Analytics can
interface directly with flat files by using Java Naming and Directory Interface (JNDI), and can
communicate with user provisioning systems through the Service Provisioning Markup
Language (SPML).


Sample Deployment
Application Server
Web Interfaces Connected
Systems

Oracle Identity
Analytics

Application Server
Administrative
Load
Balancer

Oracle Identity Network Failover
Analytics Device Managed
Nonconnected
Systems Resources

Identity
Whse
Identity Mgr
Instances


Sample Deployment
This slide demonstrates a sample Oracle Identity Analytics deployment that includes both
connected and nonconnected resources. Connected resources include those systems that
Oracle Identity Analytics can communicate with directly, which includes relational databases
and directory servers. Nonconnected resources are those systems that Oracle Identity
Analytics cannot communicate with directly and require that data dumps be taken on a periodic
basis and consumed by Oracle Identity Analytics.
This example also demonstrates integration with a user provisioning solution such as Sun
Identity Manager. In the context of Oracle Identity Analytics, this is called a Provisioning Server.
The Provisioning Server can be used as an authoritative source of user identities when
populating the Identity Warehouse with users. Oracle Identity Analytics can also instruct the
Provisioning Server to disable or delete user accounts that are found to be in violation of
corporate or security policies through a process called closed-loop remediation.
In this example, there are two instances of Oracle Identity Analytics in a highly available
configuration. These instances can be clustered, or you can place a load balancer or network
failover device in front of the instances as necessary.


Sample Deployment (continued)
A common deployment scenario is to separate Oracle Identity Analytics instances based on
functionality as follows:
• Role Management and Identity Compliance (certification and audit):
This instance requires periodic feeds from resources in order to perform scans for policy
violations and might also include connectivity to a Provisioning Server to perform closed-
loop remediation. Application and data owners interface to this instance to perform audits
and certifications.
• Role Engineering (role mining and entitlement discovery):
This instance can be treated as an offline instance. It does not need to be part of a
production server cluster and might even be used as a staging server for the production
environment. Role engineering instances require one-time application feeds when
performing role mining and entitlements discovery, and the data is locked until the
analysis has been completed. This instance is not typically connected to the Provisioning
Server, but it could be in order to provide another highly available instance.
Note that both instances point to the same Identity Warehouse. In such architectures, you
should consider using database clustering in order to achieve a highly available database
solution.


Integration with Provisioning Systems

Analysis & Definition of Run-time Enforcement of
Identity-based Controls Identity-based Controls

Users & Accounts

Roles, Policies, & Rules

Oracle Identity Analytics Oracle Identity Manager
• Role Life Cycle Mgmt • Identity Life Cycle Mgmt
• Detective Identity • Preventative Identity
Compliance Compliance

Comprehensive Access Control Compliance


Integration with Provisioning Systems
Companies need to evaluate access for existing individuals (detective), as well as ensure that
all the current identity management processes do not introduce inappropriate access
(preventative). By integrating the Oracle Identity Analytics software with a user provisioning
solution such as Oracle Identity Manager, companies can enter into audits with the assurance
that they have done everything possible to ensure compliance.
Through automation of provisioning processes, such as hiring a new user, handling a job
transfer, or terminating a contractor, controls can be defined and enforced much more
effectively and consistently than through a manual process.
To ensure that the existing access is appropriate and does not represent “toxic combinations”
of access, such as “create vendor” and “pay vendor,” customers require enterprisewide
evaluation of detective SoD policies. Additionally, during any provisioning operation, manual or
automated, companies want to evaluate preventative SoD policies and ensure that the
operation will not introduce any new violations.


Functionality Matrix

Role Life User Life End User Identity
Cycle Mgmt Cycle Mgmt Self Service Compliance Reporting

Oracle
Identity
Manager * *
Oracle
Identity
Analytics * *

Primary Function
Supporting Function
*

Functionality Matrix
The Oracle Identity Manager and Oracle Identity Analytics products provide an integrated
solution for establishing roles and managing access across the enterprise.
Oracle Identity Analytics is primarily a tool for achieving compliance. It is the authoritative
source for role definitions and role-to-user relationships, and provides out-of-the-box features
for managing the overall role life cycle. This includes features such as notifications, approvals,
and versioning when a role change occurs. The Oracle Identity Analytics software provides
audit scans to identify violations against existing policies. As such, Oracle Identity Analytics is
primarily a reactive tool that reacts to policy violations and takes an appropriate action. One
such action might be to simply notify an owner who must then mitigate the violation manually.
Alternately, Oracle Identity Analytics can interface with the Provisioning Server and request that
the user’s account should be deleted or disabled in order to conform to corporate policies, and
therefore, close the violation automatically.


Functionality Matrix (continued)
The Oracle Identity Manager software manages users throughout the identity life cycle. It
creates, deletes, and modifies accounts on managed resources and can do so by utilizing role
definitions created by Oracle Identity Analytics. Oracle Identity Manager can monitor data from
one or more identity sources (such as human resource applications or contractor databases)
and can provision user accounts based on roles. As such, it is primarily a proactive tool in the
hiring process.
Oracle Identity Manager provides an end-user interface that enables employees, contractors, or
other users to manage certain attributes (such as mobile phone or password). The primary
users of Oracle Identity Analytics are the administrators who support the product and owners
who participate in the certification process (nonadministrative users do not access Oracle
Identity Analytics directly).


Implementation Methodology

The Wave Methodology for Role Definition
Analyze & Prioritize. Build Entitlement Perform Role
• Prioritize divisions. Warehouse. Discovery.
• Prioritize applications. • Import data. • Define role
• Collect and correlate membership.
entitlements to • Define role
identities. entitlements.
• Form business units.

Review Candidate Finalize Candidate Analyze/Review Role
Roles. Roles. Exceptions.
• Review and approve • Incorporate • Handle exceptions via
roles. suggested changes. auxiliary roles or ad
• Review and approve • Submit roles to role hoc access requests.
entitlements. owners for approval.

Finalize Role Exceptions and Certify Roles.
• Incorporate any remaining changes.
• Finalize role definitions.


Implementation Methodology
Managing access based on users’ roles is an efficient, effective alternative to attempting to do
the same on a user-by-user basis, which can be virtually impossible when dealing with large
numbers of dynamic users. To assist organizations in creating a role-based model for access
control, Oracle has developed a wave methodology that breaks users into manageable chunks,
or “waves,” for the purpose of defining roles.
The Sun wave methodology breaks large numbers of users into more manageable chunks, or
“waves,” for the purpose of defining roles. This is accomplished by first dividing users into
business units, which are groupings of people based on their managers, departments,
divisions, or other commonalities. These business units are then grouped into different waves
(usually four to six business units per wave) that can be prioritized based on the needs of the
business. Each wave requires a seven-step process for role definition as shown in the slide.
Note: You can obtain more information about Wave Methodology in the lesson titled
“Performing Role Mining.” The Wave Methodology white paper can be found at
http://www.sun.com/offers/details/wave_methodology.xml.


Oracle Identity Management
Oracle + Sun Combination
Identity Administration Access Management* Directory Services

Access Manager
Adaptive Access Manager Directory Server EE
Identity Manager
Enterprise Single Sign-On Internet Directory
Identity Federation Virtual Directory
Entitlements Server
Identity & Access Governance

Identity Analytics

Oracle Platform Security Services

Operational Manageability

Management Pack For Identity Management

*Access Management includes Oracle OpenSSO STS and Oracle OpenSSO Fedlet.


Oracle Identity Management
eSSO:
Oracle Enterprise Single Sign-On Anywhere – Simplifies Oracle Enterprise Single Sign-On
deployments to client desktops. It includes:
• Oracle Enterprise Single Sign-On Logon Manager – Enables individuals to securely use a
single login credential to all Web-based, client/server and legacy applications
• Oracle Enterprise Single Sign-On Password Reset – Helps reduce helpdesk costs and
improve user experience by enabling strong password management for Microsoft
Windows through secure, flexible, self-service interfaces
• Oracle Enterprise Single Sign-On Authentication Manager – Enforces security policies
and ensures regulatory compliance by allowing organizations to use a combination of
tokens, smart cards, biometrics, and passwords for strong authentication throughout the
enterprise
• Oracle Enterprise Single Sign-On Provisioning Gateway – Improves operational efficiency
by enabling organizations to directly distribute single login credentials to Oracle
Enterprise Single Sign-On Manager based on provisioning instructions from Oracle
Identity Manager
• Oracle Enterprise Single Sign-On Kiosk Manager – Enhances user productivity and
strengthens enterprise security by allowing users to securely access enterprise
applications even at multiuser kiosks and distributed workstations


Oracle Identity Management (continued)
Oracle Identity Federation (OIF):
OIF enables identity providers and service providers to connect seamlessly. It creates trust
relationships between partners and agencies by connecting users seamlessly and securely.
OIF ensures the interoperability to securely share identities across vendors, customers, and
business partners, thus providing cross-domain SSO.
Oracle Adaptive Access Manager (OAAM):
OAAM provides real-time fraud prevention, multifactor authentication, and unique
authentication strengthening. OAAM consists of two primary components:
• Adaptive Strong Authenticator, which provides multifactor authentication and protection
mechanisms for sensitive information such as passwords, PINs, security questions,
account numbers, and other credentials
• Adaptive Risk Manager, which provides real-time and offline risk analysis and proactive
actions to prevent fraud at critical login and transaction checkpoints. Adaptive Risk
Manager examines and profiles a large number of contextual data points to dynamically
determine the level of risk during each unique login and transaction attempt.
Security Token Service:
STS simplifies the orchestration of standards-based and proprietary tokens between Web
services clients and providers, enabling businesses to abstract security from Web services. It
provides a solution for abstracting Web services security and handling token issuance,
validation, and translation through WS-Trust.
It also provides a means to propagate identity and security information across infrastructure
tiers by converting a Web SSO token issued for an enterprise portal to an SAML token that is
consumed by applications or Web services.
Fedlets:
A Fedlet is a service provider implementation of SAML 2.0 SSO Protocol. It is a lightweight way
for service providers to quickly federate with an identity provider. An 8.5 MB package that
identity providers give to service providers enables them to federate back to a company without
the need for any additional federation products.
To become federation enabled, the service provider simply adds the Oracle OpenSSO Fedlet
to their application and deploys the application. No configuration is required and it works with
both Java and .NET applications. With Fedlets, service providers can consume identity
assertion and receive user attributes from OIF.
Oracle Entitlements Server (OES):
OES provides management of fine-grained authorization policies and a standardized
enforcement mechanism as an alternative to embedding one-off security within the application.
Oracle Platform Security Services (OPSS):
OPSS provides an abstraction layer in the form of standards-based APIs that insulate
developers from security and identity management implementation details. With OPSS,
developers do not need to know the details of cryptographic key management or interfaces with
user repositories and other identity management infrastructures. By leveraging OPSS, in-house
developed applications, third-party applications, and integrated applications all benefit from the
same uniform security, identity management, and audit services across the enterprise. It is a
standards-based, portable, integrated, enterprise-grade security framework for Java Standard
Edition (Java SE) and Java Enterprise Edition (Java EE) applications.


Available Documentation

• All Audiences
– Oracle Identity Analytics 11gR1 Release Notes
• Business Users
– Business Administrator’s Guide
– User’s Guide
• System Administrators and Service Providers
– Installation and Upgrade Guide
– System Administrator’s Guide
– Database Administrator’s Guide
• System Integrators
– System Integrator’s Guide
– API Guide


Available Documentation
Oracle provides extensive documentation on the Oracle Identity Analytics product that is
applicable to different audiences. This slide provides an overview of the documents that are
available on the Oracle Identity Analytics 11gR1 Documentation Home (Wiki) at
http://wikis.sun.com/display/OIA11gDocs/Home.


Summary

In this lesson, you should have learned to:
• Identify the business drivers for role management
• Describe methods for meeting compliance
• Describe how a role management solution streamlines the
process
• Describe the features and components of Oracle Identity
Analytics
• Describe an Oracle Identity Analytics implementation



Practice 1 Overview: Installing the Software

This practice covers the following topics:
• Starting the VirtualBox Image
• Installing Oracle Identity Analytics 11gR1



Building the Identity Warehouse


Objectives

After completing this lesson, you should be able to describe the
following:
• Oracle Identity Analytics terminology
• Identity Warehouse
• Methods for importing data
• Job scheduling


Objectives
Discussion: The following questions are relevant to understanding the topics covered in this
lesson:
• What type of information does Oracle Identity Analytics store and where is this information
maintained?
• How can you import data (users, roles, business units, and so on) from existing sources?
• What functionality does Oracle Identity Analytics provide for job scheduling?


Terms Used in Oracle Identity Analytics

• User
• Business structure
• Resource
• Attribute
• Audit policy
• Role
• Role mining
• Certification
• Application


Terms Used in Oracle Identity Analytics
This slide provides an introduction to the terminology used in Oracle Identity Analytics. The
remainder of this and subsequent modules provide further insight into each of these terms.
• User – A user is defined as a discrete, identifiable entity that has a business need to
access or modify enterprise information assets. Typically, a user is an individual, but a
user can also be a program, a process, or a piece of computer hardware.
• Business structure – A business structure in Oracle Identity Analytics is defined as a
department or subdepartment within an organization. An organization can be segregated
into as many business structures, with as many levels of hierarchy as are required to
represent teams and subteams within the organization. There is no limit to the number of
users that can be assigned to a business structure. All operations in Oracle Identity
Analytics, such as identity auditing and identity certification, are performed on the basis of
a business structure.
• Resource – Resources are the applications and enterprise information assets that users
need to do their jobs.
• Attribute – Attributes are resource data elements that pertain to user and policy
information.


Terms Used in Oracle Identity Analytics (continued)
• Audit policy – An audit policy is a collection of audit rules that together enforce the
business polices associated with segregation of duties (SoD).
• Role – A role represents a job function. Roles contain policies that describe the access
that individuals have on a particular resource. Roles represent unique job functions
performed by users in the domain.
• Role mining – A role mining process can be used to discover relationships between
users based on similar access permissions that can logically be grouped to form a role.
This process is also known as role discovery and can drastically reduce the time needed
to define and manage roles.
• Certification – Also known as attestation, certification is the process of evaluating users’
access to system resources and attesting that their presence on these resources does not
violate any business policies.
• Application – Applications provide a method of grouping entitlements across one or more
resources for auditing purposes.


Identity Warehouse

• Is a data-rich repository of Business Structures, Users,
Roles, Policies, Applications, and Resources
• Is a relational database
• Provides a logical view of the company for management
• Enables implicit grouping of people for role mining
purposes
• Contains all entitlement data:
– Consists of data imported from organizational resources
– Is updated on a regular or scheduled basis
• Is built first in an Oracle Identity Analytics deployment


Identity Warehouse
Oracle Identity Analytics utilizes a data-rich repository called the Identity Warehouse that
contains all important entitlement data for your organization (Business Structures, Users,
Roles, Policies, Applications, and Resources).
The Identity Warehouse is a relational database (MySQL, SQL Server, Oracle, or DB2) that
stores identity information (profiles and entitlements) for all users across the enterprise. This
includes the access rights held across all systems and applications. The Extract-Transform-
Load (ETL) functionality in Oracle Identity Analytics and the direct interfaces to most
provisioning systems (Sun, IBM, Oracle, CA, BMC, and so on) allow for the import of user
identity and account information quickly and securely.
The hierarchical nature of the warehouse means that organizations can capture detailed
granular data from all applications. The scheduler built within Oracle Identity Analytics ensures
repeatability of the import process at a predetermined time. Oracle Identity Analytics also
captures the glossary description of each entitlement, which can be sent as a separate feed to
the repository.


Identity Warehouse (continued)
The glossary information provides business descriptions that are associated with the raw
entitlement data for improved usability and understandability. The complete entitlement data
can be correlated during the certification phase, and the entitlement hierarchy can be shown as
part of the drill-down entitlements. The advanced correlation engine built within Oracle Identity
Analytics ensures that the user account is correlated to the appropriate identity based on
defined correlation rules. Data owners and data classification can be assigned to individual
entitlements. Appropriate entitlements can be tagged as high-privileged to be used during
certification and reporting.


Identity Warehouse Contents

Consists of the following objects:
• Business Structures
• Users
• Roles
• Policies
• Applications
• Resources


Identity Warehouse Contents
You can review or manage data in the Identity Warehouse by clicking the Identity Warehouse
tab from the Administrative Interface. From here you can access the following:
• Business Structures
• Users
• Roles
• Policies
• Applications
• Resources


Business Structures

• Are hierarchical structures composed of Business Units
• Provide scope to Oracle Identity Analytics operations
• Can contain Business Units of any organizational grouping
• Impose no limitations on the number of Business Units

Example
Corporation

Client
Operations Marketing
Services

Human Information Product Professiona
Resources Technology Mgmt l Services


Business Structures
Oracle Identity Analytics performs operations such as role certifications and policy violation
scans within organizational groupings called business structures. A business structure provides
the scope of these operations and can consist of multiple business units to create a hierarchical
model of the organization. A business unit can represent entities such as departments, teams,
geographic locations, or any other type of organizational unit.
Organizations can be segregated into as many business structures with as many levels of
hierarchy as are required to represent teams and subteams within the organization. There is no
limit to the number of users who can be assigned to a business structure.


Users

• A person’s identity in Oracle Identity Analytics
• Comprehensive representation of the person:
– Necessary for correlation
– Necessary for attestation
– First Name, Last Name, Address, Phone, Email, Title,
Description, Employee ID, Manager, Location, and so on
• Populated from authoritative source
– Human Resources (flat file)
– Identity Manager application


Users
A user is a global identity to which various accounts are associated. A user can have multiple
accounts, but all the accounts are associated with a single global identity in Oracle Identity
Analytics. This global identity is defined under the Users View, which shows the entire list of
users who belong to the organization.
A user is a discrete, identifiable entity that has a business need to access or modify enterprise
information assets. Typically a user is an individual, but a user can also be a program, a
process, or a piece of computer hardware.
Users are associated with business structures in various ways. A user can be assigned to
several business structures based on access level and other details within an organization. A
business user has a manager or an application approver who is tasked with carrying out
various user-management and role-management functions on the user.
A naming convention for all users needs to be established. A common naming convention is a
combination of a user’s name in lowercase letters and a set of numbers. For example, John
Smith’s username might be josmit01. Usernames must be unique.


Users (continued)
The user store is the central platform, database, or directory where user records are stored.
Oracle Identity Analytics uses the user to populate identities within the Identity Warehouse.
Commonly used user stores include Active Directory, Exchange, ORACLE, SAP, UNIX, and
RDBMS Tables.
Initially, an organization in Oracle Identity Analytics is populated with users by using a feed
from an HR system. The HR system is used to create all the global identities in Oracle Identity
Analytics. Alternatively, the global identities can be created from a provisioning system such as
Oracle Waveset (formerly Sun Identity Manager).
Note: Oracle Identity Analytics is a data-heavy model and consists of several data elements
associated with a user. This is in contrast to Oracle Waveset, which maintains only enough
data to accurately identify and correlate users (a data-sparse model). Oracle Identity Analytics
can consist of hundreds of data elements, whereas Oracle Waveset consists of less than 10, by
default.


Roles

• Oracle Identity Analytics supports a role-based access
control model.
– Roles consists of applications and entitlements.
– Access to assets is provided through role assignment.
• Roles change based on organizational needs.
• Role definitions can be created based on:
– A top-down approach
– A bottom-up approach
– A combination of both
• Similar roles can be consolidated as appropriate.
• Roles can include other roles (role hierarchy).


Roles
Oracle Identity Analytics administers role-based access controls. Roles make it easier to assign
access levels to users and to audit those assignments on an ongoing basis. Rather than
assigning access levels to users directly, access levels are assigned to a role, the role is
assigned to individual users, and a user’s access level is determined by the roles assigned to
that user. Management of individual user rights becomes a simple matter of assigning one or
more roles to the user.
Role-based administration typically grows and expands as new situations occur. The main
advantage of using this approach is ease of implementation. Role-based administration can be
established in a centralized fashion, distributed throughout your network, or can consist of a
combination of both. Oracle Identity Analytics can be configured to match the unique structure
and needs of your organization. Roles can be defined in a hierarchical format, and segregation
of duties (SoD) can be administered through a role.
Roles typically represent a job function and can contain policies that describe the access that
individuals have within the organization. For example, a person can function as a manager, a
developer, and a trainer. In this case, three roles represent each job function because each
requires different privileges and access to different resources.


Roles (continued)
Roles provide the flexibility and power to enforce enterprise standards so that you can
accomplish the following:
• Manage users who perform the same tasks the same way no matter where they are
located in the enterprise
• Perform less work when managing users because you do not have to manually specify
privileges every time a change is made to a person’s job function
A role can be nested within another role. Role hierarchy can be defined for any level required in
an organization.
Roles have a life of their own and change as the organization changes. The role management
features within Oracle Identity Analytics enable organizations to maintain the life cycle of a role.
This includes comprehensive workflows for adding, modifying, and decommissioning of roles,
and provides the following features:
• Role consolidation allows for the comparison of roles based on underlying entitlements or
similarity in users.
• Role versioning ensures that all historical data is maintained for each role.
• Role certification ensures that the owner of the role can validate the content of each role.
• Role versus Actual analysis ensures that all access that the user has beyond that
provided by the role is monitored.
Note: Refer to the lesson titled “Performing Role Lifecycle Management” for more information
about role lifecycle management.


Role Hierarchy

• Consists of the following types of roles:
– Enterprise roles (highest level)
– Functional roles (based on job function)
– Auxiliary roles (can have a time limit)
• Typically follows an 80/20 Model:
– 80% of roles consist of enterprise and functional roles.
– 20% of roles consist of auxiliary roles.

80% Coverage 20% Coverage

Enterprise Roles Functional Roles Auxiliary Roles
Project IDM
Employee Contractor Manager MIS
Mgr Proj


Role Hierarchy
Similar to a business unit hierarchy, roles can exist in an n-level hierarchy, where top-level
roles assign more global entitlements and lower-level (child) roles assign more specific
entitlements. The highest level in the hierarchy consists of enterprise roles that define the
resources and entitlements that all users in a specific category obtain simply because they are
who they are. These might include an email account, access to the local area network (LAN), or
a nondigital asset such as an employee phone. Enterprise roles are typically assigned
automatically based on programmatic logic (rules).
Functional roles are more granular and provide entitlements based on the user’s job function
within the organization. For example, a manager can access the HR application to manage
employee data, or a project manager can have an account on the project server. Functional
roles can be assigned programmatically, or you can provide a process for users to request
access to such roles.
Approximately 80 percent of all users can be associated with the appropriate roles through
enterprise and functional roles. The remaining 20 percent of access is associated through an
auxiliary role.
Auxiliary roles are more focused and are typically associated with a specific resource or set of
resources. Users request access to auxiliary roles and are typically granted access for a limited
duration. Oracle Identity Analytics can associate an expiration date on auxiliary roles. After the
role’s end date has been reached, a user’s access to the entitlements associated with the role
causes a violation.


Audit Policies

• Are rules that specify segregation of duty violations
– A user with responsibility for accounts payable cannot also
be responsible for accounts receivable.
• Can span multiple resources
• Can be associated with multiple roles
• Can be evaluated to determine if any violations currently
exist
• Can cause a remediator to take action when the violation
is found


Audit Policies
An audit policy is a collection of audit rules that together enforce business policies that are
associated with segregation of duties. Suppose that you are responsible for both accounts
payable and accounts receivable and must implement procedures to prevent a potentially risky
aggregation of responsibilities in employees working in the accounting department. You might
create an audit policy that ensures that personnel with responsibility for accounts payable are
not responsible for accounts receivable.
Audit policies contain the following:
• A set of rules in which each rule specifies a condition that constitutes a policy violation
• A workflow that launches remediation tasks
• A group of designated administrators, or remediators, with permission to view and
respond to policy violations created by the preceding rules
Oracle Identity Analytics scans resources searching for policy violations. After a policy violation
is detected (in this scenario, users with too much authority), the associated workflow can
launch specific remediation-related tasks, including automatically notifying select remediators.


Segregation of Duties (SoD)

• SoD is the control used to separate duties and
responsibilities.
• Control over all phases of a transaction is limited.
• Potential damage from the actions of one person is
reduced.
• Oracle Identity Analytics determines SoD violations by
evaluating:
– Roles
– Policies


Segregation of Duties (SoD)
You define segregation of duties (SoD) to separate certain duties or areas of responsibility so
that they cannot be assigned to the same person. By defining SoD, you reduce opportunities
for unauthorized modification or misuse of data or services. SoD is a primary internal control
that is intended to prevent (or decrease the risk of) errors or irregularities, identify problems,
and ensure that corrective action is taken. This is done by ensuring that no individual user has
control over all phases of a transaction. Oracle Identity Analytics determines SoD violations by
reviewing roles and policies.


SoD Matrix


SoD Matrix
This slide demonstrates an SoD matrix of the roles that can be associated with a user and
those that cannot be combined.
Imagine having to maintain matrixes like this and attempting to find violations manually for the
entire enterprise. Oracle Identity Analytics does this for you out-of-the-box.


Applications

• Include a group of entitlements for reporting purposes
• Use business-level verbiage
• Can span multiple resources

Communications

Directory Email Calendar
Server Server Server


Applications
Applications provide a method of grouping entitlements across one or more resources for
auditing purposes. Applications can consist of any combination of resources, entitlements,
group memberships, and so on. This enables application owners to use language that is more
attuned to business during the certification process instead of using more cryptic, technical
language.
The example in this slide demonstrates how three different resources (Directory Server, Email
Server, and Calendar Server) are combined under a single Communications application. The
owner of the Communications application can certify users associated with that application
more easily than attempting to certify each resource or entitlement individually.


Resources

• Resources are systems and enterprise information assets.
• Each is an instance of a resource type.
• Each is an authoritative source for user entitlements.
• Each has an owner who certifies user entitlements.

Resource Types

Enterprise
Package Custom
Operating Application Application Non-digital
Directories Databases Mainframes Systems s s Assets


Resources
Resources are the systems and enterprise information assets that users require in order to
perform their jobs. In Oracle Identity Analytics, a resource is an instance of a resource type,
which is a grouping of similar resources. For example, multiple Oracle database instances may
compose a resource type named Oracle, where each individual database instance is a
resource.
Common resource types include platforms (Windows 2000, UNIX, or an RACF mainframe) or
business applications (such as billing and accounts payable applications). User entitlements
are collected from resources and stored in the Identity Warehouse. Resource owners run
reports against their resources and certify that the appropriate users have the proper
entitlements.
Note: In the previous releases of Sun Role Manager, the term endpoint was used to denote a
resource, whereas the term namespace was used to denote a resource type.


Attributes

• Resources contain attributes.
– User-based (uid, gid, cn, sn)
– Policy-based (groups)
• Attributes are necessary for:
– Role engineering (role mining)
– Determining separation of duty policy violations
• Attributes can be combined into categories.


Attributes
Resources consist of data elements that pertain to user and policy information. For example, a
user account on a UNIX system would include attributes such as uid, gid, gecos, and
shell. A user object in a directory server would include attributes such as cn (common name),
sn (surname or last name), and quite possibly the groups that the user belongs to. Oracle
Identity Analytics evaluates this information to determine if the user’s presence on the resource
or his or her capabilities on the resource violates any business policies.
You can group similar types of attributes to form an attribute category that can be used for data
mining purposes. When defining resources, you can create attribute categories and specify the
attributes within those categories. You can also specify other characteristics such as whether
the attribute is used in the role mining process (Minable) or the certification process
(Certifiable).
Note: Before you start a role mining job, you must specify the attributes that are minable.
Attempting to run role mining without any attributes set as minable will result in an error. See
the lesson titled “Performing Role Mining” for more information.


Populating the Identity Warehouse

To populate the Identity Warehouse, perform the following
steps:
1. Create users.
2. Create resources.
3. Create a business structure.
4. Assign users to the business structure.
5. Correlate users with resource accounts.
Data can be entered manually or through a bulk load process.


Populating the Identity Warehouse
This slide describes the process for populating the Identity Warehouse.


Populating Data Manually

• The graphical user interface can be used to enter data.
• Data items must be entered manually, one at a time.
• Some items (for example, Users) require that you enter
information in two passes.
– Basic account creation (User Name, First Name, and Last
Name)
– Additional data elements (Title, Address, and Email)
• However, this is not an efficient process when processing
large amounts of data.


Populating Data Manually
You can use the graphical user interface to add Business Structures, Users, Roles, Policies,
Applications, or Resources, but it can become a time-consuming process entering them one at
a time.
Additionally, some items (such as Users) require that you enter data in two phases: one to
create the basic account and a second pass to add additional data.
Adding information through Web forms is convenient when you are managing one data element
at a time, but it is not an efficient process when you have large amounts of data to process.


Adding Additional Data Elements


Adding Additional Data Elements
This slide shows the interface for managing users within the graphical user interface.


Importing Data (Bulk Load of Data)

Administration > Configuration > Import/Export > Schedule Job
> Job Type.
Job types consist of the following:
• Import Users
• Import Roles
• Import Accounts
• Import Policies
• Import Business Structure
• Import Resource Metadata
• Import Resources
• Import Glossary


Importing Data (Bulk Load of Data)
This slide lists the types of data that you can import into the Identity Warehouse.


Configuring a Provisioning Server

• A provisioning server is a server or system that
administers user accounts on target resources.
• Supported provisioning platforms include:
– Oracle Waveset
– Oracle Identity Manager
– Computer Associates Identity Manager
– IBM Tivoli Identity Manager
– Flat file
• Before performing a bulk load of data, you must configure
a provisioning server.


Configuring a Provisioning Server
Oracle Identity Analytics is a role lifecycle and certification tool. It does not manage user
accounts on target systems. Oracle Identity Analytics can, however, consume data from
account management systems such as Sun Identity Manager, and can instruct such systems to
perform various actions on user accounts that violate corporate policies.
In the context of Oracle Identity Analytics, account management systems are called
Provisioning Servers. You must configure a Provisioning Server before performing actions such
as populating the Identity Warehouse.
Oracle Identity Analytics supports various provisioning platforms, including Sun Identity
Manager, Oracle Identity Manager, Computer Associates Identity Manager, and IBM Tivoli
Identity Manager. Additionally, a system file can be considered to be a Provisioning Server if it
contains user data.


Provisioning Server Parameters

• Identity Manager • Flat File Parameters:
Application Parameters: – Connection Name
– Connection Name – Import Drop Location
– SPML URL – Import Complete
– User Name Location
– Password – Import Schema Location
– Role Consumer – Export Drop Location
– Export Schema Location


Provisioning Server Parameters
Oracle Identity Analytics uses the Service Provisioning Markup Language (SPML) to interface
to provisioning solutions from Sun, Oracle, Computer Associates, and IBM. To use one of these
platforms as a Provisioning Server, you need to specify connectivity information such as the
method for communicating with the server (SPML URL) and the credentials of a user who can
perform the operation (User Name/Password). When this is completed, you can use the
information contained within the Provisioning Server to populate and maintain users in the
Identity Warehouse.
If you have not implemented a user provisioning solution from one of the supported vendor
platforms, you can still specify a Provisioning Server based on a file. The file must contain the
information necessary to populate the user data elements in the Identity Warehouse. It is your
responsibility to obtain the necessary data from one or more authoritative sources and to
provide it in a format that can be consumed by Oracle Identity Analytics.
To configure a file as a Provisioning Server, you must specify the following folder locations:
• in – Location of inbound (imported) data files
• schema – Location of the attribute mapping files


Provisioning Server Parameters (continued)
• complete – Location of archived data files (after the import is completed)
Note: It is common to schedule tasks within Oracle Identity Analytics to periodically read data
from files. This enables you to keep the data in the Identity Warehouse current. Take care,
however, to ensure that the file being consumed by Oracle Identity Analytics is complete and
that it is not updated while it is being processed because this will cause the import to terminate
unexpectedly. Consider adding a staging directory to the drop location for files that are in the
process of being updated and moving files from staging to the import drop location when the
processing has been completed.
In addition to importing data from files, you can also export data from the Identity Warehouse to
files. This is especially useful when moving customizations between different environments
such as development, staging, and production. Before exporting data, you must provide the
following folder locations for the file-based Provisioning Server:
• export – Location of outbound (exported) data files
• schema – Location of the attribute mapping files


Importing from File Processing

1. Create a Provisioning Server (file-based).
2. Export data from an authoritative source.
3. Convert data into a format that is consistent with the
schema file.
4. Copy the data file into the import drop location.
5. Perform import of data (schedule if desired).
6. Review the files in the import complete location.
7. Review the status in the graphical user interface.
8. Review the status log (if necessary).


Importing from File Processing
To import data from files, perform the following steps:
1. Create a file-based Provisioning Server and specify the import drop location, import
schema location, and import complete location.
2. Export the data from the user store, which is the authoritative source for all user data.
3. Convert the data to a format that matches the definitions within the schema file.
Following is an example of a schema file for importing Active Directory accounts:
## Example of a Scheme file for accounts
## File Name: <shnsn> _accounts.rbx (where <shnsn> is
shortNamesapceName)
## this file will be used for reading <shnsn> _accounts in the data
folder.
#
# @iam:namespace name="Windows Active Directory" shortName="AD"
#
# Start Post Line Read Script
# void script(Object account){


Importing from File Processing (continued)
# account.setNamespaceName("Windows Active Directory");
# account.setUserName(account.getId());
# }
# End Post Line Read Script
#
name<CorrelationKey>,accountId,userName,accountLocked,adGroups,country
,de
partment,disabled,division,email,employeeNumber,exchangeServer,expireP
ass
word,faxNumber,firstname,lastname,fullname,homeAddress,homeCity,homeSt
ate
,homeZip,homeMDB,homeMTA,homePhone,middleInitial,jobTitle,mailNickName
,ma
nagerId,managerDN,mDBOverHardQuotaLimit,mDBOverQuotaLimit,mDBStorageQu
ota
,mDBUseDefaults,mobilePhone,objectGUID,uSNChanged,telephone,domain,end
poi
nt
Note: Ensure that you have all the necessary attributes based on the schema definition. If you
do not have all the necessary attributes, the data will not be imported.
4. Place the data file into the import drop location.
5. Start the import process from the graphical user interface.
This can be performed from the following location:
Administration > Configuration > Import/Export > Schedule Job > Job Type
After the import has been initiated, the file is read from the import drop location, and data
is imported into the Identity Warehouse according to the mappings defined in the schema
file. Import drop files are then time-stamped and moved to one of the following folders
based on whether the import was successful:
- Successful completion – complete/success
- Unsuccessful completion – complete/error
6. Review the status of the import process in the following areas:
- Graphical user interface
- Import complete location
7. If you detect an error during the import process, you may need to review the Oracle
Identity Analytics log file (rbacx.log).


Importing from File: Rules

• The names of the schema and data files must be
consistent.
– Schema File: businessstructure_01.rbx
– Data File: businessstructure.csv
• The following data file formats are allowed:
– Extensible Markup Language (XML)
– Comma-separated values (CSV)
• The contents of the schema files are not case-sensitive.
• Contents of data files are case-sensitive.


Importing from File Rules
The data drop files follow certain simple rules:
• File names: Although the names of the schema and data files do not need to match
exactly, they do need to contain the same basic information. You can specify an
underscore character in the name of the import file to provide some level of version
control. Everything to the left of the import file name should match the name of the
schema file.
• Data formats: Oracle Identity Analytics can read data from either extensible markup
language (XML) or comma-separated values (CSV) files.
• Case sensitivity: The data contained in the input file is case-sensitive, but the fields
defined in the schema file are not.


OIA administration

Recomendados

Recomendados

Más contenido relacionado

Similar a OIA administration

Similar a OIA administration (20)

Último

Último (20)

OIA administration