D68340GC20 SG

Oracle Identity Analytics 11gR1: Administration
Student Guide
D68340GC20 Edition 2.0 December 2010 D71223
Authors Steve Friedberg David Goldsmith Technical Contributors and Reviewers Neil Gandhi David Goldsmith Stephan Hausmann Stephen Man Lee Harsh Patwardhan Editors Vijayalakshmi Narasimhan PJ Schemenaur Graphic Designer Satish Bettegowda Publishers Syed Ali Sumesh Koshy
Copyright 2010, Oracle and/or its affiliates. All rights reserved. Disclaimer 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 in any way. Except where your use constitutes "fair use" under copyright law, you 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 the express authorization of Oracle. The information contained in this document is subject to change without notice. If you find any problems in the document, please report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This document is not warranted to be error-free. Restricted Rights Notice If this documentation is delivered to the United States Government or anyone using the documentation on behalf of the United States Government, the following notice is applicable: U.S. GOVERNMENT RIGHTS The U.S. Governments rights to use, modify, reproduce, release, perform, display, or disclose these training materials are restricted by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract. Trademark Notice Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Contents
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 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 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 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) The Wave Methodology (Step 2 of 7) The Wave Methodology (Step 3 of 7) The Wave Methodology (Step 4 of 7) The Wave Methodology (Step 5 of 7) The Wave Methodology (Step 6 of 7)
6-8 6-11 6-12 6-14 6-16 6-17

v
The Wave Methodology (Step 7 of 7) 6-19 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: A growing number of applications A constantly changing user population The need to prevent or detect inside threats The need to meet regulatory compliance
Security: Minimize Risk
Business: Open Access
Reduce Costs
Sarbanes -Oxley
GrammLeachBliley Act
The Enterprise
Improve Quality of Service
European Data Protection Directive
Health Insurance Portability & 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 todays 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 companys 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 users capabilities on that resource? Who authorized or created the users account? Does the users presence violate any business or security policies?
How do companies determine this information today?
Achieving Compliance
A common theme behind a companys 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: Provides access rights grouping mechanism Contains systems and privileges Makes assignments based on job function Provides mechanism for detecting violations
Branch Manager Bank Teller
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 users 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 companys 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 control across the enterprise Enforcing and proving compliance
Acquiring and providing access quickly Understanding and attesting to access
Mapping control objectives into security and access policies Lacking IT knowledge 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 users 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 individuals assigned roles, and an individuals 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? Employees Access Management
Oracle 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 users 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 (formerly Sun Role Manager, before that Vaaus 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. Suns 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 LifeCycle Management
Role Framework Role Maintenance Role Mining Role Certification
Identity Compliance
Access Certification Dashboard/Analytics Policy Enforcement 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

Administrative
Application Server Load Balancer
Nonconnected Systems
Network Failover Device
Managed 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 closedloop 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 Identity-based Controls Run-time Enforcement of Identity-based Controls
Users & Accounts
Roles, Policies, & Rules
Oracle Identity Analytics Role Life Cycle Mgmt Detective Identity Compliance
Oracle Identity Manager Identity Life Cycle Mgmt Preventative Identity 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 Cycle Mgmt User Life Cycle Mgmt End User Self Service Identity 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 users 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. Prioritize divisions. Prioritize applications. Build Entitlement Warehouse. Import data. Collect and correlate entitlements to identities. Form business units. Finalize Candidate Roles. Incorporate suggested changes. Submit roles to role owners for approval. Perform Role Discovery. Define role membership. Define role entitlements. Analyze/Review Role Exceptions. Handle exceptions via auxiliary roles or ad hoc access requests.
Review Candidate Roles. Review and approve roles. Review and approve entitlements.
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* Access Manager Adaptive Access Manager Enterprise Single Sign-On Identity Federation 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.
Directory Services
Identity Manager
Directory Server EE Internet Directory Virtual Directory
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 Administrators Guide Users Guide
System Administrators and Service Providers

Installation and Upgrade Guide System Administrators Guide Database Administrators Guide
System Integrators
System Integrators 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-TransformLoad (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
Operations
Marketing
Client Services
Human Resources
Information Technology
Product Mgmt
Professiona 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 persons 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 users name in lowercase letters and a set of numbers. For example, John Smiths 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 users 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 persons 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 Enterprise Roles Employee Contractor Functional Roles Manager Project Mgr 20% Coverage Auxiliary Roles MIS IDM 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 users 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 roles end date has been reached, a users 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 Server
Email Server
Calendar 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
Directories
Databases
Mainframes
Operating Systems
Enterprise Package Application s
Custom Application s
Non-digital 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 users 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 Application Parameters:
Connection Name SPML URL User Name Password Role Consumer
Flat File Parameters:

Connection Name Import Drop Location Import Complete Location Import Schema Location 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.
Debugging Import Errors

How to identify errors:
Review the Import/Export log.
Review files in the drop locations error directory. Review the rbacx.log file.
How to debug errors:

Review exceptions in the Import/Export log. Enable extended logging and restart the server.
Debugging Import Errors

During the processing of an import job, Oracle Identity Analytics provides details about its success or failure. This information can provide valuable details about what when wrong during an import process. You can access this information from the GUI at the following location: Administration > Auditing & Events > Import/Export Logs The Import/Export Logs page contains an index with the following information: Job (import/export) Object type being processed (users, business structure, and so on) Brief description of the job Time stamp Job results (Success/Failure)
Debugging Import Errors Exception

Time Stamp
12/01/2009 12:00:01
Exception Exception Level Type

ERROR BAD RECORD FORMAT
Description
File: businessstructure.csv, line no.1, doesn't match businessstructure.rbx schema, found [Schema File,Data File,Database Table] File: businessstructure.csv, line no.2, doesn't match businessstructure.rbx schema, found [businessstructure.rbx,businessstr ucture.csv,businessUnits] File: businessstructure.csv, line no.3, doesn't match businessstructure.rbx schema, found [,,] Aborting BusinessUnit import, file: businessstructure.csv Unsuccessful business structure import, file: businessstructure.csv
12/01/2009 12:00:01
ERROR
BAD RECORD FORMAT
12/01/2009 12:00:01
ERROR
BAD RECORD FORMAT
12/01/2009 12:00:01 12/01/2009 12:00:01
ERROR ERROR
TOO MANY ERRORS IMPORT FAILED
Debugging Import Errors Exception

You can obtain more information by clicking the link in the Description column. If errors occurred during the import process, you can see the number of successful records processed, as well as those that were unsuccessful. Clicking the Show Exceptions button enables you to see details about why the job failed. The slide provides an example of exception data found during the import of business structure data. This example shows that the format of the data contained in the businessstructure.csv file does not match the structure found in the businessstructure.rbx schema file. The import job attempted to process the records found in the businessstructure.csv file, but stopped after it reached the maximum number of errors allowed (as indicated by the TOO MANY ERRORS exception type). The solution to this situation is to correct the inconsistency between the two files and attempt to process the import again. You can also look at the contents of the rbacx.log file if you find that the import drop file contains errors. This log file contains valuable details for determining debugging failed imports as well. If the file does not contain enough data to make this determination, you can increase the amount of data output to the log file by setting the logging level in the log4j.properties file to DEBUG as follows: log4j.logger.com.vaau.rbacx.iam=DEBUG
Job Scheduling
Oracle Identity Analytics includes a scheduler application (Quartz Scheduler). Data imports and exports can be scheduled to run on a periodic basis. A preconfigured set of jobs is included. Methods for scheduling jobs include:
Graphical user interface Direct edit of configuration files
A Provisioning Server is required.
Job Scheduling
Oracle Identity Analytics provides a scheduler that enables you to set a specific time for imports and exports. You can schedule import and export jobs by using the scheduler in the graphical user interface, or you can schedule jobs by manually editing configuration files. The following jobs are included with Oracle Identity Analytics: Accounts Maintenance Glossary Import Roles Import Policies Import Rule Based Role Assignment Note: Before you can import data into Oracle Identity Analytics, you need to configure a Provisioning Server.
Job Scheduling Through the GUI
Job Scheduling Through the GUI

You can access the interface for scheduling jobs through the graphical user interface (GUI) by navigating to the following location: Administration > Import/Export > Schedule Job This slide demonstrates the various settings that can be configured when scheduling the job through the GUI. The processing of various tasks (such as importing users) is performed by the scheduler by using the JavaBeans definitions defined in the scheduling-context.xml file. Most tasks are originally commented out in this file, and modifications made through the GUI uncomment the appropriate JavaBeans to allow the scheduler to access that functionality. Additionally, the scheduler uses the definitions contained in the jobs.xml file to define when and how often to run the job. The format of the data contained in this file is similar to UNIX cron expressions. The GUI makes it easy to schedule jobs without having to understand the syntax for modifying these files directly. You can, however, edit these files directly to schedule jobs.
Job Scheduling Through Direct Edit

Two configuration files control the scheduler:
scheduling-context.xml jobs.xml
Edit these files as follows:

scheduling-context.xml Enable or disable scheduled tasks. jobs.xml Define the schedule for when the job will run.
Restart the application server.
Job Scheduling Through Direct Edit

Oracle Identity Analytics includes two configuration files that control the scheduler. scheduling-context.xml Edit this file to enable (or disable) the scheduled tasks, such as users import, accounts import, and others. jobs.xml Edit the cron expressions in this file to define a schedule for each job. Note: These two files are located in the $RBACX_HOME/WEB-INF folder, and the contents can vary based on the application server being used. You can schedule jobs, including import and export jobs, by manually editing these configuration files and restarting the application server. To manually edit the configuration files, perform the following steps: 1. Uncomment the job in schedule-context.xml. <property name="jobDetails"> <list> 
          <ref bean="fullTextIndexMaintenancedJob"/> <ref bean="workflowStepSLAJob"/> <ref bean="roleMembershipJob"/> </list> </property> For example, if you want to import users on a periodic basis, you can replace the line containing usersImportJob  with the following: <ref bean="usersImportJob"/> 2. Locate usersImportJob and usersImportTrigger in the jobs.xml file and configure the schedule as follows: <bean id="usersImportTrigger" class="org.springframework.scheduling.quartz.CronTriggerBean"> <property name="jobDetail"> <ref bean="usersImportJob"/> </property> <property name="cronExpression"> <value>0 0/5 * * * ?</value> </property> </bean> <bean id="usersImportJob" class="org.springframework.scheduling.quartz.JobDetailBean"> <property name="name"> <value>Users Import</value> </property> <property name="description"> <value>Users import Job</value> </property> <property name="jobClass">
Job Scheduling Through Direct Edit (continued)

<value>com.vaau.rbacx.scheduling.manager.providers.quartz.jobs.IAMJob </value> </property> <property name="group"> <value>SYSTEM</value> </property> <property name="durability"> <value>true</value> </property> <property name="jobDataAsMap"> <map>  <entry key="jobOwnerName"> <value>REPLACE_ME</value> </entry>  <entry key="usersToNotify"> <value>REPLACE_ME</value> </entry> <entry key="IAMActionName"> <value>ACTION_IMPORT_USERS</value> </entry> <entry key="IAMServerName"> <value>FILE_SERVER</value> </entry>  <entry key="NEXT_JOB"> <value>rolesImportJob</value> </entry> </map> </property> </bean> Note: The date/time format in the trigger follows standard UNIX cron format.
Database Entries for Job Scheduling

Jobs information is stored in the following database tables:
Database Table Name qrtz_job_details qrtz_triggers qrtz_cron_triggers Schedule definition Function Job-specific information
These tables are updated when jobs are configured from either the GUI or edited manually. Jobs can be disabled but there is no interface in Oracle Identity Analytics to delete them.
Database Entries for Job Scheduling

Oracle Identity Analytics maintains three tables that are updated to reflect schedule information. These tables are updated whether the job is configured through the GUI or by manually editing configuration files. The qrtz_job_details table maintains the job definition. Following is an example of the data contained in this table: job_name: Import Organizations job_group: IAM description: This job performs a periodic update of the business structure. job_class_name: com.vaau.rbacx.scheduling.manager.providers.quartz.jobs.IAMJob is_durable: 1 is_volatile: 0 is_stateful: 0 requests_recovery: 0 job_data: Blob
Database Entries for Job Scheduling (continued)

The qrtz_triggers table maintains information pertaining to the next time the trigger is to fire. trigger_name: tImport Organizations trigger_group: tIAM job_name: Import Organizations job_group: IAM is_volatile: 0 description: NULL next_fire_time: 1259686800000 prev_fire_time: -1 priority: 5 trigger_state: WAITING trigger_type: CRON start_time: 1257856703000 end_time: 0 calendar_name: NULL misfire_instr: 0 job_data: Blob The qrtz_cron_triggers table maintains the cron definition for the trigger. trigger_name: tImport Organizations trigger_group: tIAM cron_expression: 00 00 12 1 1,2,3,4,5,6,7,8,9,10,11,12 ?* time_zone_id: America/New_York
After you have configured a job, you can disable it, but there is no direct interface for deleting it. If you want to remove a particular event from these tables, you must directly edit the database tables.
Summary
In this lesson, you should have learned to describe the following: Oracle Identity Analytics terminology Identity Warehouse Methods for importing data Job scheduling
Practice 2 Overview: Importing and Setting Up Identity Warehousing

This practice covers the following topics: Importing Users Defining Resource Type Metadata Setting Up Business Structures Importing Accounts Creating Applications Importing Roles Importing Policies Managing Resource Data
Configuring Security
Objectives
After completing this lesson, you should be able to: Describe the Oracle Identity Analytics authorization model Manage Oracle Identity Analytics Users (OIA Users) Manage Oracle Identity Analytics Roles (OIA Roles) Describe proxy assignments Configure Oracle Identity Analytics to authenticate against alternate credential stores
Objectives
Discussion: The following questions are relevant to understanding the topics covered in this lesson: How can you create a delegated administrative environment within Oracle Identity Analytics? Can you assign different rights to different administrators in Oracle Identity Analytics? How can you configure Oracle Identity Analytics to authenticate administrators against a directory server?
Oracle Identity Analytics Users (OIA Users)

OIA Users are not the same as global users.
Global users are imported into the Identity Warehouse. OIA Users are administrators within Oracle Identity Analytics.
OIA Users require privileges to perform tasks.

They manage Identity Warehouse, perform certifications, and so on. Privileges are assigned indirectly through Oracle Identity Analytics Roles (OIA Roles).
Oracle Identity Analytics Users (OIA Users)

Oracle Identity Analytics Users (OIA Users) are administrators who require privileges within Oracle Identity Analytics to attest, revoke, and remediate certifications and policies, or carry out various other tasks. Note: OIA Users are not the same as global users who are imported from a user store. OIA Users are created in the Oracle Identity Analytics user interface and stored in separate database tables from global users. Privileges are associated with OIA Users through roles. Roles are correlated by application and correlation parameters, and are configured in the security-conf-context.xml configuration file. OIA Users can be managed by navigating to the following page in the Oracle Identity Analytics interface: Administration > Access Control > New OIA User
Oracle Identity Analytics Users (OIA Users) (continued)

After you select New OIA User, you will be taken to the New OIA User Wizard, where you can create a new OIA User. Complete the following steps to configure a new OIA User: 1. Enter information into the following fields: - User Name - First Name - Last Name - Password/Confirm Password - E-mail 2. Select the Enabled check box to enable this user now and click Next. 3. Select the appropriate System Roles for this OIA User and click Next. The following System Roles are available: - OIA Admin - Certification Manager - Policy Violation Remediator - Role Engineer Administrator - Policy Owner (Identity Audit) - Warehouse Administrator - Workflow Designer - Reporting Administrator - Compliance Administrator - Audit Administrator 4. Assign the scope of this OIA Users influence by associating the appropriate business structure with the OIA User. 5. Click Finish. This OIA User can now log in to the user interface with the credentials you provided in Step 1. He or she can perform the operations defined by the System Roles selected in Step 3 within the scope of the business structure assigned in Step 4. Note: You must complete these steps even if you are using an alternate credential store. See Alternate Credential Store later in this lesson for more information.
Oracle Identity Analytics Roles (OIA Roles)

OIA Roles are not the same as roles in the Identity Warehouse.
Identity Warehouse roles are used for certification. OIA Roles are used to assign privileges to OIA Users.
OIA Roles consist of one or more system privileges. System privileges specify:
What an OIA User can see (visibility) What an OIA User can do (capability)
Any OIA Role with business privileges becomes a Business Role. Administrators can create and edit OIA Roles.
Oracle Identity Analytics Roles (OIA Roles)

Oracle Identity Analytics Roles (OIA Roles) are different from the roles contained within the Identity Warehouse. Whereas Identity Warehouse roles are used for certification purposes, OIA Roles are used to assign privileges to OIA Users which, in turn, provides them with certain capabilities with a particular scope. OIA Roles consist of one or more of the following system privileges: System-level privileges: Access to menus, screens, and so on Business-level privileges: Access to view, attest, and update logical groups of data (users, roles, and so on) Usually system-level privileges are appropriate for administrative roles, and business-level privileges are appropriate for business user roles. System-level privileges and business-level privileges are added to OIA Roles to provide capabilities (or rights) within Oracle Identity Analytics as needed. These OIA Roles are subsequently assigned to OIA Users based on the tasks that those users need to complete. Note: Any role with business privileges becomes a Business Role.
Oracle Identity Analytics Roles (OIA Roles) (continued)

Oracle Identity Analytics includes nine roles that work out-of-the-box and that you can edit or delete as needed. You can add additional roles as necessary. Note: Rather than modifying existing roles, it is a best practice to add new roles that contain your own customizations. OIA Roles can be managed by navigating to the following page in the Oracle Identity Analytics interface: Administration > Access Control > New OIA Role After you select New OIA Role, you will be taken to the New OIA Role Wizard, where you can create a new OIA Role. Perform the following steps to configure a new OIA Role: 1. Enter information in the following fields: - Role Name - Description 2. Click Next. 3. Select the appropriate System Privileges for the OIA Role and click Next. Examples of System Privileges include Create Business Structure, Create User, Run Custom Reports, and so on. 4. Select the appropriate Business Structure Privileges for the OIA Role. Examples of Business Structure Privileges include Add Child Business Structure to Business Structure, Add Users to or Remove Users from Business Structure, Sign Off Reports, and so on. 5. Click Finish. This OIA Role can now be associated with an OIA User.
OIA Role Creation
OIA Role Creation

This slide demonstrates the interface for managing OIA Roles. Oracle Identity Analytics includes several default OIA Roles as follows: System Administrator (currently RBACx Admin) Role Administrator Compliance Administrator Certification Administrator Identity Audit Administrator Reporting Administrator Manager Application Owner Role Owner Role Engineer Glossary Owner Scheduling Administrator Workflow Designer Note: Default OIA Roles are editable. In most cases, default values eliminate the need to create new OIA Role definitions. If new OIA Roles are necessary, however, default values can be used as a starting point and provide a template that administrators can build upon, which saves time during the deployment process.
OIA Role Visibility
The OIA Users interface depends on the OIA Role. Dashboard Tabs Privileges
OIA Role Visibility

Selection of a particular OIA Role (or a set of OIA Roles) affects what an OIA User can see within Oracle Identity Analytics. This has an effect on the dashboard that is displayed when the OIA User first logs in and controls which tabs the OIA User sees when he or she logs in to the user interface. The association of a particular OIA Role also controls the privileges that the OIA User has within the pages he or she is allowed to see.
OIA Users/Roles Database Tables

OIA Users and Roles are stored in the following database tables:
Database Table Name rbx_user rbx_roles rbx_role_acegi_roles Privileges Function OIA User information
OIA Users/Roles Database Tables

OIA Roles are composed of privileges and assigned to OIA Users to enable them to perform various tasks within the graphical user interface. This slide lists the tables that contain the definitions and entries for OIA Users, OIA Roles, and privileges.
Proxy Assignments
OIA Users can delegate certification-related duties. Proxy assignment can be made to another OIA User. Delegations cannot be set for more than 30 days.
Proxy Assignments
If an OIA User is on leave or vacation, critical tasks such as Certifications or Role Approvals will be placed on hold and may have an impact on the overall business. In such instances, an OIA User can delegate his or her tasks to another OIA User to act on his or her behalf. This is called proxy assignment. OIA Users can set proxy assignment for a maximum of 30 days. Attempting to go beyond that time frame will result in an error in the user interface.
Alternate Credential Store

OIA User credentials can be stored in an external directory.
Sun Directory Server Microsoft Active Directory
The username attribute for the OIA User must exist in the target system.
rbx_user Username Target System NetBIOSDomain\sAMAccountName
(where username = sAMAccountName) Users should be correlated based on the email attribute.
Alternate Credential Store

OIA User credentials are stored in the Identity Warehouse by default, but you can elect to authenticate against an external credential store instead. Oracle Identity Analytics supports the following alternate credential stores: Sun Directory Server Microsoft Active Directory You still need to create the OIA User in the user interface, and Oracle Identity Analytics will continue to maintain database entries for the OIA User in the rbx_user table. Authentication for the OIA User, however, will be performed against the alternate credential store instead of the credentials stored in the Identity Warehouse. To provide this feature, the username attribute in the target system must match the username field in the rbx_user table. If the alternate credential store is Active Directory, it must match the sAMAccountName attribute. A method of correlating OIA Users in the rbx_user table and those contained in the alternate credential store would be to use the email attribute.
Summary
In this lesson, you should have learned to: Describe the Oracle Identity Analytics authorization model Manage Oracle Identity Analytics Users (OIA Users) Manage Oracle Identity Analytics Roles (OIA Roles) Describe proxy assignments Configure Oracle Identity Analytics to authenticate against alternate credential stores
Practice 3 Overview: Configuring Security

This practice covers the following topics: Configuring Oracle Identity Analytics Security Configuring LDAP Authentication
Configuring Identity Certification
Objectives
After completing this lesson, you should be able to: Describe security challenges faced by organizations Describe the benefits of an automated certification process Establish a certification environment Configure the Oracle Identity Analytics Glossary Describe the identity certification process Perform an identity certification
Objectives
Discussion: The following questions are relevant to understanding the topics covered in this lesson: How can an identity certification process address security challenges? What are the steps involved in identity certification? How can certification be automated and how can it be managed? How can the Oracle Identity Analytics Glossary provide context to identity certification?
Security Challenges
Outside threats:
Identity theft Breaches Lost or stolen data
Inside threats:
Complex organizational structure Expanding geographical footprint Multiple areas of business
Reaction to regulatory compliance
Security Challenges
The explosive global growth within organizations across verticals has created unprecedented security challenges. Even as companies battle security threats from the outside, complex organizational structures, an expanding geographical footprint, and multiple areas of business are paving the way for ever-increasing threats from the inside. Compliance laws such as Sarbanes-Oxley, HIPAA, and Model Audit Rule (MAR) are forcing companies to streamline their access-control review processes. Organizations need to strike a balance: tighten information security without jeopardizing the business agility of the enterprise and achieve the nirvana state of least privilege for employees.
Identity Certification
Is the process of reviewing employees entitlements to access applications and/or data Is performed by managers who are responsible for authorizing or revoking access Can be scheduled on a regular basis to meet compliance requirements Ensures that access is aligned with need Is a necessary step in meeting compliance Should be automated
Identity Certification
To address security challenges, companies must control access to system resources and thus prevent unauthorized personnel from accessing or compromising these systems. This involves a proactive approach during the account creation process, but also involves verification or a reactive approach. To ensure that users have appropriate access rights across the organization, companies must consistently monitor mission-critical systems and certify any accounts found. Certification (or attestation) is the process of evaluating user entitlements across system applications or data to ensure that users have access to only those systems required to perform their jobs. A well-followed certification process addresses the security challenges faced by todays organizations and provides the tools necessary to meet regulatory compliance. Managing and auditing enterprisewide attestations is a major challenge, however, for companies with a large number of employees. Because individual users can have access to a multitude of platforms, systems, and applications, organizations need an easy-to-use tool that managers can use to review user entitlements on a regular basis. Moreover, federal requirements require time-based certifications, granular entitlements, and so on. To meet these challenges, companies are moving away from cumbersome, manual access control processes and embracing an automated mechanism that effectively monitors the fundamental security challenge: who has access to what, and who has approved the access.
Automated Certification: Benefits

Accurate monitoring and management of access Ability to filter and review access to critical applications End-to-end monitoring Comprehensive audit trail Organized reminder and escalation workflow Direct remediation of accounts Minimized down time
Automated Certification: Benefits

The benefits of an automated certification process include the following: Accurate monitoring and management of access by relevant stakeholders in the organization Ability to filter and review access to only critical applications, thereby saving time End-to-end monitoring by reviewing access to applications, resources, attributes, and roles Availability of archived certification reports, providing a comprehensive audit trail Organized reminder and escalation workflow to ensure that an organization meets compliance deadlines Ability to directly remediate accounts from the provisioning solution based on revocations made during the certification process Minimizing down time and maximizing the organizations return on investment (ROI)
Certification Environment
Establish a certification environment before attempting to perform certifications. A certification environment consists of the following:
Select participants (actors). Select applications, resources, and attributes. Create labels. Configure email templates.
Certification Environment
There are several things to consider before performing an identity certification. Certification Participants (Actors) First, you need to understand who will participate in the certification process. These participants are called actors. The following table describes the types of actors that are typically involved in the identity certification process and a brief description of each actor. Actor Name Certifier User Manager Access Reviewer Application Owner Role Owner Description A generic term that signifies a person who is responsible for reviewing and completing any kind of certification A manager with direct reports. Users report to a user manager. Designated personnel responsible for reviewing user access Designated personnel responsible for reviewing user access on a particular target system Designated personnel responsible for reviewing a role and its content
Certification Environment (continued)

Actor Name Data Owner Oracle Identity Analytics Admin Description Designated personnel responsible for reviewing access to an attribute value An administrator with full access to the Oracle Identity Analytics application and who can create and view the progress of all certifications Designated personnel who can view the Identity Certification Dashboard to view the progress of each certification, and who can view reports from completed certifications An administrator with limited access to the Oracle Identity Analytics application and who can only create and view the progress of certifications
Auditor (or Audit Analyst)
Certification Administrator
Applications, Resources, and Attributes Second, you need to select the applications, resources, and attributes that will be considered during the certification process. It is best to focus on those systems that are considered critical and limit the process only to those applications. This will reduce the time required to perform the certification and provide a quick win. Certification Labels (Glossary) Business managers are expected to certify that a user has the correct entitlements on the appropriate systems, but when reviewing reports, they see references that are cryptic and have no apparent meaning. The third thing that you need to do is to define the certification labels that associate cryptic access permissions into business-friendly terms. This information is contained in the Oracle Identity Analytics Glossary and can be defined on a per-resource basis. Email Templates Notifications are sent to certifiers, indicating that they need to take action on a particular certification. The last thing that you need to do is to create the templates for those emails.
Certification Process
Certification involves five distinct phases: 1. Preparation 2. Pilot 3. Validation 4. Certification 5. Remediation
Certification Process
This slide provides an overview of the phases involved in an identity certification deployment.
Phase 1: Preparation
In the preparation phase, you perform the following activities: 1. Create a certification governance team. 2. Build the Identity Warehouse. 3. Select the correct certification. 4. Determine the certification process cycle.
Phase 1: Preparation
During the preparation phase, you perform the following steps: 1. Create a certification governance team. 2. Build the Identity Warehouse. 3. Select the correct certification. 4. Determine the certification process cycle. Create a Certification Governance Team One of the first steps in identity certification deployment is to create a certification management or certification governance team. This team is responsible for managing the certification process and communicating information to key stakeholders and users affected by the changes. The team must do the following: Understand the certification management tool. Manage the life cycle of certifications. Steer the communication strategy.
Phase 1: Preparation (continued)

The certification governance team is responsible for communicating the intrinsic changes that are about to occur in your environment. The team should create and implement an effective communication plan to ensure that everyone understands their role in the certification process. Build the Identity Warehouse The Identity Warehouse is essential to any certification program because it provides a single view of all users and all applications where access is granted. As such, the next step in the identity certification deployment is to build the Identity Warehouse. The lesson titled Building the Identity Warehouse provided an overview of how to build the Identity Warehouse from a technical perspective. It did not, however, provide guidance as to which applications to consider when doing so. It is not practical to create an Identity Warehouse that consists of every application in the enterprise. Instead, you should focus on those applications that provide the most benefit. The recommended way to build the warehouse is as follows: 1. Select critical applications first. Additional resources Selecting the important applications is critical to maximizing your ROI. Analyze your business risks, limit your scope, and finalize the access information of the applications that you want to include in the certification process. Analyze the criticality of each application based on two criteria: - Does the application contain sensitive data from an audit standpoint? - Is the application critical from a provisioning standpoint? Is it an application with a huge user base that requires regular updating? Note: Oracle Identity Analytics gives you the flexibility to create an application view across various resources. This translates into reviewing user access to only high-level applications during the certification process, thereby saving time. 2. Define certifiable attributes. Within accounts, select only key attributes, and include only these attributes in your certifications. This reduces the certifiers time and effort. 3. Import glossary information. To user managers, entitlements are mere cryptic codes that are difficult to understand. To ensure that the right entitlements are certified or revoked, import glossary information into Oracle Identity Analytics. The goal of glossary descriptions is to provide capability detail. For example, an entitlement in PeopleSoft such as P_xyz_500 means an account payable clerk with the authority to approve checks of at least $500. Assign an administrator to review and update entitlements on a regular basis. 4. Review orphaned accounts and users. As you create the Identity Warehouse, addressing orphaned accounts becomes critical. Orphaned accounts can be important process or system accounts, for which owners should be assigned. This ensures that all accounts are certified and have the required access.

5. Assign data owners to high-privileged entitlements. It is critical to identify as high-privileged those entitlements that are highly sensitive in nature. These would include high-risk entitlements, system accounts, accounts with administrator-level privileges, and so on. Because of the sensitive nature of these entitlements, they should be included as part of two certifications: user entitlement and data owner. 6. Validate your processes. Ensure that the Identity Warehouse is current and accurate. Important steps to achieve this include the following: - Integrate with a provisioning solution to update user and account information in the Identity Warehouse. - Schedule a regular import process for user and account information on a nightly basis. Note: Oracle Identity Analytics can be tuned to reflect the organizational changes that are a part of your everyday business. The Identity Warehouse and the import process supported by Oracle Identity Analytics ensure that the warehouse stores the most recent version of user entitlements, in addition to updated user records, which reflect organizational changes on a day-to-day basis. The import process captures any users being hired into the organization, transferring from one department to another, or being terminated, which in turn enables Oracle Identity Analytics to take appropriate actions. These actions might include triggering audit scans, creating access certifications, or rule-based assignments and deassignments of roles to new, transferring, or terminated users. The Identity Warehouse also records the most up-todate user entitlements across an enterprise, allowing for a more streamlined reporting and auditing process. Choose the Correct Certification Oracle Identity Analytics offers four out-of-the-box certifications to review user access. Use the following table to select the best certification type for your organization. Certification Type User Entitlement Resource Entitlement Data Owner Role Entitlement Description Allows business managers to review their employees access and certify or revoke access to applications Allows application owners to review and certify or revoke access to applications they own Allows attribute owners to review and certify or revoke access to the granular data they own Allows role owners to review role content. (See the lesson titled Performing Role Lifecycle Management for more information.)
Determine the Certification Process Cycle Before you start your certification process, you should determine the frequency of the certifications. Use the incremental certification feature, a setting that allows user managers to certify only the changes that have taken place since the last-created certification. Enable this setting to avoid repetition of access evaluation for previously certified users.

An ideal certification process cycle is as follows: First year Schedule the certification job on a quarter-to-quarter basis. This will filter the orphan accounts and streamline user access. The first certification should be a complete certification, followed by three incremental certifications. Second year Schedule certification jobs on a half-yearly basis, again with one annual baseline followed by an incremental certification. Third year and onward Schedule certification jobs on a half-yearly basis. Note: It is important that you consult your internal and external audit teams to verify the frequency of certifications suited for your organization.
Phase 2: Pilot
In the pilot phase, you perform the following activities: 1. Form a user acceptance testing team. 2. Create pilot certifications. 3. Configure remediation settings.
Phase 2: Pilot
Before performing any certifications, you should test the configuration. This is a critical step to ensuring success. A pilot phase gives you the opportunity to detect any outstanding issues and address them before performing the actual certification. In the pilot phase, you will perform the following activities: 1. Form a user acceptance testing (UAT) team and include team members in the process. This team should participate in two different roles: testing the administrative functions and serving as end users or requestors. The team will gain greater understanding of how to manage its own access and support end users who may require assistance. 2. Create pilot certifications. Launch a pilot certification for a predetermined set of users. Include a mix of systemsavvy and non-IT users in the pilot to ensure a complete system run. Monitor the pilot certification process and progress. Refine your certification configuration based on the results of the pilot run. 3. Configure remediation settings (include managed and nonmanaged applications). Oracle Identity Analytics enables you to automatically remediate accounts that have been revoked during the certification process. The actions taken during remediation can be as simple as sending an email to the appropriate owner or as extensive as automatically removing the users entitlements from the system where a violation has occurred. You should configure the remediation settings because this will expedite the post-revocation activity.
Phase 3: Validation
Ensure the following before launching certifications: Certification meets organizational requirements. Issues found during the pilot have been addressed. Email templates are relevant. High-profile users are excluded from the certification. Administrators are blind copied on all notifications. The system can handle increased traffic.
Phase 3: Validation
Before launching any certifications, you should recheck your settings to ensure the following: All the identity certification configurations are in line with your organizations requirements. Issues encountered during the pilot process have been addressed. Email templates have been created and contain relevant content. The escalation workflow has been developed and dates are set for reminders to managers. A list of high-profile users (senior vice presidents and above) has been created. This groups daily administrative activities are performed by their respective executive assistants or designated proxies. You should turn off the escalation emails for this set of users. Administrators have been blind copied (bcc) on all certification notifications. Configuration changes on the server have been made to accommodate increased traffic to the tool.
Phase 4: Certification
Best practices for launching certifications are as follows: Launch the certification in batches. Stay within predefined time lines. Handle certifications for high-profile users.
Phase 4: Certification
After you have validated the certification settings, you are now ready to launch an identity certification. The success or failure of the certification depends on the previous phases. Best practices for launching an identity certification include the following: Launch the certification in batches. To facilitate the success of the certification process, you should launch certifications in increments of 50. This is a manageable number and enables you to address any issues that arise during the certification process without impacting the organization as a whole. Stay within predefined time lines. A certification campaign is an enterprisewide activity and involves various business units and a broad range of participants. This includes business line managers, application owners, and data owners. As such, an identity certification can drag on for weeks (if not months) if not managed properly. The certification process should not take more than four weeks in total, and managers must complete their certifications within two weeks. Managers should be onboard if you have effectively executed the communication plan created in Phase 1. If not, Oracle Identity Analytics provides notifications, escalations, and monitoring by administrative personnel to aid in this process.
Phase 4: Certification (continued)

Handle certifications for high-profile users. Treat this set of users with care. After the escalation reminders have been removed for high-profile users, you should make appropriate configuration settings that are suited to their job titles.
After the certification has been launched, there are two distinct participants that become part of the certification cycle: certifiers and certification administrators. Certifiers are responsible for completing their certifications on time. This includes verifying the following information as part of the process: All users (employees, contractors, and so on) who report to them are included in the certification. All applications pertinent to their business unit are included in the certification. A users presence or entitlement on a particular application does not create a violation. Certifiers review each user and must attest the users access rights. After the certification is completed, the certifier should print the certification report for reference and distribute it to interested parties. If any users or applications were omitted during the certification process, the certifier must have the appropriate administrator add them for the next certification. Certification administrators ensure that certification deadlines are being met within the fourweek cycle. To do this, they must monitor the number of certifications that have been completed and are currently in progress. Additionally, certification administrators must monitor notifications to ensure that they are being addressed in a timely manner. In cases where a notification is not being addressed, the certification administrator can escalate or reassign the certification to a proxy user. Certification administrators monitor obsolete or revoked users on a regular basis and coordinate with management as to how to clean up these types of users.
Phase 5: Remediation
In the remediation phase, you perform the following activities: 1. Review certification reports. 2. Address violations found on:
Managed resources Unmanaged resources
Phase 5: Remediation
Remediation is the last phase in the certification process and involves taking action on any violations that may have been found. To accomplish this, certification administrators need to review reports generated during the certification process. The following table provides a description of some of the types of reports that are available during this phase. Certification Reports Report: Description: Action: Report: Description: Action: Consolidated certified access report Compiles evidence of certifiers responses Should be stored in a noneditable format Consolidated revoked access certification report Includes all revoked accounts, roles, and entitlements across the organization Must be shared with application owners and the user administration team for remediation action
Phase 5 - Remediation (continued)

Report: Description: Action: Obsolete users report Includes and terminates users with incorrect information about managers Is shared with the HR department to update its records
Note: Refer to the Oracle Identity Analytics 11gR1 Users Guide (http://wikis.sun.com/display/OIA11gDocs/User%27s+Guide) for a complete list of reports. The information contained in these reports can be used to communicate the status of the certification and to determine the steps for addressing any violations found. The next steps performed depend on whether the violation was found on a managed or nonmanaged resource. For managed resources, if Oracle Identity Analytics is integrated with Oracle Waveset, the software directly revokes the account in the provisioning solution and updates information in the Identity Warehouse. For nonmanaged resources, the certification administrator must work with the application owners to ensure that the revoked accounts are deprovisioned. Certification administrators can achieve continuous monitoring by generating remediation reports on a regular basis.
Certification Dashboard
Summarizes status information for certifications in progress:
Certifications by Status Summary User Accounts Certification Status Notifications Issued in Last Week Statistics User Roles Certification Status
Customizes information based on a users access:

Global administrators see data for entire organization. Managers see data only for their business units.
Certification Dashboard
The identity certification dashboard summarizes status information for certifications in progress. The information presented is customized based on your user access. For example, if you are logged in as an administrator with global access, the dashboard presents certification data for the entire organization. If you are logged in as a manager, however, the dashboard presents information that is relevant only to your particular business units. The identity certification dashboard presents the information found in the following table. Dashboard Panel Certifications by Status Description This bar graph compares certification statuses (new, in progress, complete, and expired) for each of the four certification types (user, role, resource, and data owner). Summary provides the total number of users, accounts, resource types, and resources that are defined in Oracle Identity Analytics for your organization. This pie chart shows how many user accounts are marked as certified, revoked, and incomplete.
Summary
User Accounts Certification Status
Certification Dashboard (continued)

Dashboard Panel Notifications Issued in Last Week Description This bar graph shows how many reminders have been sent in the last week to managers, senior managers, and the IT security department. Statistics provide the average number of certifications per business structure, the average number of roles per user, the average number of accounts per user, and the average number of users in the average business structure. This pie chart shows how many user roles are marked as certified, revoked, or incomplete.
Statistics
User Roles Certification Status
To open the identity certification dashboard, select Identity Certification > Dashboard from the main menu.
Closed-Loop Remediation
The certification process is tightly coupled with the provisioning process. Roles and entitlements are revoked in the provisioning solution as a result of them being revoked in the certification process. This feature is available to implementations that utilized Oracle Identity Manager as the provisioning solution.
Closed-Loop Remediation
Closed-loop remediation is a feature that enables you to directly revoke roles and entitlements from the provisioning solution as a result of roles and entitlements that were revoked during the certification process. This feature is applicable only if the provisioning solution is Oracle Waveset and only pertains to those applications being managed by the Oracle Waveset software. For nonmanaged applications, you can manually revoke roles and entitlements by using the information stored in the remediation configuration module. It is the responsibility of the certification administrator to work with individual application or data owners to ensure that this task has been completed.
Best Practices
Do not rush through precertification or prelaunch. Limit the number of applications. Use a four-week certification cycle as a foundation. Communicate, communicate, communicate. Provide training to certifiers. Take immediate action on revocation reports.
Best Practices
When deploying an identity certification solution, follow these best practices to provide the best foundation for success. Do not rush through the precertification or prelaunch phases. Plan to communicate, pilot, remediate changes from the pilot, communicate again, and then launch your first batch of certifications. Overlooking this process creates the risk that governance, training, and communication have not occurred to the proper degree to ensure sustainable success. Limit the number of applications considered during the certification process. Selecting too many applications that may not be critical to your business increases risk. The secret to saving time and minimizing business risk lies in the choice of applications. Organizations often make the mistake of either selecting too many applications, which do not pose a potential security threat, or not including all data-sensitive applications in the review process. Therefore, a team comprising a business analyst and a technical expert must be consulted before short-listing target applications. Also, include your internal audit team in this discussion because it is best able to differentiate between applications that are compliance-critical and those that can be included in the certification process.
Best Practices (continued)

Start with a four-week certification cycle. Do not establish certification cycles that are either too short or too long. Four weeks is the optimum time to launch and complete a certification cycle. Too short a cycle will rush user managers and administrators, and too long a cycle will elongate the process, delaying your compliance deadline. Communicate to all parties at every step in every phase of the process. The certification process involves many participants throughout the enterprise and consists of both technical and nontechnical persons. The concerted effort of all the actors is key to the success of an identity certification cycle. It is vital to create a seamless communication channel where all personnel involved are aware of their new roles and are prepared to fulfill the associated responsibilities. Provide adequate training to certifiers. Certifiers can perceive the process as a daunting task if they are not adequately trained. Conduct demonstrations and training sessions for certifiers to make them comfortable with the tool and the process. Take immediate action on revocation reports. The certification cycle is only as good as the action the organization takes on the reports generated. Addressing all HR issues and remediation actions will result in a compliant organization.
Metrics
Reduction in the number of dormant or terminated accounts Reduction in the number of sensitive or high-privilege accounts and entitlements Number of accounts and entitlements remediated Remediation count of incorrect user-to-manager reporting relationships
Metrics
This slide provides an overview of some of the key metrics that will interest your management team, as well as internal and external auditors. Following these best practices will make the certification process more successful. You can leverage this success by communicating these metrics throughout the organization.
Return on Investment
Reduction in time Minimization of errors Reduction in manpower costs Enhanced user experience
Return on Investment
Additionally, you can calculate return on investment (ROI) on the criteria shown in this slide. Whereas many of these items have a direct impact on the bottom line, others are more objective. Reduction in time: There is significant reduction in turnaround time versus manual certification and in comparing a complete certification versus incremental certifications. Minimization of errors: With monitoring ease, an automated certification module eliminates manual errors. Reduction in manpower costs: Fewer people are involved in the process. Enhanced user experience: Certifiers now do not loathe the process.
Summary
In this lesson, you should have learned to: Describe security challenges faced by organizations Describe the benefits of an automated certification process Establish a certification environment Configure the Oracle Identity Analytics Glossary Describe the identity certification process Perform an identity certification
Practice 4 Overview: Configuring Identity Certification

This practice covers the following topics: Configuring Identity Certification Creating Data Owner and User Entitlement Certifications Completing Certifications Performing Remediation Validation
Configuring Auditing
Objectives
After completing this lesson, you should be able to: Describe identity auditing Configure audit rules and audit policies Perform audit scans and detect policy violations Schedule audit scan jobs Configure event listeners
Objectives
Discussion: The following questions are relevant to understanding the topics covered in this lesson: What is an identity audit and how does it compare to identity certification? How does Oracle Identity Analytics detect separation of duties violations? Who are the key actors in an identity audit process and what are their responsibilities? How can the identity audit process be automated?
Identity Auditing
Identity auditing is the process of scanning for access violations. Violations are flagged against audit policies. Audit policies consist of audit rules.
Audit Rule Violation Audit Rule Audit Policy
Violations are tracked until they are closed.

Identity Auditing
Identity auditing is the process of scanning resources for access violations. In Oracle Identity Analytics, audit rules define violations. The intent of an audit rule is to determine if any user has been granted access that he or she should not have based on business or security policies, and includes detection of segregation of duties violations. Note: A segregation of duties (SoD) violation is a violation in which a user account, a user attribute, or a role has been assigned two entitlements that should not be held in combination. Audit rules are combined to create an audit policy. User accounts and business units are then scanned for audit policy violations. User accounts, user attributes, and roles that violate an audit policy are flagged and tracked until the violation is resolved.
Product Capabilities
Monitors users actual access to resources Detects segregation of duties (SoD) violations Creates and tracks audit rules, audit policies, and audit policy violations throughout the audit life cycle Captures violations on a continuous basis and maintains a history of audit scans
Product Capabilities
Oracle Identity Analytics has a detection mechanism that monitors users actual access to resources and captures any violations on a continuous basis. Note: This is different than the identity certification capabilities described in the lesson titled Configuring Identity Certification. Identity certification enables managers to certify or revoke access of users on a periodic basis (when certifications are performed) and might lead to the creation, deletion, or modification of audit policies. Identity auditing monitors for violations against policies on a continual basis and provides notifications in real time. The software can be programmed to conform to audit policies and report exceptions when they are found. An identity audit provides a summary of all exceptions, which can help security analysts, executives, or auditors to determine if they want to accept the exception or mitigate it. Note: Violations can be applicable during the identity certification process. If a user has any open violations, the certifier sees a link on the certification page where he or she can obtain additional details about the violation. The certifier can then elect to certify the user or not. Oracle Identity Analytics provides mechanisms for creating and tracking audit rules, audit policies, and audit policy violations throughout the life cycle of an audit. The software also maintains a history of all audit scans and the actions taken by various participants in the process.
Audit Rules
Identity Audit Rule Definitions
Rule condition Metadata such as name, description, create and update dates
Three states
Active Inactive Decommissioned
Audit Rules
An identity audit rule consists of a rule condition and some metadata associated with the rule (name, description, create/update dates). Following is an example of an identity audit rule: Rule Condition : ( Resource Type::Windows Active Directory.adGroups contains 'CN=BankSoft_User,OU=Applications,OU=Corporate,DC=identric, DC=com' AND Business Structure.Business Structure Name equals 'Services' ) This rule defines a violation for users in the Services business unit who also have the BankSoft_User application group in Active Directory. An audit rule currently can exist in three states: Active, Inactive, and Decommissioned. Note: You cannot delete audit rules from Oracle Identity Analytics. This would introduce gaps in the audit history and impact an auditors ability to review information from previous violations. This could impact a companys ability to meet regulatory compliance.
Audit Policy
A collection of rules that together enforce a business policy in the enterprise environment Audit Policy Definition
Name, description Severity Create date, update data, owner Default remediator* information (* The person responsible for addressing policy violations)
Audit Policy
An audit policy consists of one or more audit rules that together enforce a business policy in the enterprise environment. The policy consists of other metadata such as name, description, severity, create and update dates, owner, and the default remediator information. The remediator is the person responsible for addressing any violations found against the audit policy. The severity of the policy (high, medium, or low) associates a level of criticality to any violations against this policy.
Actors
Audit policies have designated remediators who are responsible for taking action when violations are discovered. The following actors can be remediators: Oracle Identity Analytics administrator Policy owner Remediator (defined in the audit policy)
Actors
Audit policies have designated remediators who are responsible for taking action when violations are discovered. The following actors can be remediators: Oracle Identity Analytics administrator (by default, rbacxadmin) Policy owner Remediator (designated person assigned during policy creation)
Remediators of audit policies receive automated emails from Oracle Identity Analytics informing them of audit violations. Remediators can then log in and perform remediation actions.
Policy Violations
Users and business units are scanned against existing audit policies. Audit scans detect SoD violations associated with:
User HR attributes Role assignments Business structure memberships
The remediator is responsible for addressing the violation. Policy violations can be assigned only to other OIA Users. Oracle Identity Analytics tracks the violation until it is resolved.
Policy Violations
An audit policy violation enables an enterprise to track SoD violations and pursue their resolution. Policy violations occur when one or more rules associated with a policy are broken by a user account, a user attribute, or a user role. Oracle Identity Analytics maintains comprehensive details for each violation: Cause of the violation Policy being violated Severity Create date Update date Number of reminders sent Date of the last reminder Number of times this violation was detected
Policy Violations (continued)

Each broken rule, and the user, account, role, and membership details that caused the violation are recorded. Each violation contains at least one cause. When more than one rule in the policy matches, the violation will have multiple causes. Violation causes are displayed on the Violation Details page under three different categories: Account Causes Role Causes HR Attribute Causes Violations are assigned to the remediator of the audit policy. The remediator is then responsible for taking action to bring the violation to resolution. A remediator can reassign violations to other SRM Users so that action can be taken to resolve the violation. Updates to violations that occur due to user or system actions result in the creation of an audit trail. The remediator is mentioned in the audit trail of every violation, thereby making him or her accountable for the action. Oracle Identity Analytics tracks the violation until it is resolved.
Audit Scans
Are performed on a set of users Search for violations to existing identity audit policies Consist of two types:
Scan Creates or updates violations; sends email Scan Preview Performs a scan but takes no action
Audit Scans
An audit scan is the process of checking if a particular set of users is violating one or more audit policies. Scans are run as jobs in the background, and the status or results are displayed in the graphical user interface. There are two types of scans: Scan: When a typical audit scan is run, it creates new violations or updates existing violations and sends email notifications to the remediator of the identity audit policy. Scan Preview: The typical scan is performed, but no action is taken to resolve the violations or email notifications. It provides a preview of what the result of an actual scan looks like.
Dashboard: Overview
Audit policy violation information is summarized. It provides a graphical depiction of:
Policy Violations Policy Violations By State Violation By Priority Policy Violations By Updated Date
Information is customized based on a users access.

Global Administrators see data for the entire organization. Managers see data only for their business units.
Dashboard: Overview
The audit dashboard summarizes audit policy violation status information. It displays graphs that enumerate the number of violations, and lists violations by state, priority, and date-of-lastupdate. The following graphs are displayed: Identity Audit Policy Violations Identity Audit Policy Violations By State Identity Audit Violation By Priority Identity Audit Policy Violations By Updated Date To open the audit dashboard, select Identity Audit > Dashboard from the main menu.
Dashboard
Dashboard
This slide demonstrates the graphical dashboard for Identity Audit. You can select the type of graph that you would like to see at the lower-right corner of each graph. This enables you to see alternate views of the data. You can change the time period that the dashboard displays by selecting from the Period dropdown list at the bottom-right of the screen. The dashboard contains information pertaining to violations against audit policies as follows: Open violations: Displays all violations that are not yet fixed by the remediator. You can view the open violations by clicking them. Closed violations: Displays all violations that have been addressed by a remediator and closed
Policy Violation States

Violation States: Open Closed (Fixed) Closed (Risk Accepted)
Policy Owner or System
Created
Policy Owner
Assigned
Policy Owner or Assignee
Policy Owner, Assignee, or System
Closed Fixed
Policy Owner, Assignee, or System
Closed Risk Accepted
Closed
Violation Life Cycle

Policy Violation States

Audit policy violations can be sorted by three different states: Open: The remediator has not yet taken any action on the violation. Closed and Fixed: The remediator has fixed the violation and therefore, it should not appear in the next policy scan. Oracle Identity Analytics will reopen the violation if it reappears during the next audit scan. Closed as Risk Accepted: The remediator has acknowledged the violation and opted to allow the access for a certain time period. Oracle Identity Analytics will reopen the violation after the specified time has expired if the condition still exists. Violations that are Closed as Fixed and Closed as Risk Accepted are verified by the system and reopened if the underlying cause is not resolved or if the date until which the risk is accepted has expired.
Audit Policy Actions

Create Violations
When the user object matches the condition associated with one or more rules in the audit policy
Update Violations
Authorized users or system Reassign Remediate (that is, if taken to close state)
Closed
By authorized user or system scan All causes associated with violation resolved
Audit Policy Actions

Violations can have one of three actions associated with them: Create: Violations are created when the user object matches the condition associated with one or more audit rules in an audit policy. Update: Violations are updated by authorized users or the system. Authorized users can reassign or remediate a violation. A violation is said to be remediated by an authorized user if the violation is taken to one of the closed states. Closed: The system or user can move violations to the Closed state if in a scan, it finds that all the causes associated with a particular violation are resolved. If you elect to close the violation (Close as Fixed or Close as Risk Accepted), you will be required to provide comments for future reference. This becomes a part of the audit trail for that violation. If you elect to close the violation as risk accepted (Close as Risk Accepted), you will still need to provide a comment, but you will also need to provide a date when the risk is no longer acceptable (end date). If an audit scan detects the violation after the end date has passed (even if the violation has been accepted), the violation is reopened and the remediator will need to re-address it.
Job Scheduling
Jobs can (and should) be scheduled to run on a periodic basis. Reminder & Escalation Job:
Reviews each unresolved violation Sends out an escalation or reminder email as appropriate
Continuous SoD Scan Job:

Performs a scan on all active users in the Identity Warehouse and looks for violations of audit policies Automatically closes or reopens violations based on data available in the Identity Warehouse
Job Scheduling
Identity audit jobs can be scheduled to run on a periodic basis. Oracle Identity Analytics contains two default jobs that pertain to identity auditing: Reminder & Escalation Job This job reviews each unresolved violation and sends out an escalation or reminder email as appropriate. Administrators of Oracle Identity Analytics should monitor for violations that have been open for too long and escalate as appropriate. The Reminder & Escalation Job is identified by the identityAuditViolationReminderJob bean in the jobs.xml configuration file. You should consider scheduling this job on a frequent basis (such as every 30 minutes) in order to resolve open violations. Continuous SoD Scan Job This job performs scans on all active users in the Identity Warehouse and searches for violations of any audit policies. Any previously closed violations are reopened if the violation is still in effect. The Continuous SoD Scan Job is identified by the identityAuditContinuousViolationScanTrigger bean in the jobs.xml configuration file. You should consider scheduling this job to run on a daily basis in order to detect violations in a near real-time manner.
Event Listeners
Monitor for system events (such as user changes) Take action when an event is detected Consist of:
Event definition Action to take
Event Listeners
The Event Listener mechanism enables an administrator to create listeners to business events that are occurring in the system and take action when those events are detected. An example of a business event is a user update, which occurs when one or more of the users attributes are updated. A listener, when created, defines the events to examine based on a condition, and also defines the actions that are to be executed by the system in response to those events.
Summary
In this lesson, you should have learned to: Describe identity auditing Configure audit rules and audit policies Perform audit scans and detect policy violations Schedule audit scan jobs Configure event listeners
Practice 5 Overview: Configuring Auditing

This practice covers the following topics: Configuring an Identity Audit Creating an Audit Rule and a Policy Performing an Audit Scan Running the Identity Audit Exercise
Performing Role Mining
Objectives
After completing this lesson, you should be able to: Describe the best practices for role definition Perform role mining for a business unit Review and analyze the role mining results Perform role entitlement discovery
Objectives
Discussion: The following questions are relevant to understanding the topics covered in this lesson: What are the approaches to defining roles within an organization? Can the role creation process be automated and if so, how? What is the best approach for performing role mining and how can I implement a role mining methodology in my organization? How can existing roles be updated after they have been created?
Role Management
Role management is a process that involves:
Defining roles that are appropriate for an organization Assigning those roles to individuals according to their needs Managing users access according to the roles
Role management is an efficient and effective way to manage the large and constantly changing universe of users. Creation and management of roles is the most challenging aspect of role management.
Role Management
Role management is the process of defining and assigning roles to individuals who require access to organizational resources, and then managing their access according to those roles. Creating roles based on usage and enterprise policies enables greater visibility into access and makes access more manageable. This enables you to provide access control based on a limited number of roles rather than on an infinite number of individuals. Role management is therefore an efficient and effective way to address the challenges of access control for a large and constantly changing universe of users. Even though using roles as the basis for access control can make the process more efficient, there remains the challenge of defining roles for this purpose. In organizations that have a considerable numbers of users with access spread across multiple applications, role definition can be a monumental task.
Role Mining (Role Discovery)

Role mining evaluates user entitlements within a set of business units. Roles are created based on groupings of entitlements. Role mining can be performed by using:
Top-Down Approach Bottom-Up Approach Hybrid Approach
Role Mining (Role Discovery)

Traditional methods for defining and managing roles have, for the most part, been manual in nature. Hundreds, if not thousands, of spreadsheets are used to define roles. These same spreadsheets are then used for comparison with users actual access in an attempt to find violations against the role definitions. This method of role management is ineffective, time consuming, and extremely expensive to implement. Fortunately, the process can be automated for the most part. 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 it takes to define roles within an organization. Role engineers can specify the applications and attributes that will return the best mining results and perform the analysis on one or more systems within a business unit. During role mining, a set of candidate roles is discovered for one or more business units. When considering how to discover roles, there are three general approaches from which to choose: top-down, bottom-up, and hybrid.
Approaches to Role Mining

Top-Down Approach
Oracle Identity Analytics creates roles by analyzing users job functions and HR attributes. (For example, geographical location and manager are typical HR attributes.)
Bottom-Up Approach
Oracle Identity Analytics creates roles by analyzing users account permissions.
Hybrid Approach
The Top-Down and Bottom-Up approaches are combined.
Approaches to Role Mining

There are three approaches you can take when performing role mining: a top-down approach, a bottom-up approach, and a hybrid approach. Top-Down Roles are created based on users job functions and HR attributes. (For example, geographical location and manager are typical HR attributes.) This option approaches the process from the perspective of what a user needs access to, based on the users HR attributes, context in an organization, and what is determined appropriate by the users superiors in the organization. This methodology was used traditionally when no tools were available to analyze the users actual access. Bottom-Up Users existing access permissions are analyzed and roles are created based on the account permissions they currently have. This approach is centered around the process of evaluating the access assigned to users in each application and clustering users based on their similarities. While generally more successful than the top-down approach, this method is very cumbersome when performed manually.
Approaches to Role Mining (continued)

Hybrid The hybrid approach to role definition has been the most successful approach. It takes into account user context information (manager, location, job title, job functions, and so on) in conjunction with the actual access held by the users in order to provide a holistic view of which users have similar access and why (similar job function, location, manager, and so on).
No matter which method is used for role discovery, there is consensus that the traditional method of using spreadsheets for defining roles is ineffective, time consuming, and very expensive. Oracle Identity Analytics provides automation for all three approaches and offers an end-to-end solution to discover and define roles based on existing user entitlements. Roles can be generated using the softwares role mining module, which uses sophisticated algorithms to create new roles based on user entitlements. Role mining reduces the role definition time by about 50 percent. Multiple rules and a combination of attributes (such as job codes, department, and location) can be used to assign role-based access to new and existing users.
The Wave Methodology

The Wave Methodology for Role Definition
Analyze & Prioritize Prioritize divisions. Prioritize applications. Build Entitlement Warehouse Import data. Collect and correlate entitlements to identities. Form business units. Finalize Candidate Roles Incorporate suggested changes. Submit roles to role owners for approval. Perform Role Discovery Define role membership. Define role entitlements. Analyze/Review Role Exceptions Handle exceptions via auxiliary roles or ad hoc access requests.
Review Candidate Roles Review and approve roles. Review and approve entitlements.
Finalize Role Exceptions and Certify Roles. Incorporate any remaining changes. Finalize role definitions.
The Wave Methodology

Oracle has developed an implementation methodology for role mining that breaks users into manageable chunks (or waves) for the purpose of defining roles. The wave methodology is based on years of experience in helping customers adopt a role-based model for access control and has been developed in concert with both customers and partners. The Wave Methodology for Role Definition (Wave Methodology) consists of the following seven steps: 1. Analyze and Prioritize 2. Build Entitlement Warehouse 3. Perform Role Discovery 4. Review Candidate Roles 5. Finalize Candidate Roles 6. Analyze/Review Role Exceptions 7. Finalize Role Exceptions and Certify Roles Even though some of the steps outlined in this methodology can be accomplished without the aid of technology, it is virtually impossible to accomplish all the steps without the aid of such a tool as Oracle Identity Analytics. Note: The Wave Methodology white paper can be found at http://www.sun.com/offers/details/wave_methodology.xml. These steps are described over the next few slides.
The Wave Methodology (Step 1 of 7)

Step 1: Analyze and Prioritize Meet with stakeholders.
Discuss the purpose of the project. Review the project methodology. Select the approach for prioritizing the project.
Prioritize the project based on divisions. Prioritize the project based on applications.

One of the critical factors for success in defining roles is to make the work more manageable by dividing it into waves that can be prioritized based on the needs of the business. After this step is completed, you will have a high-level understanding of the entire scope of the initiative and a good idea of where to begin focusing your efforts. This step requires a series of meetings with the role definition project team and stakeholders representing IT as well as the various business divisions. The stakeholders are usually managers, department heads, and other members who can add value to the role definition process with their knowledge of the environment. Meetings are held to discuss the purpose of the project, an overview of the methodology, and the best approach to prioritizing the environment. The overall prioritization exercise is primarily driven by the prioritization of both the divisions and the applications that are utilized by those divisions. The following summarizes the criteria for prioritizing divisions and applications.
The Wave Methodology (Step 1 of 7) (continued)

Prioritization of Divisions The prioritization of divisions for the purpose of role definition is based on two criteria: 1. Current cost of user administration As the need to reduce the cost of administering users goes higher, the corresponding prioritization of the division goes higher as well. This higher need is demonstrated by the following criteria: - Number of users: More users within a division will generate more user administration activities. - Number of Human Resources (HR) events: A greater number of new hires, rehires, transfers, and terminations will generate more user administration activities. - Access criticality: Some divisions are absolutely necessary for the operations of the company. Access must be granted to individuals from these divisions first to support the core operations of the business. 2. Ease of implementation Role definition is typically easier for divisions that have a very clear demarcation of user job functions. The easiest divisions are dealt with first in order to provide organizations with a quick return on their investment. The following criteria are used to determine the ease of implementation: - Number of different job functions: The ratio of the number of users by job functions provides a good metric to determine the easiest role-definition candidates. If the ratio is higher, the division is easier. - Stakeholder availability and influence: The stakeholders identified for role definition must allocate time to the process of role verification. It is imperative to determine the best months for the stakeholders to work with the role engineers to define roles. The stakeholders must also have sufficient influence to summon the resources necessary to complete the task. This includes the appropriate people for reviewing and approving the candidate roles, as well as the data (user and entitlements) necessary to perform role mining. - Number of applications in use: It is important to determine the number of applications used by a division. If the applications are fewer, it is easier to define roles for the division.

Prioritization of Applications Prioritization of applications is driven by the prioritization of divisions and the following three criteria: 1. Current cost of user administration The higher the need to reduce the cost of administering users, the higher the prioritization of the application. This higher need is demonstrated by the following criteria: - Number of new accounts created/modified/deleted per month: A higher ROI is generated by automating the user administration activities for applications that have a higher user administration cost. - Number of users that use the application: The higher the number of users of the application, the greater the ROI will be when access is automated. - Average time frame for provisioning: If the provisioning activity on an application is very time intensive, the role-based model will reduce the time frame and thus provide a greater ROI. - Frequency of use: If an application is used more frequently than others, it should be given a higher priority for role definition. 2. Application security profile If the security and risk profile are higher (and therefore, the need for stringent user access controls on an application is greater), the prioritization of the application is higher. This higher profile can be demonstrated by the following criteria: - Sensitivity of application (potential risk of nontimely removal of idle/expired accounts): If the application is classified as being sensitive, it requires more stringent security controls and must be higher in priority. - Criticality to Sarbanes-Oxley (SOX) compliance: If an application is SOX critical or is classified as a PCI application, it should be given a higher priority. - Length of existing certification process: If the application owner and business manager take a long time in performing user access reviews, a role-based system can reduce the time and provide a higher ROI. 3. Ease of implementation Role definition is typically easier for applications that have a process to extract user access data, have a designated subject matter expert, and have a designated owner. It is also easier to define roles for applications that have built-in roles and a lower number of access levels. Based on the information gathered during these sessions, you can develop a plan for defining roles that will maximize the positive impact to the business and shorten the time necessary to achieve a return on the investment.

Step 2: Build Entitlement Warehouse 1. Create user identities based on an authoritative source. 2. Collect application entitlements. 3. Correlate entitlements to identities. 4. Create an organizational structure. 5. Associate users with the organizational structure. 6. Perform access certification (optional).

After the environment has been prioritized and the initial divisions and applications have been identified, the next step is build an entitlement warehouse to serve as a repository for the HR profile data (name, job function, department codes, location, and so on) for each user within the relevant divisions and applications. This data should be obtained from an authoritative source, which can be an enterprise directory or an HR application. After the profile data is collected, the next step is to collect and correlate the entitlements to the identities for each application. Initially, this may be only a handful of applications, or it can be one large application such as an Enterprise Resource Planning (ERP) system. After the data is imported and correlated, the users are split into their respective business units. A business unit is a logical grouping of users and can be a department, a department split further into smaller groups, or a group of departments depending on the number of users. Organizational hierarchy can also be used to determine business units from a role-definition perspective. The goal is to form a manageable size of groups and users contained within each group. After the entitlement warehouse has been populated, an optional next step before performing role discovery would be to initiate the access certification process. The process of reviewing each user and the associated accounts not only fulfills a critical access control, but also cleanses the user and entitlement data before defining roles. Note: The access certification process was introduced in the lesson titled Configuring Identity Certification. For more information about access certification, review the paper titled Access Certification: Addressing and Building on a Critical Security Control at https://www.sun.com/offers/details/access_cert_security.xml.

Step 3: Perform Role Discovery Use Oracle Identity Analytics to discover roles. Consider using two phases:
1. Define role membership.

Target subset of user population. Consider only mission-critical applications. Include remaining applications. Finalize the set of entitlements.
2. Define role entitlements.


During this step, a set of candidate roles is discovered for those business units identified from the prioritized list created earlier. This step involves using the top-down, bottom-up, or hybrid approach to role discovery that was previously discussed. The Wave Methodology utilizes a hybrid approach and assumes that you are using a role management tool such as Oracle Identity Analytics. The top-down portion of this approach is encompassed in the prioritization exercise in Step 1 (Analyze and Prioritize), as well as in the HR data incorporated in the entitlement warehouse created in Step 2 (Build Entitlement Warehouse). This information helps to determine which users should be included in a particular iteration of the definition process. The bottom-up portion of this approach is captured in the role-mining process. In role mining, clustering and categorization algorithms are applied to a set of users and their entitlement associations in order to define a set of candidate roles. Oracle Identity Analytics provides the analytics to aid in deciding what access should be made part of each role based on the percentage of users that hold the particular access.

The role-mining process typically occurs in two phases that are distinguished by the applications incorporated within each step. Phase One: Define Role Membership During the initial phase, a subset of the user population is targeted, and only those applications that are deemed to be the most critical to that particular grouping of users are included. This places the initial focus on identifying which users should be included as members within the candidate roles. By limiting the number of applications (and therefore, the population of entitlements incorporated in the mining process), noise is reduced in the mining results, and the quality of the candidate roles is increased. The candidate user population is typically segmented based on one or more of the HR attributes (job code, job title, and so on) captured in Step 2 (Build Entitlement Warehouse). The applications can be removed from the roles with the aid of tool analytics that show the percentage of users who have access to a particular application. For example, a policy can be set that dictates that applications should be included only if at least 80 percent of the users have access to the application. Phase Two: Define Role Entitlements In the next phase, the remainder of the applications identified in Step 2 (Build Entitlement Warehouse) is added to the mix. The goal of this phase is to finalize the set of entitlements that should be included within a candidate role. As in the first phase, analytics in the role management tool will help in deciding which entitlements from each application should be included in the candidate role based on the percentage of users who are currently assigned the entitlement. The combined analytics enable you to decide down to the individual entitlement level whether the entitlement should be included in the definition of the role. Again, policies can be set that would dictate whether to include an entitlement based on the percentage of users who already hold that particular access.

Step 4: Review Candidate Roles 1. Review role membership. 2. Define role metadata (name, description, and owners). 3. Review role entitlements. 4. Define role assignment rules (optional). 5. Define separation of duties policies (optional). 6. Document action items.

During this step, the stakeholders identified in Step 1 (Analyze and Prioritize) are presented the set of candidate roles for review and their feedback is solicited. These review meetings are sometimes referred to as workshops and are an important component of the wave methodology for role definition. In fact, the key to a successful role definition strategy is to ensure that all the stakeholders are involved in the review process. Because roles can contain access or entitlements from a number of applications across disparate business units, it can be extremely difficult to obtain feedback from each stakeholder individually. Perform the following steps when reviewing candidate roles: 1. Review role membership. Following the two-phase approach to defining the roles outlined in Step 3 (Perform Role Discovery), the first goal of a workshop is to review and obtain approval on the users included in each role (also known as role membership). Remember that these sessions are working sessions. Changes can and should be made during the meeting after reviewing reports such as the Role to User report (an Oracle Identity Analytics report that associates roles with users) and other information contained in Oracle Identity Analytics.

2. Define role metadata. After the role members are finalized, the next step is to define the important metadata for each role: name, description, and owners. Of particular importance here are role owners, who are responsible for the final approval of the roles, as well as for ongoing approvals and certifications during the maintenance phase of the overall role management. 3. Review role entitlements. The final goal of the workshop is to review and obtain approval on the entitlements included within the definition of each candidate role. During this exercise, stakeholders can use Oracle Identity Analytics Role Entitlement report to understand the entitlements currently included within the candidate role. This information enables stakeholders to make suggestions for fine-tuning the access based on their knowledge of what is required for the users in that role. 4. Define role assignment rules. It is recommended, though not required, that you define role assignment rules during this step in the methodology. Role assignment rules encapsulate the business logic necessary to determine whether a role should be automatically assigned to a user. These rules most often include logic that detects the presence of a particular value for one or more HR-related attributes to determine whether a role should be assigned. For example, a role assignment rule can be defined that would assign the role Financial Analyst 1 if the user were assigned the value of FA Level 1 for their jobCode attribute. Any combination of attribute values can constitute a rule, and any combination of rules can be applied to a particular set of users. These rules are most often evaluated during the automated provisioning process. 5. Define separation of duties policies. During this step, it is also recommended, though not required, that you discuss potential separation of duties (SoD) conflicts between various candidate roles and entitlements. SoD conflicts can occur at the role level or at the individual entitlement level. After potential conflicts are identified, audit policies can be created that encapsulate rules for determining when a conflict exists. In their simplest form, these rules will perform a check to detect whether two roles that constitute a conflict are both assigned to the same user. The role management tool should provide the means to both define the policies as well as apply them to the enterprise environment on an ongoing basis. Although this process can be performed outside of the role definition process, it is a recommended step here because the stakeholders necessary to identify and define these policies should be participants in the role definition process. 6. Document action items. At the conclusion of this step, suggested changes not executed during the workshop are collected and documented as action items for the next step in the methodology.

Step 5: Finalize Candidate Roles Incorporate any remaining changes Associate metadata with candidate roles Submit roles for approval

During this step, any of the remaining changes to the role definitions suggested during the workshop described in Step 4 (Review Candidate Roles) are incorporated within the model. After these changes are implemented and the role metadata captured is associated with the candidate roles, the roles are submitted for approval to their assigned role owners. Oracle Identity Analytics automates the entire process and audits the approval decisions for future reference.

Step 6: Analyze/Review Role Exceptions Address access that falls outside of the defined roles. Provide for exception cases with one of the following:
Auxiliary roles Ad hoc access request

After approval has been received for each role, the next step in the methodology is to review any access assigned to users that falls outside of the definition of their assigned roles. Based on a review by the appropriate stakeholders, a decision is made to either remove the access from the user or to allow him or her to retain the access as an exception to the role model. Oracle Identity Analytics provides reporting mechanisms that allow you to view assigned access that falls outside of the assigned roles. It is important to keep in mind that even though a role-based approach to access control is an effective method for controlling and managing the access that users have within an organization, it is impossible to define a role model that completely, 100 percent, covers the assignment needs of the entire organization. The enterprise environment is too dynamic to be constrained by a static definition of access. For this reason, during this step in the workshop, exception cases are discussed for users whose access might not fit neatly into one of the candidate roles. The Wave Methodology provides two options for handling these exception cases.

1. Auxiliary roles: The exceptions can be handled within the role model by using auxiliary roles. These are roles defined within the model that are associated with a base role, or parent role, and that contain those one-off entitlements needed by users who do not fit neatly within the defined model. For example, a user with some special job functions can be assigned an auxiliary role in addition to his or her base role. The base role would provide the user with access that is normally granted to someone in his or her job function (encapsulated by the base role). The auxiliary role would provide the user with special or auxiliary access that he or she requires based on the unique circumstances. Given the ongoing cost of managing roles within an organization, one of the overall goals of the role-definition process is to minimize the number of roles defined for an organization. With this goal in mind, the auxiliary role approach might not be the best method for handling exceptions to the role model. In fact, if you are not careful, this approach could lead to role explosion. Note: As a best practice, auxiliary roles are defined if the extra access is needed by more than two to three users who are a part of the base role. 2. Ad hoc access request: The other option for handling exceptional access is to include the exceptional access in the ad hoc access request process. In this option, the exceptional access is made available for request in the tool that is used to automate the access request process. In most cases, this is, or should be, the user provisioning application. But it could also be included in a solution that has been built in-house or incorporated within the service desk application. Regardless of where the functionality is located, the exceptional access would be made available in the user interface of the request tool for assignment to the users in question. This access could be scoped by way of the applications that are relevant to a population of users, or it could be made available for assignment to all users. For example, entitlements that grant specific access within the financial reporting application can be restricted to those users who are members of the finance business unit. Analyzing and reviewing role exceptions is one of the most important steps in the Wave Methodology because it enables the business to remove unwanted access that has been accumulated over time by users. It is also important from a compliance perspective and is central to enforcing the concept of least privilege.

Step 7: Finalize Role Exceptions and Certify Roles Complete final action items. Finalize role definitions. Role exceptions are either removed or approved. Perform the initial role certification:
Review roles for accuracy. Approve or deny access. Create an initial baseline.

In this final step in the methodology, any remaining changes that were captured within the previous steps are made and the role definitions (membership and entitlements) are finalized. Also, role exceptions are either removed or approved based on the decisions captured in the previous step. The final action in this step is to launch the role certification process. The goal of the certification process is to periodically review and approve the entire role model. Each role is reviewed by the role owner for accuracy and approved or disapproved based on a point-in-time snapshot of the role. The decisions are captured and audited within Oracle Identity Analytics to provide confidence to the organization and to external auditing entities that the role model is working as expected. In the case of the first certification, it will also provide the final approval necessary for the changes incorporated in the model, as well as provide a baseline for comparison during subsequent role certifications. By providing a baseline for comparison, it is possible to highlight only those roles that have changed since the last review, which can streamline the entire process.

Next Steps After a role model has been defined, a logical next move is to leverage that model in the user provisioning process. At the very least, this involves exporting the role definitions for use in the access request process. If role assignment rules have also been defined, these rules would need to be accessible to the process responsible for automatically assigning access based on changes in the HR system. By accomplishing this step, the roles move beyond an aid to reporting and access control compliance to a means for simplifying and streamlining the process of assigning and managing access within the enterprise. It is also important, after a role model has been defined, to institute a governance model for managing and maintaining the roles on an ongoing basis. Roles, like identities, are not static and must be managed for change through a disciplined change-control process. Note: See the lesson titled Performing Role Lifecycle Management for more information. Based on Oracles experience in helping companies adopt a role-based model for access control, it has pioneered a procedure for defining, implementing, and administering a role governance body. Whereas the topic of role governance is beyond the scope of this course, it should be noted that a role governance board is a cross-functional oversight body whose primary objective is to ensure that appropriate policies and procedures are followed for the creation, modification, and deletion of roles.
Accessing Role Mining
Role Management consists of the following objects: Role Mining Rule Discovery Role Consolidation Rules Entitlements Discovery
Accessing Role Mining

Oracle Identity Analytics is a valuable tool for implementing the Wave Methodology. It provides capabilities that support each of the steps previously mentioned. To access the role-mining product features, open the user interface and click the Role Management tab. The Role Management tab provides access to role-mining capabilities and various other identity correlation tasks, including role consolidation, role discovery, entitlements discovery, and rules discovery. The role-mining functionality is primarily intended for use by administrators.

The role-mining process consists of the following steps: 1. Specify Minable Attributes (prerequisite). 2. Enter General Information / Selection Strategy. 3. Select Users Based on Selection Strategy. 4. Specify the Criteria for Performing Role Mining. 5. Preview the Results (before execution). 6. Perform Role Mining (execution). 7. Review the Results. 8. Save Roles.

This slide demonstrates the steps that should be followed when performing role mining. Select New Role Mining Task from the user interface to initiate the role discovery process. The following pages provide additional details about the steps shown in this slide.
Role Mining: Minable Attributes

Step 1: Specify Minable Attributes (Prerequisite).
Role Mining: Minable Attributes

Oracle Identity Analytics evaluates resource attributes and attribute values during the rolemining process. Oracle Identity Analytics can then determine similarities between users and recommend roles based on those similarities. You specify attributes as being minable for each resource definition. This can be found under Administration > Resource Types in the graphical user interface. This slide demonstrates the attributes associated with the Entitlements resource for the AIX resource group. You can specify the following parameters for each attribute associated with this resource: Mandatory: This flag, when selected, specifies all the privileges for the attribute such as managed, importable, and so on. Managed: To display an attribute or import it, the managed flag needs to be set for the attribute. Auditable: This flag enables the attribute to be checked for audit exceptions. Importable: This flag enables the attribute to be imported from a CSV or Text File.
Role Mining: Minable Attributes (continued)

Minable: This flag enables Oracle Identity Analytics to run its role-mining algorithms over this attribute to produce roles. Certifiable: This flag enables this attribute to be evaluated during the identity certification process.
It is important to specify attributes that are critical in terms of defining access to a particular application or target system and set them as minable before initiating the role-mining process. This gives the role engineer the flexibility to include only relevant applications and relevant attributes for best data-mining results and ensures that the appropriate applications and input data are accounted for while the role-mining algorithm is running. Irrelevant attributes can thus be discarded from the role-mining exercise. Performing role mining without any attributes set as minable will result in an error. Note: Including attributes that are not important will affect the accuracy of the role-mining effort.
Role Mining: General Information

Step 2: Enter General Information / Selection Strategy.
Role Mining: General Information

To perform a role-mining task, you need to provide a name for the task and select an appropriate Selection Strategy against which to perform the role-mining task. In the Name text box, you provide a name by which the system will refer to the results of this task at a later time. This name should be descriptive enough to provide meaning. If not, you can also enter a description for the task. You also need to specify a set of users that will be evaluated during the role-mining process. In the Selection Strategy section, you select from various ways to search for and specify these users. You can locate users associated with a particular business structure, resource, or role, or select users individually by selecting one of the following options: By Business Structures By Resources By Existing Roles Users For example, selecting the By Business Structures option enables you to select from those users associated with a particular business structure. The user interface would then provide you with a list of business structures that you can choose from in order to locate those users. Your selection on this page dictates what you see on the next page.
Role Mining: User Selection

Step 3: Select Users Based on Selection Strategy.
Role Mining: User Selection

On the User Selection page, you specify the users that will be included in the role-mining process. This slide demonstrates users being selected based on Business Structure. Navigate through the options in the left panel to see the users associated with a particular business structure. You can select each user individually or use the All and Page check boxes to select multiple users at one time. All: Selects all the users associated with that business structure. In this particular example, this would include 58 users, which are the number of records associated with this business structure. Page: Selects all the users being displayed on the current page (or in this case, 50 users). You can use the drop-down list next to Display to change the number of users displayed on one page. You can click a page number link or click the Next link to scroll through the pages. As users are selected, a new panel opens at the bottom of the page that displays the set of users you have selected. This panel can be used to review the users selected.
Role Mining: Basic Parameters

Step 4: Specify the Criteria for Performing Role Mining.
Role Mining: Basic Parameters

The role mining feature uses the Expectation Maximization and Cobweb Clustering algorithms when performing role discovery. You can control the output of these algorithms by specifying various parameters as follows: Role Mining Parameters HR Attributes Advanced Parameters The Expectation Maximization algorithm is iterative in nature and should be told when to stop processing. In the Role Mining Parameters section, you can specify how many roles to recommend during the mining process. You can enter a maximum number of roles, or let the system determine the number for you after it has run through a maximum number of iterations. A value of negative one (-1) for the number of roles disables the maximum count, and the system runs to completion, providing all possible roles. This parameter works for demonstration purposes or for small sample sizes, but should not be used for large numbers of users. Instead, a best practice is to set the maximum number of roles to be 1 percent of your user population, up to a maximum of 350. In the HR Attributes section, you can specify a list of user attributes that can be incorporated into the search algorithm. Using these parameters, along with the logical grouping of users by job responsibility, gives the best results for a hybrid role-mining effort.
Role Mining: Advanced Parameters

Step 4: Specify the Criteria for Performing Role Mining.
Role Mining: Advanced Parameters

In the Advanced Parameters section, you can specify additional parameters that further refine the role-mining process. The following table provides an explanation of these parameters. Parameter: Ignore attributes with a frequency lower than Description: Attributes may not be relevant if the frequency they show is low, and they may introduce noise. Processing them is costly and adds processing time. Parameter: Data Resampling Percentage
Description: The best threshold value is 300%. Parameter: Min. standard deviation
Description: This is used by the role-mining algorithm to size the amount of user detail to capture. Use values between -2, -1, 0, 1, and 2. Larger numbers (positive or negative) return more outliers.
Role Mining: Advanced Parameters (continued)

Parameter: Single instance per user Description: Keep this selected to choose a single instance per user. Parameter: Use Binary splits Description: The goal of splitting is to get more roles with greater differences. When role mining, the ideal subset is a group of users who do not share any attributes with users in any other group or role. Enabling Binary splits forces Oracle Identity Analytics to attempt to build a role classification model with greater differences. Parameter: Confidence factor Description: This provides a method to statistically analyze the users-to-role assignment data and estimate the amount of error inherent in it. Parameter: Minimum users per role Description: This specifies the minimum number of users per role when building the classification rules. If the cluster step has found a role with fewer users, the classification test can show incorrect results. Parameter: Number of folds Description: Reduce error pruning is another mechanism to prune the tree (the classification model). Consider subtree raising, which is another mechanism to simplify the classification model (smaller number of final roles). Parameter: Unpruned Description: A more complex decision tree (later decomposed into more rules) is generated. Parameter: Use Laplace Description: Use Laplace transforms when performing this operation.
Role Mining: Preview

Step 5: Preview the Results (Before Execution).
Role Mining: Preview

A good practice before running a role-mining task is to preview the input data selected for the role-mining exercise. This step is performed to ensure that all and only correct attributes are accounted for and to check for any visible inconsistencies in data.
Role Mining: Execution

Step 6: Perform Role Mining (Execution).
Role Mining: Execution

After you have previewed the results, it is time to perform the execution of the role-mining exercise. This slide shows the Run Results section associated with the role-mining task. Note that the value of Run Status is FINISHED. This indicates that the role-mining task has been completed and you can view the results. Click the view link beneath the View Results column to see the results of the role-mining exercise.
Role Mining: Users In Roles

Step 7: Review the Results.
Role Mining: Users In Roles

The Users in Roles tab displays a pie chart that shows the percentage of users assigned to each role type as part of the role-mining process. In this example, four roles were recommended based on the input provided to the mining algorithms. The generic role names are as follows: Role : 1::RM-Sun Nov 29 12:33:59 EST 2009 Role : 2::RM-Sun Nov 29 12:33:59 EST 2009 Role : 3::RM-Sun Nov 29 12:33:59 EST 2009 Role : 4::RM-Sun Nov 29 12:33:59 EST 2009 The role name consists of a unique identifier (Role : 1, Role : 2, and so on) concatenated with the time stamp of when the role-mining process took place. You should rename these roles to make the names more readable and understandable. The pie chart also shows the percentage of users who were found in each role. The Classification Rules tab provides more details about the actual number of users and how the percentages were calculated.
Role Mining: Classification Rules

Role Mining: Classification Rules

The Classification Rules tab displays a page that shows the classification rules that were used to create the roles during the role-mining process. This information is contained in the Description column on that page and is used to generate the generic role name shown in the Role column. The Record Count column demonstrates the number of users that fall under the rules specified by the classification. The Confidence % column contains a factor for the Weka data-mining algorithm used for the role-mining process. Note: Waikato Environment for Knowledge Analysis (Weka) is a collection of learning algorithms utilized for data-mining tasks. The software was developed at the University of Waikato and is available under the GNU General Public License. For more information, refer to the Weka Software Web page at http://www.cs.waikato.ac.nz/ml/weka/.
Role Mining: Mining Statistics

Role Mining: Mining Statistics

The Mining Statistics tab reports the following statistics that you can use to interpret the role mining results: % of Users correctly/incorrectly assigned This mining statistic tells what percentage of users has been assigned correctly and what percentage has not. Kappa value The higher the Kappa value, the stronger the agreement. Depending on the application, a Kappa value of less than 0.7 indicates that your measurement system needs improvement. Kappa values greater than 0.9 are considered excellent. Kononenko & Bratko score / Relative score This is a score of the data-mining algorithm. This value can be disregarded.
Role Mining: Roles

Role Mining: Roles

The Roles tab provides a listing of the roles that were found during the mining process. The page displays two panels: Left panel: Is the Roles Found panel that lists the created roles Right panel: Contains two tabs: Role Details and Membership The Roles Found (left) panel displays the roles that were found during the mining process. You can expand a particular role to see the resource types, resources, and minable attributes associated with that role. Selecting any one of these items provides role membership details for that item in the right panel.
Role Mining: Roles (continued)

The right panel shows users with and without entitlements for the item selected in the Roles Found panel and contains the information as described in the following table: Column: Resource Type Description: Displays the type of resource associated with this role. This may or may not be a subset of all the possible resource types configured in the Identity Warehouse. A complete listing of all resource types can be found at Administration > Configuration > Resource Types. Column: Resource
Description: Displays the specific resource within the resource type Column: Attribute name
Description: Displays the name of the minable attribute associated with the resource Column: Attribute Value
Description: Displays the value of the minable attribute Column: % of Users
Description: Displays the percentage of users that have access to the selected attribute Column: No. of Users
Description: Displays the number of users that correlate to the attribute listed in the role You can use the cutoff slider to select the desired risk percentage. All attributes above the cutoff percentage will be set to a primary or parent role policy, and all those below the cutoff percentage will be set to a secondary policy for child roles.
Role Mining: Role Mining Reports

Step 8: Save Roles.
Role Mining: Role Mining Reports

The role-mining process has not yet made any change to the Identity Warehouse. You need to specify if you would like to save one or more roles or discard the data altogether. You can save the recommended roles by selecting Create Role from the Roles tab. When you do this, the Role Mining Report page appears. This page contains a list of all users pertaining to a particular role, as well as the attributes and values associated with the role across all resources and resource types.
Entitlements Discovery
Analyzes existing legacy roles Allows you to modify the entitlements within these roles as follows:
Define new roles. Re-evaluate existing roles. Refine existing roles.
Can be used for role consolidation
Entitlements Discovery
After roles are defined for critical applications, you might not want to add new roles or change the makeup of an existing role. Instead, you might want to introduce a larger domain of application entitlements into these roles. You can accomplish this by increasing the relevant minable attributes for applications and running entitlements discovery on existing roles. The entitlements discovery process analyzes legacy roles to define, reevaluate, and refine the content of these roles. Entitlements discovery can also be used for role consolidation if you need to include more applications in the role entitlement mix.
Accessing Entitlements Discovery
Consists of the following objects: Role Mining Role Consolidation Entitlements Discovery
Rule Discovery Rules
Accessing Entitlements Discovery

From the Role Management tab, you can perform role mining and various identity correlation tasks, including role discovery, role consolidation, entitlements discovery, and rules discovery. This feature is primarily intended for use by administrators. Select Entitlements Discovery to initiate the entitlements discovery process.
Performing Entitlements Discovery

The entitlements discovery process consists of the following steps: 1. Select the Attribute Type Strategy. 2. Select the Role and Associated Users. 3. View, Modify, and Save Updated Role Entitlements. 4. Verify and Commit Policy Changes.
Performing Entitlements Discovery

This slide demonstrates the steps that should be followed when performing entitlements discovery. The following pages provide additional details about each step.
Entitlements Discovery: Strategy

Step 1: Select the Attribute Type Strategy.
Entitlements Discovery: Strategy

You need to select an appropriate strategy for performing an entitlements discovery task. You can evaluate existing roles based on minable attributes or entitlement discoverable attributes.
Entitlements Discovery: Role/Users

Step 2: Select the Role and Associated Users.
Entitlements Discovery: Role/Users

The next step in the process is to select from the left pane the role that you would like to evaluate (for example, Customer Service Representative). Selection of a role populates the right pane with all users who currently possess that role. You can select each user individually or use the All and Page check boxes to select multiple users at one time. All: Selects all the users associated with that role. In this particular example, this would include 30 users, which are the number of records associated with this role. Page: Selects all the users being displayed on the current page. The number of users associated with this role (30 users) is less than the maximum number of users that can be displayed on this page (which is 50). In this particular case, selecting the Page check box is the same as selecting the All check box. You can use the drop-down list next to Display to change the number of users displayed on one page. You can click a page number link or click the Next link to scroll through the pages. As users are selected, a new panel opens at the bottom of the page that displays the set of users you have chosen. This panel can be used to review the users selected.
Entitlements Discovery: Entitlements

Step 3: View, Modify, and Save Updated Role Entitlements.
Entitlements Discovery: Entitlements

By clicking the View Details button, you can obtain granular information for the resources and entitlements associated with this role. The role name and number of users appear on the title bar of this window. The left pane shows the resources associated with this role, and the right pane allows you to drill down on each resource to view the attributes, percentage of users who share those attributes, number of users who share those attributes, and the ranking of those users. This slide shows that there are 30 users who are associated with the Customer Service Representative role. This role consists of eight resources comprising various minable attributes. The AIX resource has been expanded to show the aix_login, aix_home, aix_pgrp, and aix_groups minable attributes. If you select a resource in the left pane, the information appearing in the right pane pertains to all minable attributes. If you select a particular minable attribute in the left pane, the information in the right pane pertains only to that attribute.
Entitlements Discovery: Entitlements (continued)

The data in the right pane has been sorted in descending order based on the number of users that have these attributes. This slide demonstrates that there are 24 users (or 80 percent of the population) who have the aix_pgrp attribute with a value of AIX. You can increase or decrease the users associated with this role by changing the percentage associated with the cutoff slider. The access (attributes) related to these policies can be evaluated and added or removed by performing this action. Generally, feedback from the business or a role owner committee is recommended before changing the policies (associated access attributes). These policies, after they are renamed and finalized, can be re-associated to the original role. Click the Save Policies button on this page to create a new version of the policy. This new version is not yet in production because it needs to be approved first.
Entitlements Discovery: Verification

Step 4: Verify and Commit Policy Changes.
Entitlements Discovery: Verification

You can see the updates by viewing the role within the Identity Warehouse as follows: 1. Select Identity Warehouse > Roles to see a list of existing roles. 2. Select the role that you updated from the left pane. You will see a reference to the updated version in the bottom-left pane. 3. Click the Versions tab in the right pane to see all versions of this role. 4. Select the check boxes between the previous version and the current version, and click the Compare Versions button. You will see side-by-side information of each version. This slide shows the policy differences between the two role versions. If you are satisfied with the changes, you can close this window and submit the changes for approval. If not, you can revert to the previous version of the role.
Best Practices
Get executive sponsorship for the project. Do not try to become completely role based. Utilize a knowledgeable implementation partner. Use a phased approach to the implementation. Define measurable milestones. Implement an identity management program and not just a provisioning project.
Best Practices
Avoid pitfalls by obtaining executive sponsorship for the project. Implementing a role based access solution requires inclusion of all business units across the enterprise. Do not try to become completely role based. Implementing a role solution that covers 80 percent of the user population will provide true return on investment. Utilize a knowledgeable implementation partner who is both experienced with the process as well as the tool. This can be critical to the overall success of your project. Use a phased approach to the implementation. Prioritize applications and business units and implement in several waves. Associate measurable milestones with each wave, and evaluate success at the end of each phase. Determine the amount of time saved and the costs that have been reduced by implementing the program, and evangelize the success to the organization. Implement role management as an overall identity management program along with provisioning. Role definition must be run in parallel with an identity management solution so that the roles can be used in a proactive manner during the provisioning process.
Summary
In this lesson, you should have learned to: Describe the best practices for role definition Perform role mining for a business unit Review and analyze the role-mining results Perform role entitlement discovery
Practice 6 Overview: Role Engineering

This practice covers Performing Role Engineering.
Performing Role Lifecycle Management
Objectives
After completing this lesson, you should be able to: Describe the phases of a roles life cycle Configure role workflows and approvals Perform role versioning Describe the best practices for managing roles
Objectives
Discussion: The following questions are relevant to understanding the topics covered in this lesson: How are roles maintained over time? What are the phases of role lifecycle management? What types of activities do you perform in each phase of role lifecycle management? How can you maintain control over role versions?
Role Management Activities

Periodic activities:
Role certifications (biannual) Segregation of duties (at role and policy level) Role versus actual Reporting (governance charter) Change logs User and organization changes Resolving role requests Rule creation and updates Application management
On-request activities:

Role Management Activities

Management of roles is an ongoing process. This slide lists some of the activities associated with role management.
Role Lifecycle Management

DEFINE REFINE
VERIFY

Because users roles and relationships constantly change, role management is an ongoing project, and the processes associated with it are best described in the context of a role lifecycle. This lifecycle consists of three phases: 1. Define Role engineering 2. Refine Role maintenance 3. Verify Role certification And then the cycle starts all over again.
Role Engineering (Definition)

Build a role framework. Create roles:
Import from file Manually from user interface Role mining
Role Engineering (Definition)

Role engineering includes building a role framework based on an organizations business model, and then defining roles by using data mining to apply the framework to existing user entitlements. Having this framework in place ensures that the defined roles reflect the organizations business processes and the job responsibilities that are associated with these processes. These topics have been discussed in previous modules.
Role Maintenance (Refinement)

Role owners attention to change events:
Role changes Entitlement changes
Impact analysis to change events Role consolidation Role decommission Entitlements discovery
Role Maintenance (Refinement)

After roles are established, they must be maintained, which means keeping the framework and roles consistent as the organization changes. This phase includes activities such as automatically notifying the role owner, who is usually the application owner, when changes occur to the entitlements underlying a role; performing impact analysis to show how role changes will affect users; and consolidating or enhancing existing roles based on organizational changes. Decommissioning a role removes all role-user associations. The role itself, however, is not truly deleted. Instead, the role is made inactive and stored in Oracle Identity Analytics. The role cannot be made active again, and it cannot be modified in any way or assigned to users. Entitlements Discovery analyzes legacy roles in order to define, reevaluate, and refine the content of these roles.
Examples of Change Events

Changes to access rights on resources that are part of the role Changes in the architecture of systems and applications Changes to applications (introduction or retirement) Changes in the organization structure Changes in HR system attributes
Examples of Change Events

The slide demonstrates common changes that occur during the life cycle of a role. Roles can change due to the addition or removal of access rights on the systems or applications that are part of the role. Additionally, changes to the architecture relating to the storage and application of these access rights can impact organizational roles and require a role change. Introduction of new applications or the retirement of existing applications can require new roles or roles to be modified within the organization. Changes to the organizational structure due to mergers, acquisitions, divestitures, and other events will impact the business structure. This will have a direct impact on the roles and users associated with that business structure. Rules may need to be modified based on attribute changes in the Human Resources application (that is, job code) because this can impact assignment of users within the business structure and roles to those users. All these events may require that new roles be created, existing roles be modified, or some roles even decommissioned.
Role Certification (Verification)

Periodically roles go through role recertification.
Role owners responsibility Attest to applicability of entitlements
Workflow processing is involved:

Automatic notification Approval routing Audited changes Reporting
Role Certification (Verification)

Periodically, the role framework and roles must be reviewed by management. This typically involves the role owner reviewing and attesting the privilege assignments for the roles associated with the application. Relevant activities such as notification and approval routing should be automated, audited, and documented as part of the process.
Workflows
Include a specific sequence of actions or tasks related to a business process Are used during role and policy creation and modification Involve various actors:
Initiate the workflow. Receive notifications. Perform approvals or rejections.
Are based on the Open Symphony Workflow engine
Workflows
A workflow is a specific sequence of actions or tasks related to a business process. In Oracle Identity Analytics, workflows enumerate each step involved in the various processes, such as role and policy creation, role and policy modification, and so on. A workflow lists all the actors, who play a pivotal role in the management of roles and policies, and their function. Oracle Identity Analytics has a robust and easy-to-configure workflow engine. Workflows can be configured to any environment because they are based on the open-source Open Symphony workflow engine. Each workflow can be customized to support diverse requirements such as role approval paths, policy approval paths, and email integration, and to expose Web services to communicate with third-party applications, and so on. You can make the following changes to a workflow: Add a step Delete a step Edit workflow action details
Default Workflows
Default Workflows
There are nine default workflows in Oracle Identity Analytics as described in the following table: Workflow Role creation Role modification Role membership Role membership activation Description Runs when a role is created Runs when a role is modified (for example, when a policy is added) Runs when users are added or removed from the role Runs to activate memberships that are pending activation. This workflow is automatically triggered by Oracle Identity Analytics. Runs when many roles are created or modified Runs when a policy is created Runs when a policy is modified Runs when a role provisioning rule is created Runs when a role provisioning rule is modified
Mass modification Policy creation Policy modification Role membership rule creation Role membership rule modification
You can edit an existing workflow by selecting the link for that workflow as shown in this slide.
Editing Workflows
Editing Workflows
The Edit Workflow page displays the name, description, and various steps involved in the completion of the task in Oracle Identity Analytics. A diagrammatic representation of the workflow is displayed to the right of the page. The following data is displayed to the left of the page: Name: Displays the name of the workflow Description: Displays the workflow description Steps: Displays a table explaining each step. See the following table for details. The following table provides an overview of the data contained in the Steps section.
Editing Workflows (continued)

Column Name StepName Link Status Actions Assignee Type Description Lists all the steps involved in the workflow Displays the current status to the user Displays all the actions that can be taken in each step and the respective consequences Displays the type of actor that is assigned to complete this step. The assignee types are usually one of the following: Policy_owner: The designated policy owner Role_owner: The designated role owner Global_user: Any user who is assigned to complete the step Rule_owner: The designated rule owner Role: All users who are part of the selected role Displays the employee ID of the actor assigned to complete this step Gives you the option of adding a step, deleting a step, or adding an action
Assignee Operation
Custom Role Modification Workflow

Perform initial review of the role update. Meet Role Criteria No Work with the Role Owner and Business to refine the request. Email notification
Provides Role Approvals, Impact Analysis, and Consolidation Opportunities
Yes
Role updates exported to IDM solution
Approval emails sent to the requestor, Role Owners, and IS Team
Submit a request for a role update.
Review Impact Analysis in RBACx.
Approve the Role.
No
Role Owner works with the Business and IS Team to refine the role. No
Yes Review proposed roles to ensure consistency with company guidelines. Approves the Roles Yes Email notification
Business defines Role.
Submit a request for a role update.
Email notification
Custom Role Modification Workflow

The default role modification workflow as described in the previous section involves approvals from a policy owner and a role owner when changes are made to the role. This slide gives an example of a customized role modification workflow. The customized version demonstrates how role modification requests can be submitted from various sources and move through an approval process involving additional approvers. A role engineer can create a diagram similar to this in order to obtain an approval to make workflow modifications. He or she would then make the changes in the Oracle Identity Analytics interface.
Processing Role Changes

OIA Users initiate role changes.
Role owner Business partners
Role changes initiate email notifications. Role changes require approvals.

Policy owner Role owner
Approved role changes are updated in Identity Warehouse.

Role is versioned. History is maintained.
Processing Role Changes

Changes to roles are not automatic. They require the approval of one or more OIA Users before role definitions are updated in the Identity Warehouse. This slide describes the process followed when performing role changes.
Role Modification
Role Modification
The Identity Warehouse maintains information about any changes made to a role. You can see this by accessing Identity Warehouse > Roles from the graphical user interface. The top-left section of the page contains all roles that are currently configured in the Identity Warehouse. The bottom-left section of the page contains any outstanding versions of a particular role. This slide shows that version 2 of the Customer Service Representative role was created on 11/29/2009 and is currently pending. Select the outstanding version by clicking it. Information pertaining to that version of the role, including the role history, versions, and the status of any workflows pertaining to that role, can be seen on the right side of the page. Clicking the General tab shows the details of the role, including the version status. This slide shows that the Customer Service Representative role is currently in a status of Composing (it has not yet been submitted for approval). If you click the Workflow tab at this point, you can see that the Role Modification workflow has not been initiated. Click Send for Approval to initiate the workflow process.
Workflow Status
Workflow Status
Oracle Identity Analytics includes a default workflow named Role Modification. This workflow has the following steps: 1. Start Workflow: This step is performed after a role is created or modified, or when a member is added or removed. 2. Policy Owner Approval: If a policy owner approves the request, the workflow proceeds to the next step. Otherwise, the role is rejected. 3. Role Owner Approval: If a role owner approves the request, the workflow proceeds to the next step. Otherwise, the role is rejected. 4. Finish: The role is created or modified. This slide shows that the first two steps have been performed and that the workflow is halted, pending action in Step 3.
Pending Requests
Pending Requests
Approvers specified in the Role Modification workflow receive an email notification that they have an approval pending. The body of the email requests that they log in to the Oracle Identity Analytics interface to respond to the outstanding request. This slide shows the pending request for the Customer Service Representative role modification. This page provides information about who initiated the request, the date of the request, the request being made, and the type of object that the action is being applied to. Approvers select the option button next to the pending request and click either Approve or Reject to act on the request. Additionally, they can click View to obtain more information about the request.
Modification Details
Modification Details
Clicking View on the previous screen provides more details about the changes being requested. This slide shows the information provided on the Policy Modifications tab. Click either Approve or Reject to act on the request.
Role Versions
Role Versions
After a role is acted upon (approved or rejected), you can return to the Roles section of the Identity Warehouse (Identity Warehouse > Roles) to see that the new version is no longer pending. This slide demonstrates both versions of the Customer Service Representative role. Version 2 of the role was approved by rbacxadmin on 11/30/2009 and is currently active. You can compare the differences between roles by selecting the check box for those versions and clicking Compare Versions. Additionally, you can select a particular version and revert back to that version by clicking Revert to Version.
Role History
Role History
The History tab provides a detailed view of the changes made to a role over time. This slide demonstrates the policy changes made to the Customer Service Representative role between the previous version (Version 1) and the current version (Version 2).
Best Practices
Use Oracle Identity Analytics as the authoritative source for roles, policies, role owners, and policy owners. Role owners and policy owners are validated on a periodic basis. Role history and versioning are critical. Use two levels of approvalsrole owner and application owners. Impact analysis should be performed before role creation or modification for various conflicts, for example SoD. Role consolidation should be performed before role creation or modification.
Best Practices
This slide shows the best practices to use when performing role management.
Summary
In this lesson, you should have learned to: Describe the phases of a roles lifecycle Configure role workflows and approvals Perform role versioning Describe the best practices for managing roles
Practice 7 Overview: Performing Lifecycle Management

This practice covers the following topics: Configuring Role and Rule Workflows Performing Role Modification and Approval Performing Role Consolidation Configuring Role Management Auto-Provisioning Rules Configuring Role Segregation of Duties (SoD) Configuring Event Listeners
Generating Reports
Objectives
After completing this lesson, you should be able to create: Default reports Custom reports
Objectives
Discussion: The following questions are relevant to understanding the topics covered in this lesson: What types of reports are available and how can I use them to achieve compliance? How can I create my own custom reports?
Reports
Reports are critical components toward achieving compliance. Oracle Identity Analytics provides the following report functionality:
Default (out-of-the-box) reports Customizable reports
Reports can be run manually or scheduled. Reports can be viewed online or can be downloaded directly to PDF or CSV. Reports viewed online can be exported to other formats or printed.
Reports
Reports are valuable tools for evaluating, analyzing, and achieving overall compliance within an organization. Reports are used extensively when performing role discovery, entitlements discovery, certifications, or simply trying to review access rights. As such, reports are critical components and Oracle Identity Analytics provides extensive default reporting capabilities. If default reports do not meet your needs, Oracle Identity Analytics provides capabilities to extend reporting by enabling you to add your own custom reports. Reports can be viewed online or downloaded to the desktop as PDF or CSV files. If you review a report online, you have the option of exporting it to various formats (PDF, XLS, CSV, HTML, XML) or printing the report.
Reporting Categories
Business Structure Reports System Reports
User reports Role reports Policy reports Exception reports Forecast reports
Audit Reports (audit exceptions) Custom Reports
Reporting Categories
Oracle Identity Analytics provides reporting capabilities by default with several predefined reports. This information can be classified into four broad categories: Business Structure Reports, System Reports, Identity Audit Reports, and Custom Reports. Business Structure Reports are run against selected business structures and provide information pertinent to those business structures. This includes reports such as the Business Structure Users Report, which provides the user identifier, first and last names, and email addresses of all users associated with a particular business structure. Note: All child business structures are included in reports when its parent business structure is selected. System Reports can further be broken down into user reports, role reports, policy reports, exception reports, and forecast reports. Information contained in these reports is global to the entire system and provides granularity based on the type of system report being run. Audit Reports provide audit-related exceptions and include information pertaining to segregation of duties, assigned versus actual rights violations, and terminated user reports. If one of the default reports does not meet your needs, you can create your own custom reports by using the open-source Jasper product. Details on how to accomplish this are provided later in this lesson. Note: Oracle Identity Analytics also has reports that are specific to the certification process. These are called Certification Reports and are accessible during Certification processing. See the lesson titled Configuring Identity Certification for more information.
Accessing Reports
OIA Users access reports from the Reports tab.
Dashboard Sign off Reports Ad Hoc Reports Schedule Reports Custom Reports
User interface is customized based on the OIA Role.

Not all OIA Users will see this tab. OIA Users who see this tab may not see all options.
Accessing Reports
The Reports tab in the graphical user interface provides access to the following reporting features: Dashboard: The dashboard page provides a graphical overview of executed Business Structure Reports and pending Certification Reports. Sign off Reports: The Sign off reports page provides access to pending reports and completed reports. The user is able to act on pending reports and view completed reports. Ad Hoc Reports: The Ad Hoc Reports page provides access to Business Structure Reports, System Reports, Identity Audit Reports, and Custom Reports. Schedule Reports: The Schedule Reports page provides access to any previously scheduled report jobs and enables you to schedule a new report job as desired. Whether the OIA User sees the tab or sees all these features depends on the system privileges assigned in their OIA Role.
Report Dashboard
Constraints by date:
Report Dashboard
Selecting the Dashboard option on the Reports tab takes you to the Reports Dashboard page. The Reports Dashboard page summarizes status information for reports and contains the following graphs: Reports by Business Structure Reports that are pending, accepted, or rejected by the managers
Business Structure Reports

Reports > Ad Hoc Reports > Business Structure Reports
Business Structure Reports

One of the most useful features of the Reports tab is providing access to Ad Hoc Reports. The Ad Hoc Reports page provides access to the following types of reports: Business Structure Reports System Reports Identity Audit Reports Custom Reports This slide shows the default Business Structure Reports provided with Oracle Identity Analytics. These reports can be run and viewed online, or they can be exported to PDF or CSV for download to your local machine. Click Run to execute a particular report in the user interface. You can also click Download to download a particular report in a particular format.
Business Structure Roles Report
Business Structure Roles Report

This slide shows the Roles Report, which is one of the Business Structure reports. After you have viewed a report online, you can export the data to other formats (PDF, XLS, CSV, HTML, XML) or print it directly from this page.
Creating Custom Reports

Are located in $RBACX_HOME/reports Are added by importing report templates Can be created by:
Using the Jaspersoft iReport report designer Directly editing the Jasper Report XML file
Can be imported through the user interface Reports > Custom Reports > New Custom Report Appear as Ad Hoc Reports Reports > Ad Hoc Reports > Custom Reports
Creating Custom Reports

You can create custom reports in Oracle Identity Analytics to suit the requirements of your organization. The following steps are involved in creating and running custom reports: 1. Create a custom reports template. Custom reports templates can be created with a graphical designer tool, such as iReport, or can be created manually by directly editing a Jasper Report XML file. iReport is a free, visual, and open-source report designer for JasperReports. iReport is used to create a Jasper Report XML file (.jrxml) that represents the JasperReports report definition. Oracle Identity Analytics custom reports are created by importing the Jasper Report XML file. 2. Import the custom reports template. Custom reports are created by importing the Jasper Report XML file into Oracle Identity Analytics. Navigate within the user interface to Reports > Custom Reports and select the New Custom Report option. The New Custom Report window opens and enables you to provide the specifications for the new custom report.
Creating Custom Reports (continued)

Report Name: This is the name that will appear when the report is referenced in the user interface. Sub-Report: If you require subreports, select this check box. Selecting this check box will display additional fields that you can use to specify subreport templates to be uploaded. Prompts: Oracle Identity Analytics has five prompts: Business Structure, Users, Date Range, Roles, and Custom Properties. Custom reports can be run on any or all of the prompts that you select. Custom Properties will display five prompts where you can enter relevant values to run the report. File Uploads: Click Browse to locate and upload the Jasper Report XML file.
Custom reports will appear as Ad Hoc reports under the Custom Reports option. 3. Run or schedule the report as needed. Note: JasperForge (http://www.jasperforge.org) is the open-source development site for iReport and JasperReports. From this site, you can download the iReport software from JasperForge, learn how to create Jasper Report XML files, and interact with the JasperForge community.
Executing Custom Reports
Executing Custom Reports

Custom Reports are listed as Ad Hoc Reports and can be found under the Custom Reports section. This slide shows that Custom Reports have the same functionality as default reports. You can run the report or download a PDF or CSV file to your local desktop. If you elect to view the report online, you can then print it or export it to one of the available formats (PDF, XLS, CSV, HTML, or XML).
Summary
In this lesson, you should have learned to create: Default reports Custom reports
Practice 8 Overview: Generating Reports

This practice covers the following topics: Creating default reports Creating custom reports

D68340GC20 SG

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D68340GC20 SG

Uploaded by

Copyright:

Available Formats

Oracle Identity Analytics 11gR1: Administration

D68340GC20 Edition 2.0 December 2010 D71223

6-8 6-11 6-12 6-14 6-16 6-17

Introducing Oracle Identity Analytics 11gR1

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

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

Oracle Identity Analytics 11gR1: Administration 1 - 2

Business: Open Access

Improve Quality of Service

European Data Protection Directive

Health Insurance Portability & Acct Act (HIPAA)

Oracle Identity Analytics 11gR1: Administration 1 - 3

Controlling System Access

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

Controlling System Access

Oracle Identity Analytics 11gR1: Administration 1 - 4

Controlling System Access (continued)

Oracle Identity Analytics 11gR1: Administration 1 - 5

How do companies determine this information today?

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

Oracle Identity Analytics 11gR1: Administration 1 - 6

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

Oracle Identity Analytics 11gR1: Administration 1 - 7

Problems with This Approach

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

Problems with This Approach

Oracle Identity Analytics 11gR1: Administration 1 - 8

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

Oracle Identity Analytics 11gR1: Administration 1 - 9

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

Oracle Identity Analytics 11gR1: Administration 1 - 10

Role Benefits (continued)

Oracle Identity Analytics 11gR1: Administration 1 - 11

Acquiring and providing access quickly Understanding and attesting to access

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

Oracle Identity Analytics 11gR1: Administration 1 - 12

Enterprise Roles (continued)

Oracle Identity Analytics 11gR1: Administration 1 - 13

Enterprise Role Management

Who approved the access assigned to users?

How can access control policies be enforced? Employees Access Management

Oracle Apps & Data

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

Enterprise Role Management

Oracle Identity Analytics 11gR1: Administration 1 - 14

Enterprise Role Management Categories

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

Enterprise Role Management Categories

Oracle Identity Analytics 11gR1: Administration 1 - 15

Enterprise Role Management Categories (continued)

Oracle Identity Analytics 11gR1: Administration 1 - 16

Oracle Identity Analytics

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

Oracle Identity Analytics

Oracle Identity Analytics 11gR1: Administration 1 - 17

Oracle Identity Analytics Features

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

Oracle Identity Analytics Features

Oracle Identity Analytics 11gR1: Administration 1 - 18

Oracle Identity Analytics Features (continued)

Oracle Identity Analytics 11gR1: Administration 1 - 19

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