ca identity manager green book enu

Concepts and Examples

CA GREEN BOOKS

CA™ Identity Manager

EXAMINE SIX KEY IDENTITY MANAGEMENT SERVICES PROVIDED BY CA IDENTITY MANAGER.

EXPLORE EXAMPLES IN A SAMPLE CA IDENTITY MANAGER DEPLOYMENT SCENARIO.

LEGAL NOTICE

This publication is based on current information and resource allocations as of its date of publication and is subject to change or withdrawal by CA at any time without notice. The information in this publication could include typographical errors or technical inaccuracies. CA may make modifications to any CA product, software program, method or procedure described in this publication at any time without notice.

Any reference in this publication to non-CA products and non-CA websites are provided for convenience only and shall not serve as CA’s endorsement of such products or websites. Your use of such products, websites, and any information regarding such products or any materials provided with such products or at such websites shall be at your own risk.

Notwithstanding anything in this publication to the contrary, this publication shall not (i) constitute product documentation or specifications under any existing or future written license agreement or services agreement relating to any CA software product, or be subject to any warranty set forth in any such written agreement; (ii) serve to affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (iii) serve to amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this publication remain at CA’s sole discretion.

The information in this publication is based upon CA’s experiences with the referenced software products in a variety of development and customer environments. Past performance of the software products in such development and customer environments is not indicative of the future performance of such software products in identical, similar or different environments. CA does not warrant that the software products will operate as specifically set forth in this publication. CA will support only the referenced products in accordance with (i) the documentation and specifications provided with the referenced product, and (ii) CA’s then-current maintenance and support policy for the referenced product.

Certain information in this publication may outline CA’s general product direction. All information in this publication is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this document “AS IS” without warranty of any kind, including, without limitation, any implied warranties of merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill or lost data, even if CA is expressly advised of the possibility of such damages.

COPYRIGHT LICENSE AND NOTICE:

This publication contains sample application programming code and/or language which illustrate programming techniques on various operating systems. Notwithstanding anything to the contrary contained in this publication, such sample code does not constitute licensed products or software under any CA license or services agreement. You may copy, modify and use this sample code for the purposes of performing the installation methods and routines described in this document. These samples have not been tested. CA does not make, and you may not rely on, any promise, express or implied, of reliability, serviceability or function of the sample code.

Copyright © 2007 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies.

ACKNOWLEDGEMENTS

Principal Authors:

Tommy Cheng Palaka Bhattacharya Roland Campbell Jane Chen Asher Dahan Brian Dyson Steve Firestone Bob Kennedy Tony Lawman Joel Lemieux Ted Short Alan Zhu

The principal authors and CA would like to thank the following contributors:

Aaron Berman Phil Bertuglia Carolyn Jones Di-Jen Leu Kevin Murphy Mike Nickle Marc Ochinang Nick Pullman Bhanu Sareddy Sami Shaik Cheryl Stauffer Bob Taylor

CA™ Identity Manager 5

Contents

Chapter 1 : Introduction .............................................................................................. 13 The Six Categories of Identity Management Services ........................................................13

Delegated Identity Management..................................................................................14 Identity Self-Service ..................................................................................................14 Web Application Authorization.....................................................................................14 Delegated Account Management..................................................................................14 Account-Level Self-Service .........................................................................................15 Identity Policies and Automation .................................................................................15

Return-On-Investment and Time-To-Value ......................................................................15 Suggested Paths for Reviewing This Book ........................................................................16

Chapter 2 : Identity Manager Environment .................................................................. 19 User Data Store Management ........................................................................................19

directory.xml ............................................................................................................20 LDAP User Data Stores...............................................................................................21 RDB User Data Stores ................................................................................................22 eTrust Admin Server User Data Store and Provisioning Directory.....................................23 Authentication Directories...........................................................................................23 Secure Management Console Using the Built-In CA SiteMinder ........................................24

Identity Manager Environments......................................................................................25 Identity Populations...................................................................................................25 Multiple IMEs and User Data Stores .............................................................................25 Creating an Identity Manager Environment ...................................................................26

Sample Identity Manager Environments ..........................................................................26 Sample NeteAuto Directory Information Tree ................................................................27 Identity Manager Directory Level Security ....................................................................27 Employee IME ...........................................................................................................28 Customer IME ...........................................................................................................29 Vendor IME...............................................................................................................30

Chapter 3 : Delegated Identity Management ............................................................... 33 Password Management..................................................................................................33

Password Policies ......................................................................................................34 Password Policies Planning Considerations ....................................................................34

Delegated Administration ..............................................................................................35 Role-Based Access Control..........................................................................................35 Admin Task ..............................................................................................................39 Admin Role ...............................................................................................................42

Identity Populations, Management, and Authority.............................................................43 Authority ..................................................................................................................43 Delegation................................................................................................................44 Request and Approval ................................................................................................44 Backend Authority Services ........................................................................................45

Delegated Identity Management Services ........................................................................45 Delegation System Management Services.....................................................................46 Backend Authorities ...................................................................................................47 Identity Objects Authorities ........................................................................................47 Help Desk Assisted Services........................................................................................47 Supervisor Assisted Services.......................................................................................48 Supervisor Delegation Assisted Services.......................................................................48

6 Contents

Sample Delegated Identity Management Services.............................................................49 Customer Delegated Identity Management Services.......................................................49 Customer Delegated Identity Management Roles ...........................................................51 Vendor Delegated Identity Management Services ..........................................................53 Vendor Delegated Identity Management Roles ..............................................................54 Employee Delegated Identity Management Services.......................................................58 Employee Delegated Identity Management Roles...........................................................59

Real World Implementation Considerations ......................................................................66 Secured Communication Channels ...............................................................................66 User Interface Customization ......................................................................................66 Common Customization Scenarios ...............................................................................67 Initial Roll-out and Ongoing Operations ........................................................................67 Deployment and Performance Consideration .................................................................67 Operation and Maintenance ........................................................................................68

Chapter 4 : Identity Self Service .................................................................................. 69 Identity Directory and Privacy ........................................................................................69

Employee Directories .................................................................................................70 Vendor Directories .....................................................................................................70 Customer Directories .................................................................................................70 Member Directories....................................................................................................71 Public Directories.......................................................................................................71

Self Service and Authority .............................................................................................71 Profile Self Service.....................................................................................................71 Advertise Your Services..............................................................................................71 Self-Registration .......................................................................................................72 Self-Registration Design Considerations .......................................................................72

Self Authentication .......................................................................................................74 Publicly Accessible Entry Points & Windows Login ..........................................................75 User ID Identification.................................................................................................75 Forgotten ID .............................................................................................................76 Self Authentication Questions and Answers...................................................................76 System Generated Passwords versus User Supplied Passwords .......................................76 Avoid AutoComplete ..................................................................................................77 Different Self-Authentication Requirements...................................................................77 Remove or Disable Unused Public Tasks .......................................................................77

Sample Identity Self-Services ........................................................................................77 Customer Identity Self Services (Services) ...................................................................78 Customer Identity Self-Services (Roles) .......................................................................85 Employee Identity Self-Services (Services) ...................................................................87 Employee Identity Self-Services (Roles) .......................................................................89

Real World Implementation Considerations ......................................................................90 Secured Secure Self Services ......................................................................................90 Initial Roll-out and Ongoing Operations ........................................................................92 Deployment and Performance Consideration .................................................................92

Chapter 5 : Web Application Authorization .................................................................. 93 Personalized Web Application Delivery.............................................................................93

Map Web Applications to the Users ..............................................................................94 Presenting Web Applications to the Users .....................................................................94 Personalizing Web Application Presentation...................................................................96 Self Subscribing Groups .............................................................................................97

Enhance CA SiteMinder with RBAC Rules .........................................................................98 Configuration ............................................................................................................99


Role Based Policy .................................................................................................... 100 Task Based Response............................................................................................... 100

Single Sign-on ........................................................................................................... 101 Single Policy Server .................................................................................................101 Multiple Independent Policy Servers........................................................................... 101

Sample Web Application Authorization Services.............................................................. 103 Customer Web Application Authorization Services........................................................ 103 Customer Web Application Authorization Roles ............................................................ 104 Employee Web Application Authorization Services........................................................ 105 Employee Web Application Authorization Roles............................................................ 106

Real World Implementation Considerations .................................................................... 107 Initial Roll-out and Ongoing Operations ...................................................................... 107 Return On Investment.............................................................................................. 108 Deployment and Performance Consideration ............................................................... 108

Chapter 6 : Delegated Account Management ............................................................. 111 Namespace and Managed Endpoint Management............................................................ 112

Endpoint Management Delegation.............................................................................. 113 Acquire Managed Endpoints ...................................................................................... 113 Explore Managed Endpoints ...................................................................................... 114 Remove Managed Endpoints ..................................................................................... 114 Re-Explore and Authority.......................................................................................... 114 Privileges over Managed Endpoints ............................................................................ 115

Global User Object and Account Correlation ................................................................... 116 Global User Objects ................................................................................................. 116 Correlation ............................................................................................................. 116 Update Global User and Authority.............................................................................. 117 Correlation Rules..................................................................................................... 118 The Correlation-Matching Algorithm........................................................................... 119 Correlation Customization......................................................................................... 119 Resolve Correlation Difficulties .................................................................................. 119 Re-Explore and Correlate.......................................................................................... 120 Uncorrelated (Orphaned) Accounts ............................................................................ 120

Provisioning Engine and Identity Management ............................................................... 121 Corporate Directory and Provisioning Directory ........................................................... 121 Provisioning Directory and Corporate User .................................................................. 122 User Data Store and Global User Objects Synchronization ............................................ 123 Identity and Global User Attribute Mappings ............................................................... 124 Inbound Synchronization .......................................................................................... 124 Outbound Synchronization........................................................................................ 125

Delegated Account Provisioning.................................................................................... 126 Provisioning Roles and Authorities ............................................................................. 126 Provisioning Policies................................................................................................. 128 Global User and Account Synchronizations.................................................................. 130 Identity Account Synchronization Events .................................................................... 131 Provisioning Engineering .......................................................................................... 132

Delegated Account Services ......................................................................................... 133 Identity/Account Status Propagation .......................................................................... 133 Password Synchronization and Propagation................................................................. 134

Sample Delegated Account Management Services........................................................... 135 Employee Delegated Account Management Services .................................................... 135 Employee Delegated Account Management Roles......................................................... 137

Real World Implementation Considerations .................................................................... 139 Support Non-Standard Namespaces........................................................................... 139

8 Contents

Secured Communication Channels ............................................................................. 140 User Interface Customization .................................................................................... 140 Initial Roll-out and Ongoing Operations ...................................................................... 141 Return On Investment.............................................................................................. 141 Deployment and Performance Considerations.............................................................. 142 Patches and Upgrades.............................................................................................. 142 Operation and Maintenance ...................................................................................... 143

Chapter 7 : Account Self-Service................................................................................ 145 Account Service Self-Help............................................................................................ 145

Password Synchronization/Propagation Consideration .................................................. 146 Request Account Privileges of Interest .......................................................................... 146

Privilege Package .................................................................................................... 146 Privilege Package Display and Self Request................................................................. 146 Request Approval .................................................................................................... 147

Sample Account Self-Services ...................................................................................... 148 Employee Account Self-Service (Services) .................................................................. 148 Employee Account Self Service (Roles)....................................................................... 149

Real World Implementation Considerations .................................................................... 150 Secured Communication Channels ............................................................................. 150 Initial Roll-out and Ongoing Operations ...................................................................... 150 Return On Investment.............................................................................................. 150 Deployment and Performance Consideration ............................................................... 151 Operation and Maintenance ...................................................................................... 151

Chapter 8 : Identity Policies and Automation ............................................................ 153 Identity Policies.......................................................................................................... 153

Identity Policy ......................................................................................................... 154 Identity Policy Set ................................................................................................... 154 Identity Policy Actions.............................................................................................. 154 Identity Policy Rules ................................................................................................ 156 Data Model Changes ................................................................................................ 156 Triggering Identity Policies ....................................................................................... 157 Identity Policy Evaluation ......................................................................................... 159

Identity Policy Automation Applications ......................................................................... 160 Account Provisioning................................................................................................ 160 Provisioning Administration Delegation....................................................................... 160 Admin Roles and Access Roles Delegations ................................................................. 161 Identity Group Membership Management ................................................................... 162 User Profile Provisioning Automation.......................................................................... 162 Identity Policy and Authority Considerations ............................................................... 163

Compliance and Reporting ........................................................................................... 164 Compliance Policies ................................................................................................. 165 User Entitlement Certification.................................................................................... 166 Compliance Reports ................................................................................................. 167

Sample Identity Policies and Certification Services.......................................................... 170 Customer Certification and Identity Policies Services.................................................... 170 Customer Certification and Identity Policies Roles ........................................................ 172 Employee Identity Policies Services ........................................................................... 173 Employee Identity Policies Roles................................................................................ 174

Real World Implementation Considerations .................................................................... 174 Identity Policies Evaluation Considerations.................................................................. 174 New Identity Policies Roll-out Consideration................................................................ 175 Ongoing Operations for Identity Policies ..................................................................... 176


Initial Roll-out versus Ongoing Operations User Entitlement Certification ........................ 177 Initial Roll-out versus Ongoing Operations for Compliance Reporting.............................. 178 Reports for Return on Investment (ROI)..................................................................... 179 Deployment and Performance Considerations.............................................................. 180 Initial Roll-out of Identity Policies .............................................................................. 181 Admin Task's User Synchronize Option....................................................................... 182 The Additional Synchronize User Event....................................................................... 182

Appendix A: Third Party Tools.................................................................................... 185 Apache Tools ............................................................................................................. 185 Eclipse Tools .............................................................................................................. 185 GNU Tools ................................................................................................................. 186 SUN Java Tools .......................................................................................................... 186

Appendix B: Sample Files and IMEs Build .................................................................. 189 Disclaimer ................................................................................................................. 189 Sample Files Organization ........................................................................................... 189 Sample IME Building Procedures................................................................................... 191

CA Identity Manager Development Workstation........................................................... 191 Employee IME Machine............................................................................................. 191 Customer IME Machine............................................................................................. 193 Enable TEWS JSP Support ........................................................................................ 194 Vendor IME Machine ................................................................................................ 195

Appendix C: Sample User Data Store ......................................................................... 197 Utilities ..................................................................................................................... 197

Create the neteauto DSA Using eTrust Directory ......................................................... 197 Back Up the neteauto User Data Store ....................................................................... 197 Load NeteAutoDB.ldif ............................................................................................... 198

NeteAutoDB.ldif Content.............................................................................................. 198 System Identities .................................................................................................... 198 Employee IME Objects ............................................................................................. 199 Customer IME Objects.............................................................................................. 200 Vendor IME Objects ................................................................................................. 201

Appendix D: IME XML Files and Tools ........................................................................ 203 IME XML Files............................................................................................................. 203

Directory.xml.......................................................................................................... 203 RoleDefinitions.xml.................................................................................................. 204 EnvironmentSettings.xml ......................................................................................... 204

Create Portable RoleDefinitions XML File........................................................................ 204 Prerequisites........................................................................................................... 205 Increment Procedure ............................................................................................... 205 Decrement Procedure............................................................................................... 206 Export Role and Task Settings................................................................................... 206 diff Utility and Clean Up............................................................................................ 206 GenRoleXML.bat:..................................................................................................... 207

Appendix E: Logical Attribute Handler ....................................................................... 209 Admin Task Screen and Logical Attribute Handler ........................................................... 209

Physical Attribute .................................................................................................... 209 Logical Attribute ...................................................................................................... 209 Attribute Data Flow.................................................................................................. 210 Logical Attribute Handler .......................................................................................... 210

10 Contents

Logical Attribute API ................................................................................................ 210 ManagerDNAdapter Example........................................................................................ 210

Build and Deploy ..................................................................................................... 211 Register an LAH ...................................................................................................... 212 Applications ............................................................................................................ 213

Appendix F: CA SiteMinder Procedures ...................................................................... 215 Enable TEWS Security ................................................................................................. 215

Enable TEWS .......................................................................................................... 215 Secure TEWS .......................................................................................................... 216 TEWS CA SiteMinder Policies..................................................................................... 216

Custom loginGB.fcc for Public Directory......................................................................... 220 loginGB.fcc ............................................................................................................. 222

Appendix G: Email...................................................................................................... 227 Email Notification ....................................................................................................... 227

Deployment ............................................................................................................ 227 Email content.......................................................................................................... 227 Task and Event Email Notification .............................................................................. 228

Application Server Email Services ................................................................................. 229 Email Notification Configuration.................................................................................... 229

Enabling Email and Setting Template Directory ........................................................... 230 Deciding When to Send Email ................................................................................... 230

Email Templates......................................................................................................... 231 Sample CertificationRequiredNotificationEvent.tmpl ..................................................... 231 Email Templates Elements ........................................................................................ 233

Appendix H: Workflow ............................................................................................... 235 WorkPoint Workflow.................................................................................................... 235

Enable WorkPoint Workflow ...................................................................................... 235 Workflow Process .................................................................................................... 236 Approved or Rejected............................................................................................... 239

Appendix I: TEWS Client Programs ............................................................................ 241 Generate a Java Web Services Client Library.................................................................. 241

Prerequisites........................................................................................................... 241 Configuring Your IMEs.............................................................................................. 242 Building Your TEWS Client Library.............................................................................. 243 Rebuilding Your TEWS Client Library .......................................................................... 243

Standalone TEWS Client Program ................................................................................. 244 Code Client Program ................................................................................................ 244 Compile and Debug Client Program............................................................................ 245 Move Client Program to Production ............................................................................ 245

Third-Party Web Application Integration ........................................................................ 246 Building and Deploying Your TEWS Client Library......................................................... 246 Creating JSP Pages .................................................................................................. 246

Generic TEWS Command Line Interface......................................................................... 247 SOAP XML Document ............................................................................................... 247 GNU wget............................................................................................................... 248

wget Automation Utilities............................................................................................. 249 Prerequisites........................................................................................................... 249 wsbatch Subdirectory............................................................................................... 249

wget Automation Examples.......................................................................................... 251 Customer IME Certification Processes......................................................................... 251


Employee IME Create Employee ................................................................................ 252 Other Examples....................................................................................................... 254 Employee IME Search Users...................................................................................... 254

Eclipse and Eclipse Web Services Explorer ..................................................................... 257

Appendix J: Connector Xpress ................................................................................... 261 Sample KMS Files ....................................................................................................... 261 Use Connector Xpress ................................................................................................. 261

Create Connector Xpress Custom Connector ............................................................... 262 eTrust Admin Win32 Manager Screens ....................................................................... 266 Remove Connector Xpress Custom Connector ............................................................. 269 Deploy Using XML File .............................................................................................. 269

Appendix K: CA Identity Manager Architecture and High Availability......................... 271

Appendix L: Patches and Upgrades............................................................................ 275 Identity Management Infrastructure ............................................................................. 275 Provisioning Infrastructure........................................................................................... 275 General Recommendations .......................................................................................... 276


Chapter 1 : Introduction The purpose of this green book is to describe common requirements in the identity management domain and how CA Identity Manager meets those requirements. This green book supplements existing CA Identity Manager documentation. It is not intended to be a standalone publication. For more details, we encourage you to consult the CA Identity Manager product documentation and other related Information Technology documents.

There are six main categories of services CA Identity Manager provides to address the needs of identity management. In this chapter, we summarize these services at a high level. After the summary, you can choose from a list of possible reading paths that directly address the business needs CA Identity Manager can solve for you.

The rest of this book is organized into seven more chapters and a number of appendices. Chapter 2, Identity Manager Environment, discusses the foundation of CA Identity Manager. Chapters 3 through 8 contain detailed discussions for each of the six categories of identity management services. To help illustrate the concepts and explore the possibilities, we provide examples of three types of identity management systems, customer, vendor, and employee throughout the book. The sample files and tools we used to build our three environments are discussed in more depth in the appendices.

The Six Categories of Identity Management Services

The need for identity management grows out of the need for better account management as most companies require a better system to manage the increasing number of accounts their employees use to conduct their daily activities. Recent government regulations have also added more urgency for this need.

There is generally no single authority for the data maintained in an identity management system. Rather, an enterprise recognizes authoritative information sources. To allow an identity management system to function correctly and to receive the internal support required in today's enterprises, we begin by acknowledging that the authority concept (or authoritative information sources concept) is the core of an identity management system. Further, to allow a system to scale in operation, some level of delegation of that authority is required to reduce the number of possible bottlenecks. The concept of authority is discussed in detail in the "Delegated Identity Management" chapter.

The six categories of services CA Identity Manager provides are as follows:

■ Delegated Identity Management

■ Identity Self Service

■ Web Application Authorization

■ Delegated Account Management

14 Introduction

■ Account Self Service

■ Identity Policies and Automation

We have collected the knowledge from several implementers of CA Identity Manager and provided practical considerations and examples to demonstrate how these services can be offered. We encourage you read about the specific services that fit the needs of your enterprise.

Delegated Identity Management

Delegated identity management is one of the main building blocks of an identity management system. Within a delegated identity management implementation, three common identity populations exist: employees, vendors, and customers. CA Identity Manager's powerful rule-based delegation capability is the key component to enable delegated identity management.

Identity Self-Service

After a delegated identity management system is properly set up, an organization can consider offering self service to its identity population. The authority concept is enforced through identity self-service. You might consider identity self-service as a special application of delegated identity management.

Web Application Authorization

Web application authorization provides a transition between identity management and account management. When a user provides credentials to log into CA Identity Manager, the user is authenticated by CA SiteMinder, which establishes the user's identity. With the user's identity established, CA Identity Manager evaluates its policies and determines a list of tasks a user is authorized to perform. With this authorization defined, the system delivers a personalized list of tasks that can include a list of third-party Web applications to which the user has access. Another benefit of using CA SiteMinder is single sign-on between separate applications that are protected by CA SiteMinder and CA Identity Manager.

Delegated Account Management

Delegated account management addresses the complicated nature of today's IT environment. To enable CA Identity Manager to work with a system where accounts exist, we first need to recognize and catalog the nature of the system. We might decide to associate each individual account on such a system with its owner. To properly manage these accounts, CA Identity Manager uses a delegated role administration model. This model allows CA Identity Manager to manage accounts, account owners, account provisioning policies and roles for account provisioning.


Account-Level Self-Service

Similar to identity self-service, an organization can consider providing account-level self-service for its users. Compared to identity self-service, account-level self-service brings a special set of challenges as the number of accounts and systems involved are much greater than those for the traditional identity self-service.

Identity Policies and Automation

CA Identity Manager uses identity policies to create the delegated role administration for account provisioning. The same tool can be used to automate many identity management tasks in addition to enforcing segregation of duties and providing compliance checking.

Return-On-Investment and Time-To-Value

Return-On-Investment (ROI) is the term used to compare the cost invested in IT projects compared to the expenses saved because of that investment. Time-To-Value is the amount of time it takes for an enterprise to realize the cost benefit generated by an investment.

In general, businesses invest to:

■ Increase profits

■ Reduce costs

■ Meet government regulations

The ROI from an identity management project can include one or more of these benefits depending on your particular business needs. The calculation of the cost invested in identity management needs to include not only the cost during the project, but also the ongoing operational cost for the identity management solution. Our experience indicates that an identity management system should be broken up into small phases to minimize the time it takes to reach milestones and to build a potentially complex system by being successful with easier initial environments.

To break an identity management project into phases allows you to shorten the time needed to enjoy the early benefits, to learn from the earlier experiences, and to adjust your plans accordingly. This allows businesses to see an ROI with a faster time-to-value by incrementally realizing the benefits of an identity management investment. The six main categories of services of this book are designed to help you look into the value of the services that may hold the most benefits for your business.

16 Introduction

Suggested Paths for Reviewing This Book

With your priorities in mind, continue reading the next chapter “Identity Manager Environment” as it describes the basic infrastructure of a CA Identity Manager system. Delegated identity management is the foundation for all of the CA Identity Manager services, and should be considered by readers interested in all subsequent services. The following is a list of focus areas and the recommended chapters of this book associated with them:

■ Identity Management Focus

> Chapter 2 - Identity Manager Environment

> Chapter 3 - Delegated Identity Management

> Chapter 8 - Identity Policies & Automation

■ Account Provisioning Focus



> Chapter 6 - Delegated Account Management


■ Identity Self Service Focus



> Chapter 4 - Identity Self Service

> Chapter 5 - Web Application Authorization



■ Account Self Service Focus



> Chapter 4 - Identity Self Service

> Chapter 7 - Account Self Service




Using this list as a reference and with ROI and time-to-value in mind, you can review the chapters of this book that apply to your business needs.


Chapter 2 : Identity Manager Environment An identity management system starts with a set of identities and other supporting objects that require management. These identities and objects are stored in user data stores. A user data store is an Identity Manager directory within CA Identity Manager. CA Identity Manager uses the Identity Manager directories to configure Identity Manager Environments (IME).

The following shows the top level of the Identity Manager Management Console Web interface that you use to manage Identity Manager Directories and IMEs:

In this chapter, we focus on building and managing the identity management system's base infrastructure. This infrastructure consists of the following topics:

■ User Data Store Management

■ Identity Manager Environment

■ Sample Identity Manager Environments

In the User Data Store Management section, we discuss how to configure a user data store in the system to become an Identity Manager Directory; we go through various types of user data stores; and we conclude the section with how you can use CA SiteMinder features to help in some special scenarios. In the Identity Manager Environments section, we discuss how to create an IME and re-enforce the reasons to have different IMEs for different identity populations. In the Sample Identity Manager Environments section, we show the creation of the three sample IMEs used in this book.

User Data Store Management

A user data store contains the identities that you want CA Identity Manager to manage. CA Identity Manager is designed to handle user data stores that contain users, groups, and optionally organization objects. In this book, we refer to a user data store that stores all relevant user objects within the same container (or organization unit) as a Flat User Data Store. A user data store that has the relevant objects stored under different containers (or organization units) is referred as a Hierarchical User Data Store. This name is given in part

20 Identity Manager Environment

because CA Identity Manager requires multiple organization objects to be arranged in a hierarchical manner.

A user data store can reside in an LDAP directory or relational database (RDB). See http://supportconnect.ca.com http://supportconnect.ca.com for a complete list of the directories and relational databases CA Identity Manager supports.

directory.xml

A user data store is known as an Identity Manager Directory in CA Identity Manager. To describe how a user data store is defined to the system, you use an XML configuration file. This file, commonly referred to as the directory.xml, contains the structure and schema of the managed objects (organizations, users, and groups) and their attributes that are in the user data store. Instead of manually creating this configuration file, we recommend that you use the directory templates that are installed as part of the CA Identity Manager Administrative Tools. For more information about directory.xml, see the CA Identity Manager Configuration Guide.

To describe your user data store's characteristics using the directory.xml, consider the following:

■ Is the user store an LDAP directory or a relational database?

This is described using the <Provider> tag. For example:

<Provider type="LDAP" userdirectory="@SMDirName">

or

<Provider type="RDB" userdirectory="@SMDirName">

■ Is the directory flat or hierarchical?

A hierarchical user data store must have organization objects defined. It is described using the objecttype attribute of the <ImsManagedObject> tag. For example:

<ImsManagedObject name="Organization" description="My Organizations"

objecttype="ORG">

■ What are the profile attributes and well-known attributes in the directory?

Profile attributes are regular user, group, or organizational attributes. Standard well-known attributes are attributes used to support the base CA Identity Manager features such as self-service. Well-known attributes are listed in upper-case with % signs enclosed (for example, %ATTRIBUTE_NAME%) in the directory.xml. See the CA Identity Manager Configuration Guide for the complete list of standard well-known attributes.

■ Do you need to create your own well-known attributes?

http://supportconnect.ca.com/


Other than the system-defined well-known attributes, you might want to specify other attributes as well-known attributes for your own purposes. For example, define the well-known attribute for a nickname attribute as %NICKNAME%.

Note: We recommend using well-known attributes to ease referencing an attribute, particularly when writing custom code that accesses attributes for task handling. This practice gives the custom code the freedom to accommodate possible user data store changes. You do want to set a naming convention to avoid conflicting with the CA standard Well-known attributes. For instance, we use a GB prefix in the three sample directory.xml files used to construct examples for this book.

■ Do you intend to use self-subscribing groups?

The capability to offer self-service is one of the major benefits organizations have realized with their CA Identity Manager implementations. The adoption of the self-subscribing groups can add flexibility to your self-service implementation.

The SelfSubscribingGroups element controls the searching behavior of the self subscribing group. For example:

<SelfSubscribingGroups type=search_type org=org_dn>

You can disable the search, allow it to search the whole user data store, limit it to a search of a specific container, or limit it to search only the same container where the user exists.

Finally, directory.xml provides a flexible means for you to map attribute names. For example:

<ImsManagedObjectAttr physicalname="l" displayname="City" description="City"

valuetype=…

In the Identity Manager User Console the attribute appears as “City”, but that attribute is mapped to “l”, which is the actual attribute in the user data store.

LDAP User Data Stores

CA Identity Manager provides mappings to common directories and their objects. However, the proliferation of directory technology has led to more and more customers extending their directories with company-specific objects that might be useful for an identity management system. The wide use of directories requires that implementation teams have the skills to define how objects are stored and more importantly how they are referenced. The recommendations that follow assume some basic directory understanding and a desire to extend the product to make use of them.

In addition to the general considerations, consider the following items for an LDAP User Data Store:

■ Does the schema use any custom LDAP object classes for managed objects?


■ Are custom objects reflected in the objectclass attribute of the IMSManagedObject tag. For example:

<ImsManagedObject name="User" …

objectclass="top,person,organizationalperson,inetorgperson" … Does it use special container like “people” and ”groups” commonly seen in the early LDAP days?

Specify special containers such as these using the Container tag. For example:

<Container objectclass="top,organizationalUnit" attribute="ou" value="people" />

CONTAINERS

In LDAP terminology containers are organizational units. In a directory.xml, containers appear as part of the definition of a managed object. Consider the following example from a directory.xml file:

<ImsManagedObject name=”Group” description=”My Groups” objectclass=”top,groupOfUniqueNames” objecttype=”GROUP”> <Container objectclass=”top,organizationalUnit” attribute=”ou” value=”groups”/> </ImsManagedObject>

In the example, the group objects are stored under the container that has a relative DN of ou=groups. The container object is of the LDAP objectclass “top,OrganizationalUnit.” Here OrganizationalUnit is commonly known as an LDAP organizational unit (ou).

When a container is specified as a managed object, CA Identity Manager only lets you view and use entries of that object type inside the container and ignores all other entries. In the event that a directory is just being populated or does not have a container populated or defined in directory.xml, CA Identity Manager creates the container when the first entry is added. For example, when a user “joe” in the organization “Customers” is created from the CA Identity Manager user interface, CA Identity Manager first creates the container ou=people beneath ou=customers, and then creates the user object joe (uid=joe) in the LDAP user store. The DN of this user then becomes <root>, ou=customers, ou=people, uid=joe.

RDB User Data Stores

In organizations with large numbers of accounts in user data stores, you may want to consider partitioning data. Partitioning organizations within LDAP directories can be done easily with the help of the LDAP user search root in the user directory properties of the CA SiteMinder user interface. When using an RDB data store, we rely on the filter feature in the directory.xml.

Suppose you have an RDB user store in the same RDB that is used by your company applications. There are 1,000,000 users in the user table, but you only want the CA Identity Manager to manage 70,000 of them without having to use separate tables. There must be some criteria you can use to distinguish the 70,000 users from the 1,000,000 users.


To simplify the discussion, assume that you can distinguish the CA Identity Manager users from the non-Identity Manager users using a special column to keep a distinct organization identifier for the two separate sets of users as follows:

Users Table UserId FirstName LastName OrgId

John123 John Doe 1

Jane456 Jane Lee 2

Organizations Table OrgId OrgName

1 IDM

2 Other

In this example, the intent is to partition users who will be managed by CA Identity Manager into orgId=1 and other users into orgId=2. For example, John Doe has an OrgId value of 1 and Jane Lee has an OrgId value of 2. John Doe will be managed by CA Identity Manager while Jane Doe will not.

In this case, you can have an entry in the RDB directory.xml similar to:

<RootOrg value=”SELECT IM_ORG_ID FROM IM_ORGANIZATIONS WHERE IMSORGID=&APOS; 1&APOS;”>

This statement tells CA Identity Manager to specifically filter out and only manage the organizations where orgId=1. This also helps for performance reasons by removing users from consideration by CA Identity Manager.

eTrust Admin Server User Data Store and Provisioning Directory

eTrust Admin Server has an LDAP interface that you can use as an LDAP user data store. eTrust Admin Server is a flat user data store. A sample directory.xml for an eTrust Admin Server is provided with the directory templates that are installed as part of the CA Identity Manager Administrative Tools.

An eTrust Admin Server user data store is usually known and used as a provisioning directory but can be used as a regular user data store. A provisioning directory is an eTrust Admin Server that provides account provisioning support. We will explore provisioning directory in greater depth in the account management-related chapters.

Authentication Directories

A user data store that CA Identity Manager can use for authentication but cannot modify is called an authentication directory. For example, some implementations use Microsoft Active Directory as an authentication directory. There are many reasons for using authentication directories that depend on the unique needs of an enterprise.


Consider the friction created between projects within an organization. One group in an organization may be required to use a user data store that is owned or managed by a separate group in the same organization. The first group may have read-only access to the user data store.

For example, CA SiteMinder has a large install base on the Internet. Many large businesses with millions of customers are using CA SiteMinder to help protect their Web applications. As these organizations start implementing CA Identity Manager, they question whether and how the new project can benefit from the existing SiteMinder infrastructure. At the same time, organizations want to ensure that introducing these new projects does not cause support complications to their existing applications. Likewise, many global businesses have built their employee-supporting systems using Microsoft Active Directory technology. These organizations ask whether CA Identity Manager can use the existing authentication infrastructure and at the same time not change the Microsoft schema, and so on.

One way to support an authentication directory is to use it as an authentication data store and supply your own data store as the real identity user data store. In this case, you may decide to ignore the password aspects of the identity as your real user data store is an independent copy of the authentication directory. Or, you can review the CA Identity Manager account management features to see if they can push the password back to your authentication directory.

To supply your real identity data store, you can create one with the exact same structure as the authentication directory or create a different one and rely on the CA SiteMinder authentication/authorization directory mapping technologies to give you the freedom of using a different structure on your identity management system. When you create your own user data store, you can provide your own attributes to support many CA Identity Manager features. See the CA SiteMinder documentation for more information on how to map directories.

Secure Management Console Using the Built-In CA SiteMinder

New CA Identity Manager administrators may be surprised to learn that after the installation, the Identity Manager Management Console is not secured by default. With knowledge of the appropriate server name, unauthorized users can connect to the console and reconfigure it or damage it. The installation documentation for CA Identity Manager instructs administrators to take advantage of CA SiteMinder for access control. Many CA customers already have a CA SiteMinder implementation to protect their Web applications when they install CA Identity Manager. Therefore, we recommend that you configure the Identity Manager Management Console for access control through CA SiteMinder as documented in the CA Identity Manager Installation Guide for your application server platform.

For a standalone CA Identity Manager implementation, there is no identity to manage or protect immediately after the base installation. Therefore, there is no way to secure the Management Console. At this early stage, there is also no data to be secured. After the first Identity Manager Directory is defined, we recommend that you quickly use CA SiteMinder to secure the Management Console.


Our user data store is actually managed by CA SiteMinder. After an Identity Manager Directory is defined through the Identity Manager Management Console, it becomes a directory in CA SiteMinder, which you can use to secure the Management Console. Also, you may need to use the CA SiteMinder user interface to perform certain advanced configurations, including fail over and load balancing.

Identity Manager Environments

The objects of a user data store are actually managed through an Identity Manager Environment (IME). Before we go further into the discussion of an IME, we first want to emphasize that a company might have different types of identities to manage.

Identity Populations

Some commonly seen identity populations are employees, vendors, and customers. These identities may have some common attributes, but what actually sets them apart are their own special attributes. To manage this data, ideally we would store it in different tables using a relational database or in different object classes derived from the same base object class using LDAP.

Even though different tables can be stored in the same database and different object classes can be located in the same LDAP directory information tree, it can create unnecessary complications to try to design an identity management system that manages all three sets of objects in the same system. Using CA Identity Manager, we need to use different directory.xml files to describe each of the user data stores. We can create a different IME to provide a different set of business logic for each of the identity populations. Additionally, you can use different directory.xml files to create different views of the same database or even the same object.

Note: Throughout this book, we use the directory.xml files discussed in Appendix D to construct examples for the three identity populations. To make it easy for you to attempt these examples on your own, we will build our examples based on the fictional NeteAuto Company that has been included as part of the CA Identity Manager installation. However, we use different directory.xml files to create different views of the same user data store.

Multiple IMEs and User Data Stores

A single CA Identity Manager Application Server can be configured to have multiple IMEs. These IMEs can share the same user data store or have their own. The same physical user data store can be used multiple times on different application servers and it can even have different logical views described with different directory.xml files.

To create an Identity Manager Directory, you need an identity:

■ Administrator Credential: an ID that has administrator privileges over the user data store.


Creating an Identity Manager Environment

To create a basic Identity Manager Environment, you need at least an Identity Manager Directory and the following system identities:

■ Public User: an ID that is used for publicly accessible services.

■ System Manager: the administrative ID that can initially own all objects of an Identity Manager Environment.

A provisioning directory is the concept of connecting the eTrust Admin infrastructure to CA Identity Manager. This has many distinct advantages, but may not be required in all cases. Provisioning directories are further explored in the chapters related to Account Management.

During the creation of an Identity Management Environment, you are asked to decide what to do with Identity Manager roles in the following screen:

For your first IME or a test system, you may start with the “default roles.” For a production Identity Management Environment, you may also have your own file known as a RoleDefintion.xml file. For more information about roles, see the "Delegated Identity Management" chapter.

Sample Identity Manager Environments

Most of the examples in this book use the fictional company NeteAuto, a large multi-franchise automobile dealer. There are three types of users being managed by CA Identity Manager: employees, customers and vendors.

We use three IMEs to illustrate the use cases throughout this book. The three environments, one for each of the identity populations, share the same physical user data store while having their own views into the same LDAP directory.

The user data store in the examples originated from the sample NeteAuto Organization LDAP included in the installation of the CA Identity Manager Administrative Tools. To minimize your work when trying to follow this book, we decided not to create special LDAP object classes for the three types of identities. Instead, we chose to use the existing object classes and overload some of the attributes with different meanings through the corresponding directory.xml. This user data store can be created on the embedded eTrust


Directory that comes with the CA Identity Manager using the instructions provided in Appendix C.

Note: The ou=Customer does not exist in the out-of-box NeteAuto Organization installation. The instructions given in Appendix B along with the ldif file included in the zip file that accompanies this book will allow you to create this ou.

Sample NeteAuto Directory Information Tree

The relevant high-level directory information tree (DIT) of the NeteAuto LDAP is:

ou=NeteAuto,dc=security,dc=com

ou=Customer

ou=Employee

ou=Vendor

Note: The ou=Customer does not exist in the out-of-box NeteAuto Organization installation. You can easily add it in once the LDAP directory is up. More information on how to create the sample NeteAuto LDAP directory is located in Appendix A. o

Identity Manager Directory Level Security

For the three IMEs, the Employee IME manages objects in the ou=Employee organization unit; the Customer IME manages the ou=Customer; and the Vendor IME manages the ou=Supplier. Note that we chose to use ou=Supplier instead of ou=Vendor. This was simply because the out-of-the-box NeteAuto example had this organization unit created already.

The sample directory.xml files provided in the zip file that accompanies this book actually use the same “NeteAuto Administrator” user DN for all three Identity Manager Directories. This means that you can actually modify user objects in the other IMEs from any of the IME using the business logic in that IME. For example, if any mistakes are made in the design of the Customer IME, you can accidentally modify an employee object using the Customer IME business logic.

The security scenario indicated here is not commonly seen. We want to point out these possibilities simply because we chose to demonstrate CA Identity Manager’s capability to support a Multi-Tenancy implementation. Depending on your security requirements, you may consider enhancing your implementation at the user directory level instead of completely relying on the correct logic at the IME level. For example, using eTrust Directory to build the NeteAuto LDAP directory, you can use the access control mechanism to create four different IDs: one ID can modify all parts of the whole DIT; the other three IDs have only partial privileges to their respective parts of the DIT. Alternatively, you can use eTrust Directory to set up a more complex scheme like using a read-only DSA to completely block out the update attempts as appropriate. Such complex configurations are beyond the scope of this document. See the eTrust Directory documentation on how these can be configured.


Employee IME

Our use cases start with an Employee Identity Management system for the fictional car dealership, NeteAuto. NeteAuto wants to gain more control over their employee identity information. Current processes for updating an employee's personal information are clumsy and require the intervention of back office employees. Managers have a hard time viewing their employees' information, even something as simple as a cell phone number. Password management is also a problem.

With the authority concept in mind, NeteAuto wants their employees to have the authority to do the following:

■ Update only their own cell phone numbers as individuals change cell phone numbers often, thereby saving time, and ensuring accuracy

■ Manage and reset their own passwords but still ensure those passwords meet corporate password policies.

NeteAuto wants managers to manage the passwords of their employees.

The NeteAuto managers want to view the personal information of employees, but the security organization wants these managers to see only the information for their direct reports.

To get the required functionality, NeteAuto has decided to create an Employee Identity Management System.

To create an employee IME on the system that is designated for it, you first define the Identity Manager Directory using the employee-Directory.xml file included in the zip file that accompanies this book. This file has been configured in such a way that an Identity Manager Directory “employee” will be created and you only need to specify your machine name and port number where the NeteAuto LDAP directory is running (3895 is the default port) and the password for the User DN ("test" is the default password):

“UID=NeteAuto

Administrator,ou=People,ou=Employee,ou=NeteAuto,dc=security,dc=com”

Note that the default passwords used for our sample environments are given in Appendix C. You should always change them according to your own security policies.


Next, you define the Identity Manager Environment using the newly created “employee” Identity Manager Directory and the sample employee-RoleDefitions.xml file in Appendix C. This xml file helps define the sample Admin Roles and Admin Tasks we need for the examples in this book.

Customer IME

As a business that sells cars of all makes directly to the customers, NeteAuto wants to create a Web site designed for their customers as part of a customer service offering. They want their customers to have the authority to do the following:

■ Update their personal information to make it easier to keep in contact with them

■ Subscribe to areas of interest

■ Manage their own passwords

In case customers have difficulty resetting their passwords, NeteAuto wants passwords to be managed by certain customer service representatives in the NeteAuto organization. To provide these personalized services to their customers, NeteAuto decides to set up a Customer Identity Management System to help provide the supporting infrastructure.

To create the customer IME on the machine that is designated for it, you first define the Identity Manager Directory using the customer-Directory.xml file. This file has been configured in such a way that an Identity Manager Directory “customer” will be created and you only need to specify your machine name where the NeteAuto LDAP directory is running and the port number (3895 as a default) and the password (default test) for the User DN:


“UID=NeteAuto


Note that we purposely use the same User DN as of the employee Identity Manager Directory. The choice for this DN needs to consider your specific security policies and requirements. In general, we recommend using a DN that does not live in the same container as the other regular customer objects as this is a critical identity. Having this identity resides in other part of the trees makes many managing aspects of the IME a lot easier.

Next, you create the Identity Manager Environment using the newly created “customer” Identity Manager Directory and the sample customer-RoleDefintions.xml that helps define the sample Admin Roles and Admin Tasks we need for this book.

Vendor IME

Like many large organizations, NeteAuto works with many suppliers. To help reduce the cost, NeteAuto works with their vendors on many fronts. Occasionally, vendors may come to visit NeteAuto headquarters for various business reasons. NeteAuto wants to use a Vendor Identity Management system to provide the infrastructure needed to continue to improve the security aspects of allowing the vendors to come to their facilities.

Currently, vendors arrive unannounced and stay for an unknown period of time. Sometimes the employee the vendor needs to see is not there, wasting the vendor's time and the company has no record of the visit. Calls come in for the vendors and the switchboard does not know the location of the vendors.

By implementing the new system, each time a vendor wants to visit NeteAuto, they will contact the NeteAuto employee they need to visit and that employee will use Vendor Visit Registration Service to register the date and length of the intended visit. The Vendor Receptionist will help visitors check in and out. With the new system, a record of each visit


is available and NeteAuto knows which vendors are in the building and who they are visiting.

To create the vendor IME on the machine that is designated for it, you first define the Identity Manager Directory using the vendor-Directory.xml file listed in Appendix B. This file has been configured in such a way that an Identity Manager Directory “vendor” will be created and you only need to specify your machine name where the NeteAuto LDAP directory is running and the port number (3895 as a default) and the password (default test) for the User DN:

“UID=NeteAuto


Note that we purposely use the same User DN as of the employee Identity Manager Directory. The choice for this DN needs to consider your specific security policies and requirements. In general, we recommend using a DN that does not live in the same container as the other regular customer objects as this is a critical identity. Having this identity resides in other part of the trees makes many managing aspects of the IME a lot easier.

Next, you create the Identity Manager Environment using the newly created “vendor” Identity Manager Directory and the vendor-RoleDefintions.xml file in Appendix C that helps define the sample Admin Roles and Admin Tasks we need for this book.

For the high-level instructions on how to build the three sample IMEs, see Appendix B.

With the three IMEs created, we are now ready to go into the six categories of the identity management services.


Chapter 3 : Delegated Identity Management In this chapter we explore the two main components of CA Identity Manager: identity management and account management. Within each component, there are delegated management and self service components.

Before we discuss working with our Identity Manager Environment (IME), we first cover the password management aspects of CA Identity Manager.

After password management we discuss Admin Tasks, Admin Roles, and CA Identity Manager's sophisticated delegated administration capability. Many of the concepts introduced here also apply to other CA Identity Manager topics explored in the rest of this book.

Note: The authentication to our IMEs is handled by CA SiteMinder.

We also re-emphasize the authority concept because it is essential to identity management systems.

Finally, we discuss the commonly seen delegated services in the identity management domain in detail including:

■ Delegation System Management Services

■ Backend Authorities

■ Identity Object Authorities

■ Help Desk Assisted Services

■ Supervisor Assisted Services

■ Supervisor Delegation Assisted Services

These discussions are followed by examples implemented on our three sample IMEs.

Password Management

Passwords are a user's primary method of authentication in most IT systems. They are also a primary problem for the following reasons:

■ Users forget their passwords

■ Users write passwords on pieces of paper and store them in unsecured places

34 Delegated Identity Management

■ Users use the same password on every system

■ Users use well-known passwords like "secret," "password," "letmein," and so on

An identity management system must manage passwords as well as the identities, and it must allow the administrators to create and enforce corporate password policies. Corporate password policies usually carry the undesirable side-effect of more forgotten or expired passwords. Industry data shows that the number one incident reported to Help Desks is forgotten passwords. Therefore, any identity management system must provide a way for users to reset or recover their passwords.

Password Policies

A password policy is a set of rules and restrictions that determines how passwords are created and when they expire to help reduce the possibility that the passwords become compromised. In a password policy, you can configure the following settings:

■ Password expiration--Define events that cause a password to expire, such as a number of days elapsing or a number of failed login attempts. When a password expires, the user account is disabled.

■ Password composition--Specify the content requirements for new passwords. For example, you can configure settings that require users to create passwords that are at least eight characters long and contain a number and a letter.

■ Regular expressions--Provide an expression that determines the format of a valid password. You can specify whether passwords must match or must not match that format.

■ Password restrictions--Set limits on password reuse. For example, users must wait 90 days before reusing a password.

■ Advanced password options--Specify actions that CA Identity Manager should take, such as making passwords lower case, before processing a password. You can also specify the priority of a password policy, if multiple password policies apply.

While a password policy seems to apply to an IME as you configure it in an Identity Manager User Console, the policy actually applies to the user store associated with the environment. This is because CA SiteMinder actually enforces the policy. If a user directory is associated with multiple environments on the same policy server, a password policy defined in one environment can apply in other environments, as well. As a result, we advise you to explicitly set the correct filter when defining Password Policies within each IME.

Password Policies Planning Considerations

Password planning activities include investigating the current password policies for all users and determining how you can implement them using CA Identity Manager. Different user populations within an organization might have different policies. This form of delegated administration enables some parts of an organization to use weaker password policies while


others require stronger ones. For example a low risk business application may only require users to change their password every 60 days and have any length password, where the IT department with its strategic access to all resources may want a very strong password that changes every 30 days. CA Identity Manager supports this form of delegated administration. Remember that making password policies difficult for an end user to follow will likely cause more forgotten or expired passwords and increased use of sticky notes with passwords written on them.

Delegated Administration

Delegation is the core of CA Identity Manager. CA Identity Manager uses its delegated role administration model to help manage identity objects, account objects, and other system objects.

Delegated role administration helps you model how your computer system is being accessed. It is designed for you to categorize the types of users or roles and how these roles access your resources. After you build the model, you must link individuals to the roles. Instead of a pure manual process, CA Identity Manager uses rules that are based on user’s attributes to provide automatic role assignment and delegation actions that change user’s attributes to provide manual role delegation.

The rules are used extensively in CA Identity Manager on identity management objects, account management objects and other system management objects. In this section we discuss the Admin Tasks and Admin Roles that are used to control what an administrator can do in an IME.

Role-Based Access Control

Historically, the US DoD introduced the Trusted Computer Security Evaluation Criteria, DOD 5200.28-STD in 1985. For a long period after that, it was perceived that Mandatory Access Controls (MAC) were appropriate for multilevel secure military applications while Discretionary Access Controls (DAC) were often perceived as meeting the security processing needs of industry and civilian government. In 1992, D.F. Ferraiolo and D.R. Kuhn published their original "Role Based Access Control" paper at the 15th National Computer Security Conference and argued that Role-Based Access Control (RBAC), http://csrc.nist.gov/rbac/ http://csrc.nist.gov/rbac/, can be more appropriate and central to the secure processing needs within industry and civilian governments than DAC, although the need for DAC will continue to exist. Since then, RBAC has been adopted by the American National Standards Institute, and the International Committee for Information Technology Standards (ANSI/INCITS) as ANSI INCITS 359-2004.

The basic concept of RBAC is that users are assigned to roles and access rights are assigned to roles. This way, users are not granted access rights directly, but rather acquire those rights based on the roles they fill in the organization. As one's role in the organization changes, the rights change. For example, a department manager generates purchase orders and needs full access to a financial application. Other users need access only to the function for viewing purchase orders. When an individual is promoted to the department manager, the new role grants full access rights to the financial application to the individual.

http://csrc.nist.gov/rbac/


ROLE ENGINEERING

In an organization with a heterogeneous IT infrastructure and requirements that span dozens or hundreds of systems and applications, the assigning of the access rights to the roles (role engineering), can become extremely complex. Role engineering can be performed using a bottom-up or a top-down approach.

Bottom-up role engineering is based on performing role-mining, which is done by exploring existing role definitions in current applications and systems, and then doing role normalization and rationalization. Under this model, roles have been defined to meet specific application or system access requirements.

Top-down role engineering is based on reviewing organizational business and job functions and mapping permissions for each function to create a role. This approach provides business oversight and alignment of a role with business functions and reusability. When a new system is deployed, roles are assigned from a common pool that is already defined. A hybrid model that combines both approaches leverages normalized roles and aligns them to job functions.

ADMIN ROLE, ACCESS ROLE, PROVISIONING ROLE, AND OTHERS

CA Identity Manager offers three types of roles: Admin, Access, and Provisioning. The Admin role is used to determine what a user can do when accessing an IME. The Access role was originally designed to offer the same RBAC security management capabilities found in CA SiteMinder. However, we have seen implementations that use it as a special attribute that an identity can possess and then develop other policies that depend on it. The Provisioning role is designed for account provisioning purposes. More details about these three roles are explored later: Admin role in “Delegated Identity Management” and “Identity Self Service”; Access role in “Web Application Authorization”; Provisioning role in “Delegated Account Management” and “Account Self Services.”

MEMBER, ADMINISTRATOR, AND OWNER

CA Identity Manager uses three concepts to help manage the relationships between identities and roles. An identity can be a member, administrator, and/or owner of any of the three types of roles.

Being a member of an Admin Role allows the individuals to execute the designated tasks with the specific scope of influences on the IME. Being a member of an Access Role gives the individual the status to be used just as another attribute of the individual or to be used by the SiteMinder Policy Server for other authorization purposes. Being a member of a Provisioning Role provides the individual the opportunity to acquire real computer accounts and the privileges to which the provisioning role is entitled.

A role is assigned to an identity by making the identity a member of that role. To assign an identity to a role, the user who performs the task must be an administrator of that role. An administrator may sometimes have the privileges to delegate the administrator privileges to


others. The administrators can be limited to a set of identities they are allowed to manage through scope rules.

The owners of a role have the privileges to change the definitions of those roles including the rules that determine role membership.

EXCEPTIONS AND OTHER OBJECTS

Provisioning Roles do not have member rules. Further details are discussed in the “Delegated Account Management” chapter. The Identity Policy objects discussed in “Identity Policies and Automation” are system objects that have only owner rules.

RULES AND DELEGATION ACTIONS

CA Identity Manager uses rules to determine whether a user is a member, an administrator, and/or an owner of a role. The rules can use most of the attributes an identity possesses, and are not limited to the usual ID value and group membership. For more details, see the “Role Planning” section of the CA Identity Manager Operation Guide.

The following screen shows the possible expressions a rule can use.

Further, this means that a user is a member, an administrator, and/or an owner of an object because the user satisfies one or more of these rules. To change the relationship between an identity and another object, many security systems choose to rely on joining the user to concepts similar to groups or adding the user directly to the Access Control Lists (ACLs). CA Identity Manager supports these concepts. What sets it apart is that instead of changing other objects like groups and ACLs, CA Identity Manager changes the users directly to fit the rules by using the Add or Remove delegation actions as shown in the following screen:


Possible actions are displayed.

The action rule builder intelligently suggests certain actions like the:

Add “CIM Customer System Manager” to Admin roles

This facility makes the delegation of tasks possible for users with little technical skill.

SCOPE RULES

To enhance CA Identity Manager's delegation capabilities, it provides scope rules to further limit the objects on which users can act, and to define the set of objects on which users can perform tasks.

The scope rules that can be used to limit the objects a member can manage are shown in the following screen:

Other scope rules can limit the privileges an administrator can pass onto a role member or administrator.

By using yet another powerful feature inside the filters, you can compare the attributes of the objects the user is trying to work on with their own (admin's) attributes. With this feature, you can set the scope like “people who work together”, “people who work for the admin”, “people who have the same interest”, …, and so on.

For more details, see the “Role Planning” section of the CA Identity Manager Operations Guide.


USAGE BEST PRACTICES

CA Identity Manager rules are very expressive and flexible. You can create rules that use any of the user's attributes. For example, consider the following rule:

in ( Organization "Employee" and lower )

It can be rather difficult to create the corresponding Add and Remove delegation actions.

You can use any other attributes that are available and to simplify the creation of Add and Remove rules. However, to help simplify the design of rules and delegation actions, we suggest that instead of using user attributes of your own choice, you use the special attribute known as “Admin roles” to construct a rule that uses delegation actions. For example, if you have a rule like:

where ( Admin roles = "Customer Certification Manager" )

The Add and Remove delegation actions are as follows:

Add “Customer Certification Manager” to Admin roles

Remove “Customer Certification Manager” from Admin roles

To find a good value for “Admin roles,” we suggest you use the name of the role being constructed and append some descriptive text to it to clarify how the attribute should be used. For example, the Delegation Actions can exist for the same role on both member and administrator rules, therefore we append the word “Admin” to the role name when we construct the Delegation Actions for the Administrator rule.

Admin Task

CA Identity Manager administrators use Admin Tasks to perform system administrative functions. They obtain the privileges to exercise these Admin Tasks by being members of Admin Roles.

An Admin Task defines administrative functions including how to represent the task in the Identity Manager user interface. It is the smallest unit of action that can be given to the user. Admin roles further identify the objects the user can apply the actions to. For example, an Admin task may allow an individual to reset another's password. An Admin role determines who the reset password function can apply to. The combination of the two gives CA Identity Manager a powerful mechanism to use a single Admin role that gives all supervisors the privileges to reset only their employees' passwords.


ADMIN TASK PROFILE TAB

The following screen shows the Profile Tab during the creation of an Admin Task:

See the CA Identity Manager Operations Guide for further details. Here we highlight a few important points within this context.

The possible Primary Objects are:

■ Access Role

■ Admin Role

■ Admin Task

■ Group

■ Identity Policy Set

■ Logical Attribute Handler

■ None

■ Organization


■ Password Policy

■ Provisioning Policy

■ Provisioning Role

■ User

The Scope Rule discussed previously applies to the relevant combinations of the Primary Object and Actions selected.

ADMIN TASK SCOPE TAB

On the Scope tab, you define the task scope using the Search Screen to set limitations on the objects available to the task. For example, if the object is users, you might define the scope as the users who are employees. See the Admin Task Section in the CA Identity Manager Operations Guide for details and note the following:

■ If the task has no primary object, or if the action is self-modify, self-view, or approve, then the Scope tab is not applicable.

■ Some of the primary objects also have the Search Option to allow you specify some commonly used filters. For example, the Admin Role object allows you to specify whether you want to see all roles, all roles for which the user is an administrator, or all roles for which the user is an owner.

■ Some primary objects have the “Modified objects must remain in administrator's scope” option. When this is selected, it causes an error if the administrator would lose scope over the modified object by submitting the task.

■ You can also define user, group and organization scope rules in an Admin Role to limit the objects that can be managed by an admin role member, administrator, or owner.

ADMIN TASK TAB

The Admin Task tab is where you design and specify the GUI presentation of the Admin task. Different primary objects have different sets of tabs to choose from. CA Identity Manager provides an interface directly on the Web Browser where you define the on-screen representation of a task. For example the following screen shows you the possibilities of what you can do with a field:


Admin Role

An Admin role is a container of administrative functions that a CA Identity Manager user can perform. It is a grouping concept that simplifies administration by collecting appropriate Admin Tasks into a logical container that you can assign to a user. This model ensures that as users change jobs or functions, an administrator does not need to remember several tasks that the user was doing and now will require in his new job. The administrator simply removes the old role from the user and adds the role for the new job function to the user.

Further, by automating the process you avoid a common administrative pitfall. When an employee changes positions, it is easy to grant them the new access permissions they need for their new job. The employees and their supervisors make sure that those authorities are granted so the employee is productive right away. There is often less urgency to remove the access permissions they no longer need. Often employees just accumulate permissions for their entire career. This is a sure way to fail a security audit.

To define an Admin role, you select the Admin Tasks to be included from the Tasks tab and further determine the settings for the Members, Administrators, and Owners tabs, see Role Base Access Control discussed previously for more information.


The Enabled check box lets you disable or enable Admin Roles that have been defined. For example, some implementations concerned about preserving the sample out-of-box Admin Roles and Tasks choose to retain these roles by checking disable, rather than deleting them. However, we suggest that you remove them from your production environment and use a process similar to the one described in the “Create Portable RoleDefinition XML” section in Appendix D to move the necessary definitions from the test/development environment to production.

SCOPE CONFLICTS AND PRIMARY ADMIN ROLES

From the earlier Admin Task discussion, you see that an Admin Task is associated with a Primary Object type like “User,” “Group,” “Organization,” and “Admin Tasks.” We also see the Scope Rules that limit which objects the Admin Task can act upon are actually given at the Admin Role level. As a result, you may sometimes run into scope conflicts between different Admin Tasks that are being assigned to the Admin Role. For example, an administrator may be given read-only privileges to a set of users, while they are given the modify privileges to a different set of users. When this happens, you simply cannot add the two Admin Tasks to the same Admin Role and have to create additional Admin Roles to accommodate the extra Admin Tasks. If these Admin Roles are always assigned to the same set of users to allow them to perform the desired business function, then you may want to consider designating one of them as the “Primary Admin Role” and give the others a Member Rule like the following:

who are members of ( admin role “AdminRoleName”)

with the designated Primary Admin Role in place of the AdminRoleName.

Note that the “Primary Admin Role” is not an official CA Identity Manager concept and carries no special meaning. It is just a simple concept introduced by the authors to help you engineer and organize your roles.

Identity Populations, Management, and Authority

For most identity management systems and their populations, there is rarely a single authority that is capable of owning every attribute of an identity. Keeping the authority concept in mind can help answer many design questions posed by the three sample IMEs presented in this book.

Authority

Different identity populations have different authoritative systems. Within a corporation, the human resource system tends to own a lot of employee-related information even though most of the information is actually owned by the employee. For example, employees own their names.

To change the information on the identity management system, you might want the individuals to go through human resources first and then use the human resource system records to update the same on your identity management system. This means that the


individuals sometimes have no direct authority over their own personal information. On the other hand, if individuals are expected to use passwords to prove they are who they claim to be, then the system should allow them to change their own passwords. It should also block any attempt to retrieve those passwords in formats that allow others to impersonate those individuals.

A customer identity management system usually gives the customers a lot of authority over their own information. Only information similar to membership level and other business-related information are owned by business applications.

An identity management implementation for vendors can vary depending on the relationship between the company and its vendors, ranging from the extreme where the vendor is the center of the business model (maybe a franchise) to the model where a vendor receives very limited access (an occasional or backup supplier). An application that allows a vendor organization to administer their sales force on your vendor identity management system might give the vendor a lot of authority compared to a vendor identity management system that is used for employees to register the vendors for onsite visiting purposes. In this book, we intend to build a very minimal vendor identity management system just to show you that even with a limited system, you can still get value.

Delegation

Individuals are not always available to do their assigned work. Delegation lets individuals share some of their authorities with others temporarily or permanently. Delegation also includes whether the delegate is authorized to further delegate the authority to someone else. For example, when an IME is newly created, there is a single identity known as the System Manager who owns all objects in the IME. For a production IME, you might want to delegate all or part of the privileges to others who act as Sub-System Managers and allow them to delegate their authorities to provide adequate support and services.

Request and Approval

Centralized administrative authorities within an enterprise cannot determine all of the needs of a business independently. In a production environment, you can never fully anticipate all of the needs your identity populations may have. Sometimes, your system needs to have a manageable mechanism to allow users to request what they think they need and to allow an authority to approve and grant the request.

GRANT-BY-DEFAULT

So far, the authoritative system is considered as Grant-By-Default. The system determines the authoritative natures of the parties involved through the delegated roles and allows them to change the information directly on the system. Most systems start with this concept.


GRANT-BY-REQUEST

Sometimes, you may find yourself in a situation where you want to package a number of privileges and resources together and allow people to make a request and obtain them automatically. This is known as a grant-by-request system.

GRANT-BY-APPROVAL

CA Identity Manager also supports the grant-by-approval system where an operation is attempted and the system determines whether any approvals for the operation are required. It then automatically guides the request through the approval process until the attempted operation is approved or denied.

The approval process can be configured and even customized through the embedded WorkPoint workflow engine. Since workflow involves business processes, we do not intend to elaborate much about the topic in this book. Other than some details given in Appendix H, we only provide a simplified example in Chapter 8 during the discussion of using an identity policy to execute employee self service requests.

Backend Authority Services

Once an Identity Manager Environment is defined, you must restart the Identity Manager Application Server. You are now ready to use the system.

The first question is how to populate the user data store with the objects the system is intended to manage. You might have inherited the user data store from an existing project. You might have the luxury of creating a brand new user data store. Or, you might have to share the user data store with someone else. In any case, your first task is to identify all systems associated with your user data store from the backend and clearly define the authorities of each of these backend systems if they exist.

The Identity Policy feature of CA Identity Manager (described in chapter 8) provides rule-based polices that can be applied to user data for enforcement of business rules and compliance. This feature is bypassed when user data is entered or modified outside of Identity Manager like many of the traditional backend systems do. To address this concern, you have the choice of locating and modifying these backend authorities to accommodate the same business rules that are put in place through the Identity Policies and having to change them every time the Identity Policies are changed. Alternatively, you can consider modifying your backend authorities once using TEWS Web Services tools similar to the one shown in Appendix I to create, modify, and delete any of the objects that are involved. Data fed through the TEWS interface are subject to Identity Policies.

Delegated Identity Management Services

To increase productivity, we build an identity management system that has its infrastructure centrally supported while its services are managed in a distributed fashion. The distribution is designed to help scale the solution to avoid unnecessary bottlenecks. To


avoid a breakdown of security, a delegation system that gives individuals appropriate privileges must be built.

The powerful rule based delegated role administration feature CA Identity Manager allows you to build a sophisticated delegation system. The following list of delegated administrative services is commonly used to address the identity management need:

■ Delegation System Management Services

■ Backend Authorities

■ Identity Object Authorities

■ Help Desk Assisted Services

■ Supervisor Assisted Services

■ Supervisor Delegation Assisted Services

Delegation System Management Services

The initial identity management system must allow authorized system administrators to maintain the delegation system. The delegation system objects in CA Identity Manager consist of the Admin Roles and Admin Tasks.

CA Identity Manager uses two main Web interfaces. The first interface is the Identity Manager Management Console. Both Identity Manager Directories and IMEs are created and maintained on this interface. The second interface is the Identity Manager User Console, which most people use to access the identity management system.

DELEGATED SYSTEM MANAGER

The first user who is allowed to access the newly created IME is known as the System Manager. This user ID has the System Manager Admin Role and tends to have all possible system access. We highly recommend that you immediately create a Delegated System Manager Admin Role with the same privileges and assign real users to this new role to handle the overall Delegation System Management services.

MULTI-TENANCY ENVIRONMENT DELEGATION

In the “Identity Population” topic, we discussed setting up three identity management systems, employee, customer, and vendor. It is possible and actually preferred that the three systems are integrated from the employee identity management point of view to allow an authorized employee to actually manage the other two systems. An environment like this is sometimes known as a Multi-Tenancy environment. In this multi-tenancy environment, an employee who signs onto the employee identity management system might also have certain privileges on the other two systems. The challenge is how to manage their delegated privileges on each of these systems.


We suggest that users are not permitted to modify their identities' attributes outside of their own systems to ensure data integrity as described in the “Identity Manager Directory and Authority” section. This means that the delegated roles employees have over the other two systems must be assigned through the employee identity management system, while the actual privileges received are separately managed on the systems where they work.

Backend Authorities

After the Delegated System Manager is established, link the backend authorities identified before this section back to the identity management system. These backend systems are determined primarily by the authorities they hold against the attributes of the objects in the identity management system.

Backend systems tend to have human counterparts as it is logical to set up the same capabilities for humans to verify whether the automated backend systems are actually functioning as designed. For example, there may be a Human Resource backend system that is periodically feeding data into an employee identity management system. To confirm the system is functioning properly, you might allow a Human Resource representative to do a similar job to confirm that the automatic system is functioning properly.

The rest of this section provides you with examples of the types of backend systems that you should consider in your enterprise.

Identity Objects Authorities

Users, groups, and organizations (identity objects) that describe the employees in an identity management system tend to be associated with a business function like Human Resources, which has a strong influence over the users (identities) and organizations in an enterprise. The identity objects for a customer identity management system can vary. The customers can be online self-registered guests or ones from other business activities. The identity objects for a vendor identity management system can be derived from a vendor relation business function or some level of vendor self-service in the identity management system.

Groups are typically owned by IT as they are usually used for the purpose of supporting other computer applications.

Help Desk Assisted Services

On your initial employee identity management system, you may have a smaller user population that includes those mentioned earlier. After you put the system in production, you might also need to offer a help desk assisted service of some sort to help address the needs of your users. The most common needs for a Help Desk include:

■ Enable/Disable Users

■ Entitlement Viewing Support

■ Password Reset


The Enable/Disable Users service is to help the users temporarily disable their access or to enable their access in case their access has been disabled for some reason. The Entitlement Viewing Support service used by Help Desk helps answer the questions of why certain things do not work. Also, there is the reliable Password Reset service Help Desk offers when users forget their passwords.

HELP DESK AUTHENTICATION

The very foundation for any kind of Help Desk assistance is based on the idea that the helper can authenticate or verify the caller's identity.

How does a Help Desk authenticate individuals? To answer this question, you can rely on the three commonly accepted authentication means:

■ Something the user knows

■ Something the user has

■ Something the user is

If the individual is calling in for help, the most likely method for establishing an identity is “Something the user knows.” This means that the identity management system must hold this type of information to allow the help desk to conduct the authentication. And then the question becomes whether the answers to the authentication questions are supposed to be visible to the help desk personnel.

Some real world implementations actually take another step to distinguish the questions and answers a help desk can ask to authenticate users. In these systems, individuals authenticate themselves. For more information see the "Identity Self Service" chapter later in this book.

Supervisor Assisted Services

Supervisor is the term that refers to the direct manager of an employee. For a large complex environment, setting up a dedicated Help Desk service can be expensive. The idea of using the supervisors to help their employees is appropriate. These are known as Supervisor Assisted Services. These services help distribute the demand to the Help Desk in a large environment. From the authentication point of view, the supervisor assisted services tend to be more reliable because of the existing working relationship between the supervisors and their employees.

Supervisor Delegation Assisted Services

In this busy world, people are simply not available all the time. It is common that supervisors may want to delegate some of their duties to their direct reports for various reasons. For an identity management system, a supervisor might delegate an administrative assistant to help reset the team members' passwords.


Sample Delegated Identity Management Services

Our sample implementation of the three IMEs is a Multi-Tenancy implementation where we share the same user data store. We start the discussion on the Customer IME and Vendor IME before moving onto the Employee IME. If you have no immediate interest in these types of implementations, you can skip to the Employee IME.

To highlight, employees can sign onto all three IMEs using the same ID and password and are given different sets of privileges based on the environment they are in. Single sign-on to the three environments is also possible, which is described in Chapter 5, “Web Application Authorization.”

Most importantly, the Delegated Administration Role an employee has is managed from the Employee IME and through simple coordination granted on each IME the employee connects to. Since each IME actually has different sets of identity objects, such as customer objects or employee objects, the actual entitlements must be separately managed on each IME.

Customer Delegated Identity Management Services

For the NeteAuto Customer Identity Management system, we provide the following services initially:

■ Customer Service Assisted Services that include:

> Password Reset

> Enable/Disable

> Customer Directory and Profile Update

■ Customer Special Interest Group Management

■ Customer Identity Management System Management

The Special Interest Group (SIG) is a service that allows customers to sign up for certain pre-determined SIGs and access online information once the Customer IME is open for the customers to use. See Chapter 3 “Identity Self Service” for more information about SIGs. The Customer Special Interest Group Management service is the administrative service to support SIGs.

Because of the recent identity theft and privacy concerns, NeteAuto wants to have a formal Customer Status Certification process established. Using this process, customers need to periodically meet certain certification criteria or their online access is disabled. More information about Certification is described in Chapter 8 “Identity Policies and Automation”.

The Customer Identity Management System Management is the delegated system management function that helps maintain the Customer IME with backup from the System Manager.


The “Customer Directory” is certainly a pre-requisite to many of the “Customer Service Assisted Services”.

SERVICE: CUSTOMER DIRECTORY AND PROFILE UPDATE

Customer Directory and Profile Update is a business tool the Customer Service Representative uses to help provide other services. The following screen shows the search feature of such a service:

SERVICE: CUSTOMER SERVICE ASSISTED PASSWORD RESET

Customer Service Assisted Password Reset service is a service that allows customers to call in and ask for assistance to reset their passwords.

SERVICE: CUSTOMER SERVICE ASSISTED ENABLE/DISABLE

Customer Service Assisted Password Reset service is a service that allows customers to call in and ask for assistance to help enable or disable their IDs.

SERVICE: CUSTOMER SERVICE ASSISTED SPECIAL INTEREST GROUP MEMBERSHIP

Customer Service Assisted SIG service is a service that allows customers to call in and ask for assistance to join the SIG membership.

SERVICE: CUSTOMER SPECIAL INTEREST GROUP MANAGEMENT

Customer Special Interest Group Management service helps maintain the customer special interest groups. Details are discussed in the “Web Application Authorization” chapter.


Customer Delegated Identity Management Roles

To provide these services, we have the following Admin Roles initially:

■ Customer Service Representative

■ Customer System Manager

ROLE: CIM CUSTOMER SERVICE REPRESENTATIVE

A Customer Service Representative's job function is to help provide the following services to the customers:

■ Enable/Disable the ID

■ Reset passwords

■ Certify customer status (discussed in Chapter 8)

The tasks a Customer Service Representative can perform are illustrated in the following screen:

Note: Since only employees are allowed to be Customer Service Representatives, we need Delegation Actions in the Employee IME to assign the “Admin roles” value to actually manage the delegation of this role to employees.

Member Rules

The member rules are as follows:

■ Anyone who has the “CIM Customer Service Representative” value in the multi-valued attribute “Admin roles.”

■ Scope Rules: User in ( organization "Customer" and lower ); Group in ( organization "Customer" and lower ); Organization none; Access none.

ROLE: CIM CUSTOMER SYSTEM MANAGER

Instead of using the System Manager role, we create a Customer System Manager role, which is a delegated System Manager. Customer System Managers help maintain the


Admin Roles/Admin Tasks information on the Customer IME with support from the System Manager. Customer System Managers actually own all customer-related Admin Roles. In addition, because the maintenance of the “Customer Special Interest Group Management” can be quite involved, we decided to have the Customer System Manager help perform that function.

The tasks a Customer System Manager can perform are illustrated in the following screen:

Notes:

■ Since only employees are allowed to be Customer System Managers, we need a Delegation Action in the Employee IME to assign the “Admin roles” value to actually manage the delegation of this role to employees.

■ Since Customer System Managers have a user scope of “Customer” organization and lower, they need help from the System Manager to help set the “Customer” organization user scope for the “Customer Service Representative”.

Member Rules


■ Anyone who has the “CIM Customer System Manager” value in the multi-value attribute “Admin Roles.”

■ Scope Rules: User in ( organization "Customer" and lower ); Group in ( organization "Customer" and lower ); Organization none; Access none.

ROLE: SYSTEM MANAGER

The System Manager for the Customer IME.


Note: System Manager owns two Admin Roles: “System Manager” and “CIM Customer System Manager.”

Member Rules


■ User ID = “SuperAdmin”

■ Scope Rules: User, Group, Organization, Access: all

Vendor Delegated Identity Management Services

For the NeteAuto Vendor Identity Management system, we provide the following services initially:

■ Vendor Organization Management

■ Vendor Visit Registration

■ Vendor Reception

■ Vendor Identity Management System Management

The Vendor Organization Management service allows the appropriate authorities to maintain vendor organization information in the system. The Vendor Visit Registration is used to register visitors for an existing organization. The Vendor Reception service manages vendors when they arrive at the NeteAuto facilities.

SERVICE: VENDOR ORGANIZATION MANAGEMENT

Vendor Organization Management service helps maintain the vendor organization information and basic vendor employee information for the Vendor Identity Management system.

SERVICE: VENDOR VISIT REGISTRATION

NeteAuto employees use the Vendor Visit Registration service to register visitors and specify the duration of the current visit. Visitors provide the following primary information for site visits:

■ First Name

■ Last Name

■ Email

■ Business Phone

■ Sponsor


■ Duration of Visit

SERVICE: VENDOR RECEPTION

The Vendor Reception service helps vendor visitors check-in and check-out when they arrive at the NeteAuto facilities as follows:

a

Vendor Delegated Identity Management Roles

To provide these services, we have the following Admin Roles initially:

■ Vendor Organization Manager

■ Vendor Visit Registrar

■ Vendor Receptionist

■ Vendor System Manager

ROLE: VIM VENDOR ORGANIZATION MANAGER

The VIM Vendor Organization Manager has full privileges to manage organizations under the Supplier organization tree. In addition to managing regular vendor information, the VIM Vendor Organization Manager can also maintain Vendor information.


The tasks a Vendor Organization Manager can perform are illustrated in the following screen:

Note: Since only employees are allowed to be Vendor Organization Managers, we need Delegation Actions in the Employee IME to assign the “Admin roles” value to actually manage the delegation of this role to employees.

Member Rules


■ Anyone who has the “VIM Vendor Organization Manager” value in the multi-value attribute “Admin roles.”

■ Scope Rules: User in ( organization "Supplier" and lower ); Group none; Organization in ( organization "Supplier" and lower ); Access none.

ROLE: VIM VENDOR VISIT REGISTRAR

The VIM Vendor Visit Registrar is given the privilege to create and update the vendor visitor information in the system, including sponsors for vendors and the scheduled duration of the visit.

The tasks a Vendor Visit Registrar can perform are illustrated in the following screen:


Note: Since only employees are allowed to be Vendor Visit Registrars, we need a Delegation Action in the Employee IME to assign the “Admin roles” value to actually manage the delegation of this role to employees.

Member Rules


■ Anyone who has the “VIM Vendor Visit Registrar” value in the multi-value attribute “Admin Roles.”

■ Scope Rules: User in ( organization "Supplier" and lower ); Group none; Organization in none; Access none.

ROLE: VIM VENDOR RECEPTIONIST

The VIM Vendor Receptionist is responsible for updating vendor visit status, and recording vendor's identification and car license when the vendor arrives. In addition, the VIM Vendor Receptionist can view all vendor information.

The tasks a Vendor Receptionist can perform are illustrated in the following screen:

Note: Since only employees are allowed to be Vendor Receptionists, we need a Delegation Action in the Employee IME to assign the “Admin roles” value to actually manage the delegation of this role to employees.

Member Rules


■ Anyone who has the “VIM Vendor Visit Receptionist” value in the multi-value attribute “Admin Roles.”

■ Scope Rules: User in ( organization "Supplier" and lower ); Group none; Organization none; Access none.


ROLE: VIM VENDOR SYSTEM MANAGER

The Vendor System Manager is a delegated System Manager. The Vendor System Manager is responsible for the overall management of Admin Roles and Admin Tasks in the Vendor IME with support from the System Manager. Vendor System Manager actually owns all vendor related Admin Roles.

The tasks a Vendor System Manager can perform are illustrated in the following screen:

Notes:

■ Since only employees are allowed to be Vendor System Managers, we need a Delegation Action in the Employee IME to assign the “Admin roles” value to actually manage the delegation of this role to employees.

■ Since Vendor System Managers have a user scope of “Supplier” and lower, they actually need the System Manager to help set the “Supplier” organization scope for the Admin Roles they own.

Member Rules


■ Anyone who has the “VIM Vendor System Manager” value in the multi-value attribute “Admin roles.”

■ Scope Rules: User in ( organization "Supplier" and lower ); Group none; Organization none; Access none.


The System Manager for Vendor IME. System Manager owns these Admin Roles: “System Manager” and “VIM Vendor System Manager.”


Member Rules



■ Scoping Rules: User, Group, Organization, Access: all

Employee Delegated Identity Management Services

To simplify the design of the initial Employee Identity Manage (EIM) system, NeteAuto identity management projects decided to allow the Human Resources Representative to provide the services of managing the employee and organization structure information and use the Employee System Manager to provide most of the system management tasks, such as group management.

The NeteAuto EIM system offers Help Desk assisted service to the users including password reset and others. Further, to help scale the service, the managers are given the opportunity to provide assisted services to employees who report to them directly. In addition, these supervisors can also delegate the privileges to people who work for them. As a result, a supervisor delegate can provide assisted services to their colleagues.

Our initial Employee IME provides the following services:

■ Help Desk Assisted Services include:

> Employee Directory (View Only)

■ Password Reset

> Enable/Disable

■ Supervisor Assisted Services include:

> Supervisor View Employee Directory

> Password Reset

> Enable/Disable

■ Supervisor Function Delegation

■ Employee and Organization Services include:

> Organization Maintenance

> Employee Data Maintenance

■ Employee Identity Management System Management


SERVICE: HELP DESK ASSISTED SERVICES

The Help Desk is given the privileges to assist all employees to reset their passwords, and enable or disable the access.

SERVICE: SUPERVISOR ASSISTED SERVICES

NeteAuto also allows managers to provide password reset, and enable or disable services to their employees. In this case, we assume a manager is capable of authenticating the employee's identity without having to use much of the information on the system itself.

SERVICE: SUPERVISOR VIEW OF EMPLOYEE DIRECTORY

NeteAuto provides the supervisors a special view into their employees' information that includes the employee's cell phone number, which the Help Desk does not see.

SERVICE: SUPERVISOR DELEGATION ASSISTED SERVICES

Supervisor delegations are authorized to offer assisted services to help reset passwords and enable or disable users for their colleagues.

SERVICE: SUPERVISOR FUNCTION DELEGATION

Supervisors have the privileges to delegate the “Supervisor Delegation Assisted Services” to their direct reports.

Human resource representatives have the privileges to delegate the “Supervisor Delegation Assisted Services” to all employees during the transition review.

SERVICE: EMPLOYEE AND ORGANIZATION

The Employee and Organization service help maintain basic employee information and organization structure.

SERVICE: EMPLOYEE IDENTITY MANAGEMENT SYSTEM MANAGEMENT

The Employee Identity Management System Management service helps maintain the EIM delegation system.

Employee Delegated Identity Management Roles

NeteAuto uses the following Admin Roles to provide the services stated in the previous section.

■ Supervisor

■ Supervisor Delegation


■ Help Desk

■ Human Resource Representative

■ Employee System Manager

The Employee IME needs the following Admin Roles to support the Customer IME and Vendor IME. Initially, these Roles have no Admin Tasks:

■ Customer Services Representative



■ Vendor Visit Registrar



ROLE: CUSTOMER SERVICE REPRESENTATIVE

The Customer Service Representative job function provides customer service in the Customer IME.

Notes:

■ Being a Customer Service Representative provides limited privileges at the Employee IME.

■ The Add/Remove “CIM Customer Service Representative” controls the Role at the Customer IME.

Member Rules


■ Anyone who has the “Customer Service Representative” value in the multi-value attribute “Admin Roles.”

■ Scope Rules: User, Group, Organization, Access: none

■ Add/Remove Action: Add/Remove “Customer Service Representative” and “CIM Customer Service Representative” to the Admin roles attribute.

Administrator Rules

The administrator rules are as follows:

■ Anyone who has the Admin role “Employee System Manager”


ROLE: CUSTOMER SYSTEM MANAGER

The Customer System Manage job function helps maintain the Admin Roles/Admin Tasks information on the Customer IME.

Notes:

■ Being a Customer System Manager provides limited privileges at the Employee IME.

■ The Add/Remove “CIM Customer System Manager” controls the Role at the Customer IME.

Member Rules


■ Anyone who has the “Customer System Manager” value in the multi-value attribute “Admin Roles.”

■ Scope Rules: User, Group, Organization, Access: none

■ Add/Remove Action: Add/Remove “Customer System Manager” and “CIM Customer System Manager” to the Admin roles attribute.

Administrator Rules



ROLE: VENDOR ORGANIZATION MANAGER, VENDOR VISIT REGISTRAR, VENDOR RECEPTIONIST, VENDOR SYSTEM MANAGER

These Roles are set up similar to the two Customer-related roles. Instead of CIM, VIM is used as the prefix in the “Admin roles” attributes that control the Admin Roles employees have on the Vendor IME.


ROLE: EIM HELP DESK

The Help Desk offers help desk assisted services that include password reset and enable/disable users to all employees as shown in the following screen:

Member Rules

Anyone who has the “EIM Human Resource Representative” value in the member rules are as follows:

■ Multi-value attribute “Admin roles.”

■ Scoping Rules: User ( organization Employee and lower); Group none; Organization none; Access none.

Administrator Rules


■ Anyone who has the Admin Role “Employee System Manager”

ROLE: EIM HUMAN RESOURCE REPRESENTATIVE

Human Resource Representatives help maintain the NeteAuto internal organization information. They are also allowed to help manage employee data as shown in the following screen:

Note: Being an Administrator of the “EIM Supervisor Delegation” Admin Roles gives the “EIM Human Resource Representatives” the privileges to delegate that role to all employees.


Member Rules


■ Anyone who has the “EIM Human Resource Representative” value in the multi-value attribute “Admin roles.”

■ Scope Rules: User ( organization Employee and lower ); Group none; Organization (organization Employee and lower); Access: none.

Administrator Rules



ROLE: EIM SUPERVISOR

Supervisors are managers who have people that work for them. Supervisors offer supervisor assisted services to their employees and have a supervisor view of the employee information.

Notes:

■ Supervisor Scope Rules use a complex rule shown below:

Here, the Department stores the User ID of the supervisor an employee reports to. In this screen, you see that CA Identity Manager allows you to use the admin's attribute to create a filter to limit the set of users the individual can administer

■ We were unable to use the “Manager” attribute to compare with the “User ID” as it happens to be a DN, not just a uid. To work around this, we use a Logical Attribute


Handler (see Appendix E) to allow a DN to be entered and have the uid extracted and stored in the “Department” attribute.

Member Rules


■ Anyone who has the “EIM Supervisor” value in the multi-value attribute “Admin roles.”

■ Scoping Rules: User ( Department = admin's User ID and who are in organization “Employee” and lower); Group, Organization; Access none.

Administrator Rules



ROLE: EIM SUPERVISOR DELEGATION

Supervisor Delegations are “Delegated Supervisors”. They receive their privileges from their supervisors. They are given the privileges to help offer assisted services to their colleagues.

Note: Supervisor Delegation Scope Rules compare the “Manager” attributes. This means that if an employee has a new “Manager”, then it actually changes the scope of the privilege the employee has. This, however, may not be what the new manager wants. As a result, NeteAuto's Human Resources department needs to review the Employee's privileges during a transition meeting to ensure these types of privileges are removed before the transfer.

Member Rules


■ Anyone who has the “EIM Supervisor Delegation” value in the multi-value attribute “Admin Roles.”

■ Scoping Rules: User ( Manager = admin's Manager and who are in organization “Employee” and lower); Group, Organization; Access none.


Administrator Rules


■ Anyone who has the Admin role “EIM Supervisor” with the scope (Department = admin's User ID), or

■ Anyone who has the Admin role “EIM Human Resource Representative” with the scope of (Organization Employee and lower)

ROLE: EMPLOYEE SYSTEM MANAGER

Employee System Manager is a delegated System Manager. The Employee System Manager is responsible for the overall management of Admin Roles and Admin Tasks in the Employee IME with support from the System Manager. The Employee System Manager actually owns all employee-related Admin Roles.

Member Rules


■ Anyone who has the “Employee System Manager” value in the multi-value attribute “Admin Roles.”

■ Scope Rules: User, Group, Organization: ( organization "Employee" and lower ); Access none.

Administrator Rules


■ Anyone who has the Admin role “System Manager”


The System Manager is responsible for Employee IME.

Notes:

■ System Manager owns three Admin Roles: “System Manager”, “Employee System Manager”, and “Provisioning Synchronization Manager”. (Provisioning Synchronization Manager is discussed in Chapter 6 “Delegated Account Management”)


Member Rules





Real World Implementation Considerations

Secured Communication Channels

The most critical part of the communications that must be secured is between the Web browser of a user accessing the Identity Manager User Console and the Web server providing access to the User Console. Since most of the information in an identity management system is personal information, we strongly suggest that you use the Secure Sockets Layer (SSL) protocol for the Web browser to access the Web server. If your implementation lets Web browsers access the application server directly, you need to configure the application server for SSL communication.

If your user directory is LDAP, you can also secure the communication with the user directory by setting Security Connection to TRUE when the Identity Manager directory is created. This configuration forces an SSL connection to the LDAP user directory. By default, CA Identity Manager connects to the user directory without SSL.

User Interface Customization

You can customize the look-and-feel of an IME user interface using skins. An IME can have a single customized skin for the whole user population or different skins for different sets of user populations. For example, we use the standard skin for the employee IME, the out-of-box IDM skin for the vendor IME, and the out-of-box NeteAuto skin for the customer IME. For our purpose, the different appearances of the User Console in the Web browser clearly indicate to the NeteAuto employees which identity management system they are working on.

One common use of a skin is to present different sets of CA Identity Manager users with a different visual appearance. For example, you may want employees to experience a different look-and-feel than vendors or customers. In this case, you can create three different skin sets for the same environment: one for employees, another for vendors, and a third for customers.

You can implement multiple skins for different sets of users using CA SiteMinder policies and responses. In CA SiteMinder, you create a different policy, rule, and response for each skin-type within your protected Identity Manager realm. Depending on which type of user logs in, the policy activates a rule that triggers a response for the skin-type. The response is passed as an HTTP-header variable using the web agent which is protecting the environment. See the Identity Manager's Look and Feel chapter in the CA Identity Manager r8.1 SP1 Configuration Guide for more details.

CA Identity Manager skins consist of HTML, JSP and CSS content that you can modify. Any changes to skins require you to recompile the JSP pages and restart your application server.


Common Customization Scenarios

There is often a need to provide links back and forth to external portals from your CA Identity Manager user interface. This can be done by altering the head.jsp/index.jsp/menu.jsp pages of your skin.

You cannot remove, rename or add to the standard CA Identity Manager buttons such as Approve, Reject, Submit, in the Identity Manager screens. This is because CA Identity Manager only supports changes to the imcss console (under the Identity Manager EAR) and not the CA-default user console.

Initial Roll-out and Ongoing Operations

To effectively implement CA Identity Manager in your organization, you must carefully plan your identity management model before the initial roll-out. You need to consider things such as:

■ Which departments and organizations have users to be managed?

■ Which users should be administrators of other users?

■ Who should manage the administrators?

■ What admin tasks are needed in each role?

■ Who should create roles and tasks?

■ How can I use roles to delegate work?

As a CA Identity Manager user, you can personally manage users and their access to applications or you can delegate this work. Delegated administration is the use of roles to share the work of managing users and granting application access.

For delegated administration, each role contains rules that describe which users perform the functions managing members, administrators and owners. By dividing these functions between users, you can have lower-level administrators manage users and higher-level administrators assign or modify the role.

Based on your answers to these questions, you can decide how many and what kind of roles are needed.

Deployment and Performance Consideration

The use of delegated identity management marks the beginning of a true identity management system. At this stage, you might have a relatively small user population.


Typically the size of user population does not have a significant impact on performance. On the other hand, the number of role objects has a more significant impact on performance because a larger number of role objects may result in longer policy evaluation times.

■ You should try to avoid the proliferation of unnecessary roles in your system.

■ Rule definitions may impact the performance. For example “Not Equal” in rule conditions typically results in longer evaluation time than when “Equal” is used in rule condition.

■ If there is a tab that will not be assigned to most or all of your users, you may remove the tab from a task to increase performance. For example, if most of your users do not have admin roles, you may want to remove the Admin Role tab from user related tasks to increase performance.

Operation and Maintenance

After the deployment of your Identity Manager system, consider your backup and recovery plan. In addition to the obvious user directory and policy store backup, you should also back up the directory.xml and roledefinitions.xml files.

We recommend that you have a test environment for the CA Identity Manager system. If you do not want to migrate the whole policy store during migration, you can export the directory.xml and roledefinitions.xml files from the testing environment, then use these files to update other environments. For roledefinitions.xml file, you can find the delta change and only import the sections that have been changed.


Chapter 4 : Identity Self Service In the previous chapter, we mentioned that a common IT practice is to use delegation to help remove bottlenecks and scale a solution. The ultimate delegation is to mobilize all users who are part of the identity management system. CA Identity Manager is created with self service in mind. Self service is provided through the usual Admin Tasks.

Identity self service is interesting from the security point of view. Until now, a user first needed to provide a login credential before performing the desired tasks in an identity management system. The question then becomes what if the user does not even have an identity on the system or what if the user is unable to prove their identity through a regular authentication method? In other words, our identity management solution may need to provide certain access that does not require a proven identity to allow the users to establish the identity for the first time or to prove their identity through alternate authentication methods.

CA Identity Manager uses a Public Task flag to determine whether the task requires login credentials. The out-of-the-box Public Task examples include:

■ Self Registration

■ Forgotten Password Reset

■ Forgotten User ID

Other commonly seen self service tasks that require login credentials include:

■ Change My Password

■ Modify My Profile

■ Modify My Self Subscribing Groups

In this chapter, we start with allowing people to view the identity objects we have maintained on our system but highlight the importance of privacy concerns. We continue to use the authority concept to explore the possibility of inviting individuals to help maintain their own data. We look into the self authentication technologies to help people restore their access. We then present examples on our three IMEs.

Identity Directory and Privacy

One of the first applications of self service is an online directory that helps users locate other identities in the system. An online directory helps increase productivity and saves the cost of having to have some other person look up the information or of having to maintain separate publications for this information. However, the distribution of this type of information can lead to undesirable consequences.

70 Identity Self Service

According to the Consumer Fraud and Identity Theft Complaint Data report published by the U.S. Federal Trade Commission (FTC) (available at http://www.consumer.gov/sentinel/pubs/top10fraud2005.pdf http://www.consumer.gov/sentinel/pubs/top10fraud2005.pdf), between January and December 2005, a consumer complaint database developed and maintained by the FTC, received over 685,000 consumer fraud and identity theft complaints. The reported consumer losses from fraud were more than $680 million.

On the Home page of the FTC Privacy Initiatives (http://www.ftc.gov/privacy/index.html http://www.ftc.gov/privacy/index.html), the FTC also states that “Privacy is a central element of the FTC's consumer protection mission.”

When an organization is considering an identity self-service project, privacy is an important factor to consider. In particular, many organizations are now required to provide some sort of Privacy Statement to their customers to inform them how the organization collects, uses, and secures personal information.

Employee Directories

For most companies, employee directories are considered business tools. A general employee directory should only contain information that is suited to be publicized within the company. For example, employees' cell phone and home phone numbers are usually not to be published in the general purpose employee directory.

The special relationship between supervisors and their employees may give supervisors the privilege to see their employees' cell phone and home phone numbers. For this purpose, we often see the need to have a supervisor employee directory.

Note: A supervisor should only see their direct reports from this view.

Vendor Directories

A vendor directory is a business tool and is very application-dependent. For a general purpose vendor directory, the information is usually similar to a general employee directory discussed in the previous section.

Customer Directories

A customer directory is a very sensitive business tool as it tends to contain customers' personal information and needs to be guarded at all costs. This is where identity theft is likely to happen. Only authorized employees are allowed to access the directory. Customer directories are also application-dependent. Companies that fail to protect customer information can incur heavy costs, if only to restore confidence, if not fines.

http://www.consumer.gov/sentinel/pubs/top10fraud2005.pdf

http://www.ftc.gov/privacy/index.html


Member Directories

A member directory is a special form of a customer directory. A business may offer this service for customers to find information about each other. This type of tool is often used as a networking tool to promote a sense of community.

Since this is a customer-oriented service, it is extremely important to allow the customers to easily add or remove themselves from the directory and to determine what information should be made available on the directory.

Public Directories

Sometimes, an organization may decide to offer its customers the opportunity to be added to a public directory of some sort. It is important that the customers are given opportunities to decide how their data should be used and to be able to change their minds easily.

Self Service and Authority

Once you decide to involve users in the maintenance of the information in your identity management system, the natural question to follow is what authorities are you willing to give to different types of individuals? To help answer this and other questions, we need to continue to examine the customers, vendors, and employees IMEs.

Profile Self Service

On a customer identity management system, other than certain administrative data that includes the user ID the organization uses to serve the customer, a customer-oriented profile self service page usually lets customers change most of the information that has been collected through the self-registration stage.

If a vendor profile self-service is offered, it is most likely to be similar to a customer profile self-service.

Employee profile self-service is an interesting topic. As we have discussed during the “Identity Management and Authority” section in the “Delegated Identity Management” chapter, we may only give the employee the privileges to change information like cell phone numbers and self-authentication questions and answers.

Advertise Your Services

Encouraging people to start using your services can be a challenge. First, you have to advertise its existence. Perhaps you want to offer incentives. Do the benefits of using self-service actually justify the cost of using it? Are you prepared to offer servers to your different audiences?


For a customer system, your starting point is the Customer Service Web site where your customer is likely to visit. You should plan to provide benefits to convince your customers to register.

For a vendor system, it all depends on what you want to do with it. In the examples in this book we assume that the employees of the vendor require membership to facilitate the vendor relationship with the enterprise.

For an employee system, you probably have the internal communication systems, the publicly accessible employee Home Page, e-mails, and so on. You may also provide employees with the means to manage their IDs and passwords.

You also want to consider how to roll-out your services to your various user types. You can consider a phased roll-out approach. The questions you want to ask include:

■ Are any of the messages on the system inappropriate for an internal or external audience?

■ What is the anticipated load on the system? Is your system capable for handling that load?

■ Do you have plans for initial system training and staffing to support possible issues as your users begin using the system?

Self-Registration

The next question is what if the user does not even exist on your identity management system. For a customer identity management system, it is likely a customer self registration service may be offered to allow and encourage the general public to join and to be better served.

Similar to the vendor directory discussion, a vendor identity management system is application-dependent. A company might be willing to open up a vendor self-registration service to allow vendors to register and participate in the bidding opportunities. It is also possible that a company wants to establish a closed system that uses the preferred vendor concept to help reduce the cost of having to work with the general public.

It is less likely for a business to offer employee self-registration.

Self-Registration Design Considerations

The special design considerations for self-services include:

■ Publicly Accessible Entry Points

■ End User License Agreement

■ The default container that is to be used to store the customer record


PUBLICLY ACCESSIBLE ENTRY POINTS

The publicly accessible entry point you provide is most likely a Home Page for your business where users go to consider registering.

A CA Identity Manager publicly accessible Web page is an Admin Task that has the “Public Task" checked as shown in the following screen:

The Web page URL is similar to:

http://<your server

name>/idm/customerPub/ca/index.jsp?task.tag=CustomerSelfRegistration

END USER LICENSE AGREEMENT

For most organizations, before your customers actually reach the self-registration page, you must first present them an End User License Agreement. Customers must acknowledge the license agreement before proceeding.

An End User License Agreement can be a Web page hosted by another Web server your business may have established or you may need to create a new page. For our sample customer IME, we store our sample file, message.html, under a new custom subdirectory:

<AppServer>/IdentityMinder.ear/user_console_war/app/custom

To test this page, try the following URL:

http://<your server name>/idm/customerPub/custom/message.html

Because the license agreement can become legally binding between you and your customers, it certainly needs to be written with extreme care. Before you put the system up for the public to use, it is advisable to get your Legal department to agree to the information on the page.


The actual designation of the End User License Agreement looks as follows:

Instead of hard coding the URL with a machine name and IME name given above, the Message URL, ../custom/message.html, on this screen is using a relative path. This is a technique used to make the design of this screen portable so that you can use the RoleDefinitions.xml files provided in this book without having to modify it.

DEFAULT CONTAINER

For an identity management system that is using a hierarchical user data store, you must specify a default container to store the identities that are to be created.

Self Authentication

Many studies have shown that resetting passwords can be very expensive. When employees forget their password, the company not only suffers the cost of having someone reset it for them, but also the cost of lost productivity.

The goal of self-authentication is to have the information system play the role of the Help Desk in asking the individuals personal questions as the alternative to the password authentication. The system asks the user with the forgotten password “Something they know.”

The design considerations for a self-authentication system include:

■ Publicly Accessible Entry Points

■ User Identification

■ Forgotten ID scenario

■ Self Authentication Questions and Answers

■ System Generated Password vs. User Supplied Password

■ Different Self Authentication Requirements


Publicly Accessible Entry Points & Windows Login

To provide self-authentication services, your system needs to provide similar entry points to those we described in the Self Registration design considerations.

WINDOWS LOGIN TECHNOLOGY (GINA)

One of the challenges for a self-authentication system is how to allow employees who have forgotten their passwords to access an application on the system to reset their passwords. Many times access to the program or Web browser required to reset their password requires authentication to a system to run the program. One way around this is to use Windows technology to provide a limited screen pop up that only allows you to change or reset your password, possibly after answering a security question or two.

The CA Identity Manager's provisioning capabilities (eTrust Admin) include the GINA Option for Password Reset/Unlock provides integration to the standard Microsoft Windows Logon dialog and allows a user to access only the Self-Authentication Web page without actually signing onto the base system. You need to first install the GINA option and configure it using the configuration tool or by manually editing the Windows Registry. When installed, the interface places one or two links on the standard Microsoft Windows logon dialog.

PUBLICLY ACCESSIBLE ENTRY POINT

Similar to the Self-Registration service, the Self-Authentication Web pages must be on publicly accessible Web pages because the users cannot prove their identity through standard authentication methods.

The Web page URL is similar to:

http://<your server

name>/idm/employeePub/ca/index.jsp?task.tag=ForgottenPassword

You can use the GINA option or put this URL on another well-publicized and unprotected Web page where an individual can easily locate it.

User ID Identification

If users cannot authenticate themselves through the standard authentication methods, we might want to see how much more the user knows about the ID before allowing the actual authentication process to start. Remember that giving the bad guys the questions you might ask the good guys can be a bad thing. Commonly seen extra questions include user's full name, employee number, or email address.

CA Identity Manager allows you to ask these extra questions before proceeding with the self-authentication questions.


Forgotten ID

What if the users have actually forgotten their own IDs? This scenario is seen more often in a business-to-customer situation where users do not use their own IDs often enough to remember them.

A commonly used approach supported by CA Identity Manager is to ask the users to provide their email addresses and then send an email to the specified email address with the user ID. This way if the email is invalid, then there is little chance of harm when the email is sent.

Self Authentication Questions and Answers

Self authentication questions must be designed carefully as the general public uses them. Before you put your system in production, consult with your Human Resources or Legal department to make sure the set of questions are actually appropriate for public viewing.

In general, the system should provide a list of pre-defined questions for users to choose from. Users may not have the answers to any single question you might use for verifying their identities. It is also possible, though unlikely, that you would want the users to make up their own questions and then answer to them.

Depending on your security policies, you may need to decide how many questions you want to ask, how tolerant you are with wrong answers, and so on. You may also want to ask multiple questions at the same time or to feed one question at a time. One argument is that you may not want to give away too many questions too quickly.

Identity Profile Self-Service can become a prerequisite for offering self-authentication as it may be the only time you can have users select self-authentication questions and supply the answers. During the Q&A session, you should mask the answer just like the password to avoid other people looking over the shoulders of your users. It is debatable whether the answer should be visible to the users who are viewing their “Identity Profile Self-Service” information.

System Generated Passwords versus User Supplied Passwords

As a matter of preference and security policies, you might want to decide whether to have the system generate the passwords for the users or allow the individuals to supply their own passwords. You might also consider sending the individuals emails with system-generated passwords. For a system-generated password, it makes sense to pre-expire the password and require users to change it themselves immediately after they sign onto CA Identity Manager.

CA Identity Manager supports both policies. The out-of-box example public Admin Task for System Generated Password is the “ForgottenPassword”. It always displays the system-generated password on the screen and allows the user to copy and then paste it on a new login attempt. The example User Supplied Password is the “ForgottenPasswordReset”.


Avoid AutoComplete

Some Web browsers let users to decide whether they want the AutoComplete option turned on or have the system remember passwords. While these features can be considered productivity tools, they are major threats to security. Instead of leaving the matter to the end user to decide, CA Identity Manager allows you to ask the browser to turn the feature off on some sensitive fields by checking the Disable AutoComplete box during the layout of a screen as follows:

Different Self-Authentication Requirements

You might want to consider offering different self-authentication policies for different sets of your user population. For example, the self-authentication design on a customer identity management system can be quite different from the one on an employee identity management system. However, CA Identity Manager does not support this on the same Identity Manager server. In this book, we have set up three Identity Manager Servers that share the same user data store for the three IMEs.

Remove or Disable Unused Public Tasks

You might want to disable some of the unused out-of-box sample public Admin Tasks by reusing them, removing them or un-checking the Public Task box regardless of how you want to offer your own. Otherwise, you are actually allowing the public to use these publicly accessible tasks without realizing it.

Sample Identity Self-Services

NeteAuto does not offer Self-Services to the vendor populations. The Vendor IME is designed initially as a physical security tool. In this section, we focus on the Self-Services needed for both the customer and employee populations.


Customer Identity Self Services (Services)

The Customer Identity Self-Service is the primary business driver for the Customer Identity Management (CIM) system. The delegated identity management aspect of the CIM allows the CIM to get off the ground and to start building the NeteAuo Customer Self Service. Initially, the NeteAuto Customer Self Service may look as follows:

Other than personal self-help services that include the free special interest group subscription, NeteAuto also provides a Member Directory service to encourage building the sense of community among the customers. A Public Directory is also offered for those who are willing to be searched by the general public over the Web. The following is a list of services that support the NeteAuto Customer Self Service:

■ Customer Self-Registration

■ Customer Forgotten Password

■ Customer Forgotten Screen Name

■ Customer Profile Self-Service

■ Customer Member Directory

■ Customer Special Interest Group Self-Service

■ Customer Public Directory

SERVICE: CUSTOMER SELF-REGISTRATION

Like many Internet businesses, NeteAuto wants to allow their customers to Self-Register as the first step to offer better personalized services through the Web. The Self-Registration is accessed through a URL similar to:


http://yourservername/idm/customerPub/imcss/index.jsp?task.tag=CustomerSelfRe

gistration

http://yourservername/idm/customerpub/imcss/index.jsp?task.tag=customerselfre

gistration

The general public is first challenged by accepting an “End user License Agreement”:

The acceptance of this agreement is required before moving to the next step of the self-registration process.

Part of the self-registration process allows the user to enroll in Special Interest Groups as shown in the following screen:

The self-registration provides users with the ability to:

■ Enter their identification and contact information

■ Set up their Screen Name and password

■ Select from the NeteAuto determined Self-Authentication Questions and supply the answers

■ Add themselves to the Public Directory and/or the Member Directory

http://yourservername/idm/customerpub/imcss/index.jsp?task.tag=customerselfregistration

http://yourservername/idm/customerpub/imcss/index.jsp?task.tag=customerselfregistration


The following is an example of what a user information page might contain:


SERVICE: NETEAUTO PUBLIC DIRECTORY

The Public Directory is accessible from the NeteAuto Customer Self-Service Web site. If customers select "Publish Me in Public Directory," their names and contact information will appear in this list. The Public Directory is publicly viewable. The Public Directory only shows the customer's Screen Name and e-mail address. Following is the search screen and profile screen:

NeteAuto Public Directory

You cannot implement the Public Directory using the public Admin Task. Other than the Self-Registration public task, a public Admin Task does not have a user context and as such has no access to any of the data on the system.


As a result, we configured the CA SiteMinder authentication scheme and created a customized loginGB.fcc that signs onto the Customer IME using a public ID. The loginGB.fcc presents the sign-on screen as follows:

You can integrate this loginGB.fcc with the NeteAuto Customer Self-Service Web site. The loginGB.fcc and configuration procedure can be found in Appendix F.

SERVICE: NETEAUTO MEMBER DIRECTORY

If members select Publish Me in Member Directory during registration, their name and contact information appears in this list. The Member Directory is only viewable by fellow members. It shows the customer's first name, last name, full name and email address. The following two screens show the search and the selected result:


SERVICE: CUSTOMER FORGOTTEN PASSWORD

Registered NeteAuto customers can self-authenticate and reset their own password from a link on the NeteAuto public Customer Self-Service Web site. The self-authentication requires the customers to know their Screen Name as shown in the following screen:


Then it requires them to answer the three Self Authentication Questions correctly as follows:

A temporary password is provided on the screen and an email is sent with the same information as shown:

Customers can then use the temporary password to log in and are required to change their password immediately. The email serves two purposes: It gives the customers the opportunity to do the actual login later. It serves as an alternative for the customers in the rare case when the customer's self-authentication becomes compromised.


SERVICE: CUSTOMER FORGOTTEN USER ID

NeteAuto Company also decided to give customers the ability to retrieve their own User ID / Screen Name. To do this, they must provide their e-mail address as well as answer three questions correctly, the first of which is shown in the following screen:

They are then given their User ID / Screen Name.

SERVICE: SPECIAL INTEREST GROUP SELF-SERVICE

Details about this service are given in the “Web Application Authorization” chapter.

Customer Identity Self-Services (Roles)

To support these services, NeteAuto uses three different Admin Roles:

■ Anonymous (For Public Directory)

■ Customer

■ Member

ROLE: ANONYMOUS

To provide a Public Directory that requires no authentication from the general public you must create a special user ID, CustomerPublic. When the Public Directory on the NeteAuto Customer Self-Service Web site is clicked, it signs onto the Customer IME using this ID.

Note: Since an Anonymous user is actually user CustomerPublic, using this ID and its password is still permitted through a regular sign-on. This attempt still gives the same access.

Member Rules



■ User ID = customerpublic or anyone who is a member of Admin Role “Customer”

■ Scope Rules: User ( PublishPublic = Public and organization “Customer” and lower ); Group none; Organization none; Access none.

ROLE: CUSTOMER

A customer is an individual who has registered on the NeteAuto Customer IME.

Member Rules


■ Anyone except “CustomerPublic” who is under the organization “Customer” and lower.

■ Scoping Rules: User none; Group none; Organization none; Access none.

Notes:

■ A Customer Role obtains the “Public Directory” through the “Anonymous” Admin Role.

■ As a result, we are seeing Admin Tasks with different Scoping Rules for the same user.

ROLE: MEMBER

A member is a customer who wants to be published on the Member Directory and has the privilege to access the same.

Notes:


■ A “Customer” obtains its “Member” status through the “Public Member” attribute.

■ As a result, a “Member” actually has three different Roles, Anonymous, Customer, and Member.

Member Rules


■ Anyone who has Public Member = Member, is not the “CustomerPublic”, and is under organization “Customer” and lower.

■ Scoping Rules: User ( same as Member Rule ); Group none; Organization none; Access none.

Employee Identity Self-Services (Services)

To help increase productivity, NeteAuto wants to further expand its Employee Identity Management services into Identity-Self Services to allow employees to look up the Employee Directory, and to update their cell phone numbers on their own personal profiles. To properly support this system, NeteAuto wants to provide Self-Authentication services to allow employees to reset their own passwords. The initial set of services includes:

■ Employee Self-Authentication

■ Employee Profile Self-Services

■ Employee Directory

■ Employee Self-Service Notification

SERVICE: EMPLOYEE SELF-SERVICE NOTIFICATION

To pace the size of the audience, NeteAuto decides to phase the self service roll-out schedule. This service sends the employees and their manager the same email to notify them where and how to start using the self service.


SERVICE: EMPLOYEE PROFILE SELF-SERVICE

The NeteAuto Company only allows employees to change their own cell phone number as the Human Resources system and other parts of the organization have authority over the remainder of an employee's information. Since cell phone numbers change more often than most other employee information, the employees are given the privileges to change their cell phone numbers using the employee profile self-service screen shown below:

Note: The Self-Authentication Questions are pre-determined through a drop-down list as shown:

SERVICE: EMPLOYEE DIRECTORY

The Employee Directory is very much like the address book seen in email applications and contains standard business information about NeteAuto employees. What sets it apart is that it takes the information out of the same user data store shared with other services like the supervisor view of the employee directory.


SERVICE: EMPLOYEE SELF AUTHENTICATION

NeteAuto requires an employee to supply both their User ID and Employee Number before the Self -Authentication challenges are presented as shown:

The rest of the challenges and responses are similar to what have been shown with the Customer Forgotten Password service.

Employee Identity Self-Services (Roles)

NeteAuto introduces two new Admin Roles to provide the two services, “Employee Directory” and “Employee Self-Service”:

■ Employee

■ Employee Self-Service

The Employee Self-Authentication service is a public task and must be published at a Publicly Accessible Web page. The “Employee Self Service Notification” service is initially offered by the Employee System Manager role before the notification. The employee must have the Employee Self Service role first.

ROLE: EIM EMPLOYEE

The Employee role gives a NeteAuto employee the access to the standard business tools like Employee Directory.

Member Rules


■ Anyone who is under the organization “Employee” and lower.

■ Scoping Rules: User ( organization “Employee” and lower ); Group none; Organization none; Access none.


ROLE: EIM EMPLOYEE SELF SERVICE

The Employee Self-Service role gives the employees the privileges to modify their personal profiles including the Self-Authentication Q&A to allow them to use the Self-Authentication.

Notes:

■ The primary purpose of creating a separate “Employee Self Service” Admin Role for NeteAuto Company is to give the company the opportunity to roll out Employee Self-Service gradually.

■ Once this need is done, this role can not simply be merged into the Employee role. This is because the two roles actually have different scoping rules. Doing so can sometimes create undesirable effects. To do it correctly, you can either change the Member Rules to give it to 'Anyone who is in the organization “Employee” and lower' or make the “Employee” the “Primary Admin Role” of this role as we discussed in the “Primary Admin Roles, Admin Task, and Scope Rules” in the “Introduction” chapter.

Member Rules


■ Anyone who has the “EIM Employee Self Service” value in the multi-value attribute “Admin roles.”

■ Scoping Rules: User none; Group none; Organization none; Access none.

Administrator Rules




Secured Secure Self Services

RESTRICTING ACCESS TO THE SELF MANAGER ROLE

Be default, the Self Manager role, which allows users to manage their profile information and view their roles and submitted tasks, is assigned to all users. To give the Self Manager role to a subset of users, delete the existing member policy and create a new policy with a new membership policy.


ACCESSING SELF-SERVICE TASKS

Once you have configured the self-service tasks for your IME, you can add URLs for these tasks to a corporate Web site. URLs for self-service tasks have the following format:

http://<domain>/idm/<im>/index.jsp?task.tag=<task_tag>

<domain>

Is the fully qualified domain name of the system where Identity Manager is running

<im>

Is the public alias of the Identity Manager environment

<task_tag>

Is the unique identifier for the task.

Since Self-Services are accessible by public and often personal information is transmitted during self-registration or password reset processes, it's important that the confidential information is protected, for example using SSL.

CONTROL THE SELF-REGISTRATION PROCESS

If the self-registered users need to be examined before they are allowed to access the CA Identity Manager system, a common practice is to associate a workflow process with the self-registration task so that designated administrators can review the self-registration information, then accept or deny the request.

PROTECT THE FORGOTTEN PASSWORD AND FORGOTTEN USER ID TASKS

To prevent end users from abusing the password reset task or hackers from attacking the CA Identity Manager system, you should consider locking the user account under the following circumstances.

Configuring a Failed Attempt Limit based on:

■ Number of acceptable incorrect answers

■ Verification page timeout

■ Verification page attempt limit

■ Successful Attempt Limit

Limiting the number of successful verification attempts prevents users from misusing the Forgotten Password Reset or Forgotten User ID task. For example, a user may rely on the Forgotten Password Reset task to reset a password instead of having to remember a password that conforms to a strict password policy.



Offering identity self-service can be very cost-effective for an identity management system. However, exercise care as you are subjecting your system to the general public to use and you really do not know what to expect. Other than what has been stated throughout this chapter, the topics that follow provide a list of logistical considerations.

ROLL-OUT SCHEDULE

Generally, we suggest that you plan a schedule to gradually roll out the system to your user population. You may initially use your own group as the pilot team to ensure a basic configuration. Then, you might gradually enlarge the circle of coverage to bring more people to help test other aspects of the system.

SYSTEM PERFORMANCE

Since different organizations may have different usage patterns, it can be hard for you to predict the kind of peak load you are going to get overtime. Or, you might actually need to prove the value of your system before you can get the funding you need to have the system set up to sustain the peak load that can occur.


Since self-services are open to public users, they will potentially have the heaviest use among all tasks. It is important that you stress test these tasks before deploying the production system.

In a typical IME, you need to review the configuration for the Web Tier, the Application Server Tier, the Policy Server Tier, the Provisioning Server Tier and the Back End / Data Tier.

For password reset, you should try to avoid asking a large number of end users to reset their password during a short period of time. Instead, try to arrange users' passwords to expire at different times and give them a grace period to reset their passwords. One way to achieve this goal is to create multiple password policies in CA Identity Manager, then assign these password policies to different sets of users.

Also as mentioned earlier in this chapter, you should configure a failed attempt limit and a successful attempt limit to prevent self-services from being abused.


Chapter 5 : Web Application Authorization This chapter provides a transition from Identity Management to Account Management, which is discussed in the next two chapters. The identities we have been discussing so far in this book are computer accounts. This chapter shows you many other things you can do with accounts.

First we describe a use case where CA Identity Manager is used to deliver a personalized Web application list to users. This application opens a whole new perspective into the self-service described in the previous chapter. To facilitate the personalization, we revisit the Delegated Roles Administration feature. Using the Members rule and the Self-Subscribing Group feature, you can configure CA Identity Manager to provide a Special Interest Group Subscribing service.

The Delegated Roles Administration concept also applies to Access Roles. An Access Role is an enhancement to the CA SiteMinder Policy Server. It provides SiteMinder administrators the same facilities in CA Identity Manager.

Because CA Identity Manager is built on the CA SiteMinder Policy Server, you can provide single sign-on for an organization that uses CA SiteMinder-protected Web applications and CA Identity Manager. Likewise, we can use single sign-on to provide the employees on the Employee IME access to the other two IMEs should they have the need.

Personalized Web Application Delivery

In any large organization, employees are expected to use a multitude of internal and external web applications. Often the set of tools used by an organization's employees varies with the employee's role within the organization. As new people join the company, they are bewildered by the number of common tools that everyone else just seems to know. Introducing new tools is usually done in a viral fashion. For example, managers send emails to team members and hope they read and use tools, wiki sites, and so on. The adoption is rarely complete.

CA Identity Manager lets you create a Personalized Web Application Delivery service. Using the Admin Roles of CA Identity Manager you can advertise both company-wide tools, like the Help Desk, and role specific tools, like a time reporting tool. As new tools come online they are instantly available to the work force.

The goal is to deliver the applications a person is likely to need to do the job without showing them the entire spectrum of the corporate tool set. To deliver this service, you need to consider how to map the Web applications to your user population in a manageable and scalable manner, and how the Web applications are to be delivered.

94 Web Application Authorization

Map Web Applications to the Users

The first task is to identify the tool set by working with the people who use each tool. For example, every employee needs access to the Help Desk, but only a few require access to the accounting system. Delegated Role Administration is designed to address these types of issues. After you determine the roles and the tools those roles use, map those roles to CA Identity Manager Admin Roles.

Presenting Web Applications to the Users

CA Identity Manager lets you bring a third-party Web application into the Identity Manager User Console. Instead of directly displaying the Web page, you might want to show an instruction page that explains the nature of the Web page and then ask the user to click on a link that directs the user to the actual Web page. You may also choose to open a new browser window for the page. For example, you can display an instruction page in instances when the Web application does not fit well inside the Identity Manager User Console.

Consider the following to help you determine how to present an application to users:

■ The Instructional Page and URL of the Third-Party Web Application

■ The Admin Task and the definition of the External Tab in CA Identity Manager

■ The display of the Menu Item on the User Console in CA Identity Manager

INSTRUCTIONAL PAGE AND URL

To deliver a third-party Web application within CA Identity Manager, you first need to decide whether an extra instruction page is needed.

If the answer is yes, then you need to determine what information should appear on the opening page that instructs the user how to use the Web application. The opening page should include a URL. When users click the URL, a new Web browser opens and takes them to the actual Web application page.

The instruction page can consist of multiple Web files including graphics and others. The physical Web files can be stored on the CA Identity Manager server or their supporting Web servers. Therefore, the original contents allowed are actually determined by the delivering services. For example, you might use ASP pages if you choose to use an MS-IIS Web server to deliver them.

If you choose to use your CA Identity Manager server to deliver the instruction page, you can consider storing them under a subdirectory named “custom” created under:

<APPServerDeployedHome>/IdentityMinder.ear/user_console_war/app.

For example,


E:\jboss-

3.2.2\server\default\deploy\IdentityMinder.ear\user_console_war\app\custom

or

E:\bea\user_projects\domains\mydomain\applications\IdentityMinder.ear\user_co

nsole_war\app\custom.

Further, assuming the instructional page is the CustomerPortal.html, the URL to this page might resemble the following:

https://<your server name>/idm/EnvName/custom/CustomerPortal.html

ADMIN TASK USES EXTERNAL TAB

With the determined URL, you define an Admin Task to deliver the Web application through an External Tab. For a general purpose Web Application, the Primary Object should be None and the Action Self View as the following:

The External Tab might look as follows:

We use a relative URL like:


/idm/employee/custom/customerPortal.html?Server=YourCustomerPortalServerName#

We rely on the system to add it to the root of the Web server used to access CA Identity Manager to form something like:

https://<your server name>/idm/employee/custom/customerPortal.html?Server=YourCustomerPortalServerName#

This makes the URL work with multiple server names. The use of the “?Server=YourCustomerServerName” must be configured.

We also added a # at the end of URL field to block any unwanted parameter that may be generated by CA Identity Manager. It also means that sometimes, CA Identity Manager does try to pass in other information for you to use in your own Web pages. More discussions about the # are provided later in the personalization discussion.

DISPLAY THE MENU ITEM

The value of the Category on the Admin Task Profile tab is used to determine where to display the Menu Items on a user's Identity Manager User Console.

Personalizing Web Application Presentation

The discussion of the External Tab actually points us to broader presentation possibilities. We will further look into personalization possibilities and portability issues.

PERSONALIZED CONTENT

The instructional page mentioned previously can be simple HTML. To accomplish this, consider using JSP pages or their equivalents to deliver the instruction pages. To demonstrate this capability, we have prepared the showparm.jsp.

The showparm.jsp file displays the parameters that are passed into it in a table. With its help, you can modify an Admin Task to retrieve many possible dynamic content elements from CA Identity Manager and use them in your own instruction pages. For example, when the Primary Object on the Profile tab is set to Admin Task, you can include the attributes that belong to the Admin Task as parameters to showparm.jsp. Likewise, if you set the Primary Object to User, then you can retrieve the user's personal attributes that are stored on the CA Identity Manager server and pass them to this same jsp page.

Note: You must change the Primary Object on the Profile tab, set the Action to Self View, and then go to the Tabs tab to configure the External Tab. On the External Tab configuration page, you will see that the attributes of the Primary Object now are available for use. If you want to use the attribute, then the “#” mentioned earlier would need to be removed.


The following screen shows the available attributes when the Primary Object is “User”:

PORTABILITY

While developing your instruction pages for third-party Web applications, keep in mind that CA Identity Manager supports three main application servers, JBoss, WebLogic, and WebSphere. A JSP developed for one application server may still require some modification for it to work on another. Likewise, CA SiteMinder also supports Microsoft-IIS, Apache, and other Web servers. The Web server front-ends in combination with the application server back-ends have been known to cause portability issues for the custom developed Web content.

SHOWPARM.JSP

The following is the contents of the showparm.jsp file:

<html>

<body>

<%

out.println("<table border=1>");

out.println("<tr><td><b>Parameter Name</b></td><td><b>Parameter

Value</b></td></tr>");

for (java.util.Enumeration e=request.getParameterNames(); e.hasMoreElements(); ) {

String s = ""+e.nextElement();

out.println("<tr><td>"+s+"</td><td>"+request.getParameter(s)+"</td></tr>");

}

out.println("</table>");

%>

</body>

</html>

Self Subscribing Groups

Most organizations are comprised of many different roles and smaller organizations. Examples include accounting, sales, HR and a host of others. Each of these groups might be comprised of smaller groups. Each one of these smaller groups has their own special interests and sources of information. There also exists information on corporate activities or


charitable events. Each of these sources of information might have its own WIKI, blogs, and Web sites. There is rarely proprietary information or information that must be protected from the employees of the company, but not all employees want or need to look at this information. In an optimal solution, employees should have an easy way to subscribe for content that is of interest to them.

CA Identity Manager offers the concept of Self Subscribing Groups. By using the combinations of this concept and Rule Based Admin Roles, you can offer Special Interest Group services to give users the ability to subscribe to the groups that interest them and receive additional menu items on their Identity Manager User Console.

A Self-Subscribing Group is just a regular group with the “Self Subscribing” box checked as follows:

Enhance CA SiteMinder with RBAC Rules

The Access Roles in CA Identity Manager allow CA SiteMinder administrators to create RBAC rules to enforce the Web application authorization. This means the same Policy Server used by CA Identity Manager can actually protect other Web applications.


Configuration

With an IME defined, the Domain Properties page in CA SiteMinder lets you add the IME as one of the domains from the CA SiteMinder point of view:

With the IME associated with a domain, you can use the Access Role in the CA SiteMinder Policy Properties. The following screen shows the SiteMinder Policy Dialog with the “customer” IME tab selected. Click the Add/Remove button allows you to add any Access Role defined in that environment. This allows CA SiteMinder to write policies that use the members of the added Access Roles as the users:


Role Based Policy

With CA Identity Manager, your CA SiteMinder can now control access to applications using access roles and tasks. An access task provides access to a function in an application. An access role contains one or more access tasks for one or more applications. When a user has been assigned an access role, the user can use the access task that exists in that role.

For CA SiteMinder secured web applications, the typical policy is user-based, which means that if the user profile or membership change, then it is likely that the policy must also be updated. With Access Roles, policies can be role-based. When the role definition changes, the CA SiteMinder policy remains untouched and translates into less administrative overhead.

Task Based Response

The policy server uses role-based policies to grant or deny users access to Web resources. To further control what the user can do in the Web application, the task-based response is paired with the policy rule.

When the policy server authorizes a role member for a protected resource, the following events take place:

■ The policy's rule executes in policy server, triggering the paired response.


■ The Policy Server obtains entitlement information from Identity Manager to include in a response.

■ The Policy Server passes the response attribute to the Web Agent.

■ The Web Agent makes the entitlement information available to the application as an HTTP header variable or a cookie.

With the combination of role-based policy and task-based response, the Web application can determine if the user can use certain web resources or not. For more information see the CA Identity Manager Operations Guide.

Single Sign-on

With all of the user IDs and passwords we need today, it easy to understand why password resets are a problem for organizations. People are required to remember lots of passwords and user IDs and often resort to insecure practices such as using the same user ID and password across multiple systems or writing down the information on sticky notes and putting them under their keyboard. CA has fully functional single sign-on tools such as CA SiteMinder, CA Single Sign-On, CA Embedded Entitlement Manager, and their integration to alleviate these issues.

Single Policy Server

CA Identity Manager includes a SiteMinder Policy Server. Web applications that are secured by CA Identity Manager, or its embedded SiteMinder policy server, can be configured for single sign-on. This allows single sign-on between Web applications and the Identity Manager User Console.

If you set up the three sample IMEs discussed in this book on a single CA Identity Manager server, single sign-on between the IMEs can be provided by the CA SiteMinder policy server included in your CA Identity Manager implementation.

Multiple Independent Policy Servers

In the sample scenarios, we purposely set up three IMEs hosted on three separate CA Identity Manager servers and three separate SiteMinder Policy Servers.

Note: This design is not required. CA Identity Manager is capable of supporting multiple IMEs on the same Identity Manager servers.

There are three requirements to offer single sign-on for an environment with disparate policy stores like we do:

■ Each Policy Server must have the same User Directory name configured in the Policy Stores (case-sensitive)


This is actually the reason why we created the three Identity Manager Directories using NeteAuto as their SiteMinder User Directory name.

■ A user must have the same DN in each LDAP Directory.

Since we use the same LDAP User Data Store, we automatically satisfy this requirement.

■ The Policy Servers must share the same key store or have the same static key set for the Web Agents.

To accomplish the last requirement and use the same static key approach, you must connect to the three CA SiteMinder user interfaces to set the static keys. The Key Management screen can be reached by selecting Tools, Manage Keys as follows:

Use the Agent Key tab to set up the Static Agent Key as follows:


Use the Session Ticket Key tab to set the Static Session Ticket Key as follows:

Once these are set, you must wait for all Web Agents to synchronize and then the single sign-on will be available across all three IMEs.

Note: In addition to these three requirements, if different cookie domains are used, you must configure a cookie provider for the Web Agent. See the CA SiteMinder documentation for details. We do not plan to discuss this scenario in this book.

Sample Web Application Authorization Services

Since the vendor population actually has no access to the NeteAuto Vendor IME, we focus on the customer and employee populations.

Customer Web Application Authorization Services

NeteAuto wants to revamp its existing NeteAuto Customer Service Web site using CA Identity Manager and its built-in CA SiteMinder as the base infrastructure. To convince the customers to become registered and to pave the way to build a highly secured and successful Customer Self-Service Web site, the following are the services offered by the NeteAuto Customer IME:

■ Customer Special Interest Group

■ Customer Special Interest Group Management


SERVICE: CUSTOMER SPECIAL INTEREST GROUP

When NeteAuto customers sign up for any of the available Special Interest Groups, the Personalized Web Application Delivery delivers a separate list of items to the customer's screen as follows:

Note: This service is implemented through the Self-Subscribing Group feature. To avoid showing other Self-Subscribing Groups to the customers for our Multi-Tenancy implementation, the customer-Directory.xml has the following setting to limit the Group Names that are made available to the users:

<SelfSubscribingGroups type="INDICATEDORG"/>

SERVICE: CUSTOMER SPECIAL INTEREST GROUP MANAGEMENT

The Customer Special Interest Group Management service is required to help maintain the customer facing Special Interest Group services. The creation of a Special Interest Group includes the following:

■ Create a Self Subscribing Group under the organization “Customer”.

■ Create an Admin Task using the Category of “Car Clubs” that determines the Web contents presented to the user.

■ Create an Admin Role that includes the Admin Task with the Member Rules set to anyone who are members of the Self-Subscribing Group and none to the Scope Rules.

Customer Web Application Authorization Roles

The following existing Admin Roles are modified to provide these services:

■ Role Customer is given the Special Interest Group Subscription self-service task.

■ Role CIM Customer Service Representative is given the Special Interest Group Membership assisted service task.

■ Role CIM Customer System Manager is given the privilege to maintain Groups.


Employee Web Application Authorization Services

NeteAuto has three Identity Management systems: Employee IME, Customer IME, and Vendor IME. The employees are encouraged to sign onto the Employee Identity Management system. Through the Personalized Web Application Delivery, the employees see that the Vendor Portal and/or Customer Portal are available on their Identity Manager User Console. When they click the corresponding link, separate browser windows are launched to the designated Identity Manager User Console and the personalized Web interface appears with the help of the Identity Manager and single sign-on facilities.

To accomplish this, the following services are offered on the Employee IME:

■ Customer Portal

■ Vendor Portal

SERVICE: CUSTOMER PORTAL

Since it is awkward to display an Identity Manager User Console within another User Console, the Customer Portal service uses an instructional page and a URL to link employees to the Customer IME they have access to. The sample information page follows:

SERVICE: VENDOR PORTAL

The Vendor Portal service is implemented the same way as the Customer Portal. The sample information page follows:


Employee Web Application Authorization Roles

The following Admin Roles are modified to include these services:

■ Customer Service Representative

■ Customer Certification Manager



■ Vendor Visit Register



■ System Manager

The related Employee IME Roles now have the menu items similar to the following:


With these, the screen on a System Manager looks similar to the following:



The topics in this chapter depend heavily on the different type of roles that you can create using CA Identity Manager. Creating and designing these roles is not a task to be taken lightly. You need enough granularity to give you the functionality you need. However, high numbers of roles can have an adverse effect on performance and may lead to a requirement for additional infrastructure. Additional infrastructure means more expense. Therefore, we recommend that you perform a thorough review of existing company roles and requirements.

As the organization changes, the roles and rules also change. Maintenance of the rules must become part of the process whenever the organization changes. If department numbers are changed, the rules may need to change. A full test environment with all of the roles and rules defined is an absolute requirement.

To control access to applications, you create access roles and tasks. An access task provides access to a function in an application. An access role contains one or more access


tasks for one or more applications. When a user is assigned an access role, the user can use the functions that exist in that role. During the initial roll-out and ongoing operations, the Identity Manager Administrator and SiteMinder Policy Server Administrator must work together on the planning and implementation of access roles and tasks.

Return On Investment

CA SiteMinder is a key component of the CA Identity Manager system. CA SiteMinder helps organizations to secure their web applications by offering:

■ Reduced development costs

■ Faster application deployment

■ Increased overall system security

■ Single sign-on and sign-off

■ Meeting regulatory requirements

With Access Roles and Access Tasks, CA Identity Manager allows you to secure your Web applications through RBAC and task-based responses defined in CA SiteMinder. Due to the benefits and robust features of CA SiteMinder, you can achieve a higher return on investment (ROI) and lower total cost of ownership (TCO). For example, instead of asking your development team to develop a Web security module from scratch, you can use CA SiteMinder to protect Web resources and personalize Web content based on user entitlement returned by Identity Manager Access Roles and Access Tasks. Depending on your application, the savings can be dramatic and it can help you achieve a positive ROI in a short time.


A user can have multiple roles and each role may contain multiple tasks, which may represent actions in different applications. However, you should avoid redundant access roles and access tasks. Redundant access roles create additional CPU usage and network traffic as the same data is requested multiple times.

In addition to the typical performance tuning considerations for CA Identity Manager, you should also consider what the task-based responses should return.

CA SiteMinder administrators can specify two types of CA SiteMinder-generated response attributes:

■ SM_USER_APPLICATION_ROLES[:application id] - Returns a list of roles assigned to a user

■ SM_USER_APPLICATION_TASKS[:application id] - Returns a list of tasks a user can perform based on roles assigned to him


To limit the requested set of roles and tasks to a specific application, add the application ID to the appropriate response attribute. For example, if you create the following response attribute:

SM_USER_APPLICATION_ROLES:employee

CA SiteMinder only returns the roles that have tasks in the employee application to the Web Agent.

Note: The application ID you supply should match the application ID you supplied when you used Create Access Task in CA Identity Manager and it cannot contain any spaces or non-alphanumeric characters.

Finally since access roles are used with CA SiteMinder to protect Web applications, you should also carefully review the CA SiteMinder performance guidelines and optimize Policy Server and Web Agent performance.


Chapter 6 : Delegated Account Management As you know from reading the previous chapters, the identity used in a CA Identity Manager system is actually a computer account. Now we need to examine the number of accounts many of us have to use each day for our work and personal lives.

In this chapter, we identify the types of computer accounts people use everyday as endpoint accounts, the machines that house these accounts as managed endpoints, and the provisioning engine that actually provisions them. We take you through the management of these objects in the Namespace and Endpoint Management section.

Our provisioning engine, the eTrust Admin Server, uses a data store of its own known as the Administrative Directory. The Global User Object, also known simply as Global User, in the Administrative Directory is used to correlate accounts across all managed endpoints.

To link the provisioning engine back to our identity management system, CA Identity Manager introduces two terms: the Provisioning Directory and the Corporate Directory. The user data store we have been discussing through the previous chapters is referred as a Corporate Directory where all the corporate identities are managed. Our provisioning engine, formally known as the Provisioning Directory, got this name as it was defined as a special type of Identity Manager Directory that points to an eTrust Admin Server. Since we now have both the provisioning directory and the corporate directory in our identity management system, we need to discuss synchronizing them.

There is a difference between the Administrative Directory and the Provisioning Directory. The Administrative Directory is the data store the provisioning engine uses to perform its functions and the Provisioning Directory is the whole provisioning engine itself.

With the base infrastructure established, we discuss the role based account provisioning that uses provisioning roles and account provisioning policies. Since our identity management system is loosely coupled with the managed endpoints the provisioning engine manages, the actual accounts and the identity management system require synchronization.

The Administrator Rules of the provisioning roles provide the same account management delegation capabilities we have seen for both the Web application authorization and the management of the identity component.

Interestingly, the account services for password reset, suspension, resumption, and unlocking are actually delegated in the same way as the identity object.

We continue the chapter with sample services through our sample Employee IME.

112 Delegated Account Management

Namespace and Managed Endpoint Management

Before we drill into the discussion of the account management, it is worth while to quickly point out that you perform many of the tasks mentioned in this chapter from the provisioning engine Win32 GUI or its corresponding command line interface, etautil.

Organizations provide many different types of accounts to their employees. For example, an older Windows NT Domain account looks very different from the more modern Active Directory account from the security management point of view. We call the type of a computer account a namespace. We call a machine that has accounts to be managed by CA Identity Manager a managed endpoint.

To manage the accounts on the endpoints, you must first manage the managed endpoints. A managed endpoint is first “acquired” to allow the provisioning engine to manage it. It then needs to be explored to give the provisioning engine the needed knowledge about it. When a managed endpoint no longer needs to be managed, it can then be removed from the provisioning system.


Endpoint Management Delegation

To avoid over-management, you might give a provisioning engine administrator the DomainAdmin Admin Profile that provides the user all the privileges needed to explore all features of the provisioning engine. For a more controlled implementation, the privileges to the provisioning engine are determined by the combination of Admin Profiles and Administrative Privileges that exist on the provisioning engine.

The combination of Admin Profile and Administrative Privileges let you control:

■ Who can acquire what types of namespaces

■ Who can explore which managed endpoints

■ Who can remove which managed endpoints

■ The following screen shows a list of Admin Profiles and the Administrative Privileges the DomainAdministrator has:

An Admin Profile is a packaging tool that contains individual Administrative Privileges. Compared to individual Administrative Profiles, it provides several advantages:

■ Several administrators can be defined to a profile, and therefore, each receives the same administrative privileges.

■ The operations that an administrator is allowed to perform typically require a long list of administrative privileges. Placing them into an admin profile is less error prone as it lets you define the profile once and then apply those privileges to multiple administrators.

Acquire Managed Endpoints

Acquiring a managed endpoint refers to registering a new instance of a specific namespace for the provisioning server to manage. The registration process uses the Directory Property Sheet for the namespace. For example, suppose you have installed eTrust Admin on a Microsoft Windows NT computer named NTPC4. To manage this computer, you must now register the NTPC4 computer as a directory using the Directory Property Sheet in eTrust Admin.


To avoid creating and installing a special agent for each namespace and managed endpoint, CA Identity Manager attempts to use the native account provisioning APIs and communication protocols to accomplish the account provisioning tasks. Therefore, it relies on the native security to enforce the privileges when possible. As a result, the procedure to acquire a managed endpoint is namespace-dependent. For example, to acquire a CA-Top Secret endpoint requires the user to know the IP address, the DSI port number, the Admin ACID and its password. To acquire a Microsoft Active Directory, you need the fully-qualified machine name for the Domain Controller, the DN of your Active Directory account, and its password.

For more details on how managed endpoints of each namespace will be acquired, see the CA Identity Manager documentation.

Explore Managed Endpoints

After a managed endpoint has been acquired, you must explore it before it can be used for account management purposes. Acquiring a directory automatically populates the Administrative Directory with basic information to allow the provisioning engine to manage the endpoint. To actually manage the endpoint, the next step is to explore the endpoint to bring in the relevant structure of the endpoint.

The structure is also namespace-dependent. For example, a Microsoft Active Directory contains a hierarchical structure to hold objects like users and groups while an Oracle endpoint contains objects like accounts, packages, procedures, profiles, and roles. Earlier releases of eTrust Admin actually did not manage the Oracle package object. This is because it all depends on how the namespace is being supported.

For more details on what objects are being managed for each namespace, see the CA Identity Manager documentation.

Remove Managed Endpoints

A managed endpoint can be removed from the provisioning engine after there is no use for it. This can happen when an endpoint is no longer in service. Removing a managed endpoint also causes all the relationships it forms with other objects to be removed. However, removing an endpoint does not cause any accounts on the endpoint to be removed from the real endpoint system even though the account objects of the endpoint are no longer searchable on our provisioning engine.

Re-Explore and Authority

Because the purpose of the explore process is to understand the managed endpoints for management purposes, if you or someone else actually makes changes on their account related information without going through eTrust Admin, you can create inconsistencies between eTrust Admin and the actual state of an account. You can re-explore the managed endpoint and try to resolve the discrepancy. Your authoritative system is what you use to resolve any differences discovered.


eTrust Admin allows you to update the Administrative Directory using the native system as authoritative unconditionally. Or, you might use re-explore as an auditing tool to find out whether the process has been followed or to detect other anomalies, such as security breaches that might have occurred.

Privileges over Managed Endpoints

During the discussion of acquiring and exploring a managed endpoint, we did not discuss the privileges given to our provisioning engine. For example, when we said we could explore a managed endpoint to create the structure needed for the provisioning engine to manage the endpoint, we implied that after the acquisition, the provisioning engine already has the privileges to explore the managed endpoint. The privileges a provisioning engine has over the managed endpoints are actually namespace-dependent. The possibilities actually include authorization by proxy IDs, authorization by operator-native privileges, and authorization by the managing machines.

AUTHORIZATIONS BY PROXY IDS

Most of the out-of-box supported namespaces use the authorization by proxy IDs approach. It means the privileges the provisioning engine has depend on the proxy IDs that are used to acquire the managed endpoints. For example, if we use a usual Domain Admin account as the proxy ID of a Microsoft Active Directory to acquire an AD domain, then we know the provisioning engine will have all the privileges to create any types of account on the Active Directory. On the surface, it seems to be the right thing to do. However, we can certainly use another account that has a lesser privilege than Domain Admins so long as it allows you to handle the account provisioning needed over the Active Directory. The determination of such a proxy ID is done through both the nature of the namespace and how you want the CA Identity Manager provisioning engine to manage the endpoint. Consult the Option Guide for your managed endpoint type for more information.

AUTHORIZATIONS BY OPERATOR NATIVE PRIVILEGES

This type of authorization is commonly seen in mainframes. It means that the privileges the provisioning engine has depend on the user who is using the provisioning engine. As of this writing, the three mainframe security systems, namely CA-ACF2, CA-Top Secret, and IBM RACF, are the ones that offer this possibility. These three namespaces also support the Authorizations by Proxy IDs model.

The nature of this authorization model actually creates difficulties for certain account provisioning services, especially in the self-service arena. Those difficulties and possible solutions will be discussed separately.

AUTHORIZATIONS BY THE MANAGING MACHINES

As of this writing, the managed endpoints that use the CA proprietary CAM/CAFT technologies along with remote agents use the authorization by managing machines model. To allow the provisioning engine to manage such a system, a remote agent needs to be installed on the managed endpoint and a command that modifies a configuration file needs


to run on the managed endpoints to explicitly authorize the machines that can communicate with the CAM/CAFT transport to manage them.

Global User Object and Account Correlation

After you explore a managed endpoint, you can then start correlating these accounts to their owners. Correlation is the key that allows you to offer many of CA Identity Manager's account management services. In a real world environment, the following types of accounts might exist:

■ Personal Accounts: the accounts an individual can authenticate with and are not supposed to be shared with others.

■ Custodial Accounts: the accounts an individual controls but possibly delegates to others to use for a period of time.

■ Shared System Accounts: the accounts an individual uses but possibly shares with others. All users of the accounts share the same authentication method.

■ Indirect Shared System Accounts: the accounts that are possibly shared with others. However, individuals use their own independent authentication methods. Examples include users who share the same UID or SUID on UNIX machines.

■ Personality System Accounts: the accounts that are used by computer systems that do not require human intervention.

Each type of account is likely to be managed differently and correlated differently. As a result, sometimes you may be forced to consider giving your employees multiple identities to allow them to manage accounts under their control more effectively.

Global User Objects

Global user objects contain important information such as the person's name, global user name, account name, password settings, job title, phone number, and address similar to what we have seen in the user data store. These objects are stored in the Administrative Directory and are used to link the Identities we have been discussing. The Global User Name of a Global User object in the Administrative Directory matches the user ID of an identity on the Identity Manager server.

Correlation

While the explore task and correlate task are closely related, correlation is really a separate task. The Explore and Correlate dialog lets you do the following:

Explore

Finds the objects in a registered directory and stores references to them in the Administrative Directory.


Correlate

Attempts to associate each account on a directory (or selected container of a directory) with a global user. Correlating is optional, but is essential to many account management services.

Update

Updates global users with optional parameters determined by the attributes of the corresponding accounts.

The Create Global Users option creates a global user for each account that is not matched to an existing global user in the Administrative directory during correlation. Correlations of directories without the Create Global Users option selected do not create new global users for accounts that do not associate with pre-existing ones. Those accounts that do not correlate with an existing global user are associated with the default global user.

Update Global User and Authority

The Update global user fields option lets you populate the attributes of global user objects. Use this facility with extreme care. Before you use this feature, you need to consider your authoritative information sources and ensure that this activity does not violate your overall authoritative information control system.

When considering using the Update global user fields option, you should identify, on an attribute-by-attribute basis, the single source in your organization for each global user attribute. Ideally, these determinations are done at the identity level. A Global User Object is a link between the Corporate Directory and the provisioning engine that actually performs the provisioning functions. The source for Global User Object attributes should actually be the identity objects in the user data store. Some implementations use the eTrust Admin server for both the Corporate Directory and Provisioning Directory. In that situation, updating Global User Objects is the same as updating the identity objects. You will find a more detailed discussion in the upcoming section, “Provisioning Engine and Identity Management.”

The update feature is intended primarily as a tool to help you set up a controlled user data store the first time. The attention to a comprehensive identity management solution is recent. Many corporations may have a lot of their employee information stored in a system like Active Directory and may face delays if the corporation relies on a centralized administrator to set up user store data. Situations like this sometimes happen during a trial period of such a project.

Another possibility for this type of use happens when certain managed endpoints hold the authorities for certain types of information initially. We suggest that the backend authoritative system should redirect the feed to the identity management system and use the user data store as the authority to push the information out instead. The alternative is to stay with the existing authority system and to engineer how an explore/correlate/update procedure can be incorporated into the overall identity management system. You must determine whether to use existing systems in your organization, or to change the way your organization manages its data.


You configure which attributes are updated by Update global user fields using the Attribute Mapping tab of the Directory's properties. By default these mappings are all known attribute mappings identified by the namespace. If any directory is configured to update no global user attributes, the Update global user fields feature is disabled. If you take the time to disable attribute mapping on directories that are not the authoritative source for any attributes, no-one will accidentally update global user attributes with non-trusted values taken from an arbitrary managed directory in your organization. Clearing the attribute mapping on the Namespace properties is likely the most efficient way to disable attribute mapping for all directories of that namespace. It takes time to do this and is better to do it as part of the process to acquire a managed endpoint or better yet never use the update user field on a production system.

Note: Mapping multiple attributes or substrings of a single attribute to the same multi-valued global user attribute, such as a custom field, is not supported. In these instances, you should map each attribute or substring to a different global user custom field.

Correlation Rules

The default correlation rule attempts to match the account name from the directory to an existing global user. If this does not result in a match, the rule attempts to match the full name of the account to that of an existing global user. If this still does not result in a match and the Create Global User option is not checked, then the account is correlated to the existing default user object.

Every eTrust Admin domain contains a default user object. The default user object is associated with all accounts that are not associated with any global users. During the correlation process, the default user object draws attention to any accounts that cannot be correlated with an existing global user. After the correlation process is complete, the Message Log displays the number of accounts that were associated to the default user object, as well as those correlated to an actual global user.

You can change the correlation behavior through the domain configuration parameters. The configuration applies to all domains of the same eTrust Admin hierarchical domain structure, root and children.

The correlation attribute is the parameter that lets you customize how accounts are matched to global users during the correlate operation on non-primary directories. Once your global users are created, choose the Use existing global users option of correlate as you correlate accounts on the remaining managed directories with your global users. If you want to correlate on account properties or global user properties, other than the default properties, then you will want to change this parameter.

The correlation domain must be set to root domain for the current CA Identity Manager version.


The Correlation-Matching Algorithm

When correlating accounts on a directory, the program employs the configured correlation-matching algorithm to match each account with the existing global user objects. If the matching algorithm identifies a single matching global user, the correlation of that account is successful. The account is associated with the matched global user.

If the matching algorithm identifies no matching global user or more than one, the correlation of the account is unsuccessful. If the Create global user option is not selected, the account is instead associated with the special [default user] global user. The [default user] then becomes the temporary object to keep track of problem accounts.

Note: The formal name for a default user is [default user], where the brackets are part of the name. Use the List Accounts function on the [default user] to identify problem accounts. You can manually use Copy/Paste to copy a problem account to another global user to complete the correlation manually, as you can do if the configured correlation-matching algorithm selects the wrong global user for an account.

The default correlation-matching algorithm matches accounts to global users by comparing pre-defined account attributes against the global user's Name and Full Name attributes.

Correlation Customization

You can modify the correlation-matching algorithm through a configuration parameter called Explore and Correlate Correlation Attribute. This parameter is found in the Domain Configuration settings on the System task frame. The default used when correlating accounts with global users is GlobalUserName and FullName.

In Update Global User and Authority, we described the use of the Attribute Mapping tab of the Directory properties. This tab defines which global user attributes are updated when you perform Update Global User Fields. The Use Custom Settings check box on this tab lets you define the mappings explicitly (by means of the Add button). By default, mappings are those pre-defined by the namespace option, but updated to take into account any mappings defined by a custom correlation-matching algorithm, as described in Customize the Correlation Process.

Resolve Correlation Difficulties

The presence of a large number of accounts associated to [default user] sometimes indicates a problem with the account or global user attributes. For example, if you configured your correlation matching algorithm to match accounts to global user by the user's Full Name but your global users and accounts do not represent full name the same way, many accounts will not match existing global users and will be correlated to [default user].

You might think a systematic change to each account's full name or to each global user's full name will correct the mismatch. However, a re-run of correlate on a directory only attempts to correlate accounts that are not correlated. To have these accounts reconsidered


by correlate, you must first disassociate (un-correlate) the accounts, then re-run the correlate operation.

There are two ways to disassociate accounts. The direct way is to select all the accounts from the list of accounts belonging to [default user] and select Remove Account from User from the menu. This is difficult because you typically have hundreds or thousands of accounts to select and remove. Even if you remove 50 accounts in this manner at a time, it can be quite time-consuming.

The simpler way must be done very carefully. It is to delete the [default user] global user without deleting the associated accounts. We have seen disasters happen when inexperienced administrators use this feature. Use the Delete menu item, not the Delete with Accounts menu item, to delete the [default user]. When a global user is deleted, its accounts become uncorrelated and, therefore, open for consideration the next time the accounts directory is re-correlated. You can recreate the [default user] manually or allow correlate to recreate it when necessary.

Re-Explore and Correlate

After the original explore and correlate has been done, the re-explore needs to be done under the guidance of your authoritative system as described in "Re-Explore and Authority."

We recommend that you perform the explore task independently from the correlate task to give you better control over their behaviors. The newly discovered un-correlated accounts must first go through the auditing process, and then they may be correlated to their owners as appropriate.

Uncorrelated (Orphaned) Accounts

Every eTrust Admin domain contains a default user object, called [default user], to group all accounts that the correlate function is not able to associate with any global users. The formal name for a default user is [default user], where the brackets are part of the name.

This object identifies accounts that cannot be correlated with an existing global user because there was no matching global user or because there was more than one matching global user. When correlation completes, a message displays the number of accounts that were associated to the default user object rather than correlated to an actual global user.

Unquestionably, the un-correlated accounts deserve your attention. Here is a list of interesting ideas you may want to consider:

CHANGE CORRELATION CRITERIA AND RE-CORRELATE

We have seen examples where people use different naming schemes on the same managed endpoint during transition periods. You may have to go through a few iterations to get it right.


RENAME THE [DEFAULT USER] AND CREATE A NEW ONE

You may want to rename the existing [default user] to another name (perhaps with the date appended to the account name), such as [default user 031607]. The uncorrelated accounts will then be maintained and identifiable until you can resolve the correlation problem. You can then create a new [default user] to allow another explore to continue to work. Doing these in a systematic manner allows you to create a process to manage your re-explore activities.

SPECIAL GLOBAL USER OBJECT

Sometimes accounts on a managed endpoint are not tied to a single person as we pointed out early this chapter, for example, system accounts or accounts that provide identities to processes, services, or background tasks. Some namespaces give you the option of not managing these accounts with eTrust Admin to prevent a catastrophe. If that option is not available or you choose not to use it, system accounts are likely to be associated to [default user] or its equivalent. Some implementations use special Global User Objects to hold these accounts. We recommend that these special Global User Objects should have the Restricted check box checked so that account attribute changes are not propagated from this global user.

Provisioning Engine and Identity Management

We now need to tie the provisioning system back to our identity management system.

Corporate Directory and Provisioning Directory

An IME starts with a single user data store. This user data store is also referred as a Corporate Directory. A Corporate Directory can be any of the defined Identity Manager Directories including an eTrust Admin Server. To give an IME the ability to handle account provisioning, you first need to assign the environment a provisioning directory. A provisioning directory is an eTrust Admin Server user data store that is used for provisioning. This assignment is done through the Identity Manager Management Console and requires the application server to be re-started.

The following is a list of commonly seen combinations:

■ IME has no provisioning capability

■ IME uses a Corporate Directory that is different from the Provisioning Directory

■ IME uses the same eTrust Admin Server as both the Corporate Directory and Provisioning Directory

The eTrust Admin Server that is used as a Provisioning Directory is often referred as the Provisioning Engine. It handles all aspects of communication between CA Identity Manager, the actual endpoints, and the role based access control account provisioning.


CREATE THE ETRUST ADMIN USER DATA STORE

See Chapter 2 for more information about using eTrust Admin Server as a user data store. The following screen shows how you might create your user data store:

Note: Instead of using the etaadmin Global User Object, we suggest that you create and use a caimproxy Global User Object on the provisioning server with a password, DomainAdmininistrator Admin Profiles, and disabled periodical password expiration.

Provisioning Directory and Corporate User

To assign a provisioning directory to an IME, you must identify a special identity on the Corporate Directory to act as the Corporate User. The Corporate User is the identity used by CA Identity Manager for inbound synchronization purposes. This user does not need a password as no one should actually use it.

This user, however, needs special privileges on the CA Identity Manager. These special privileges are described in the out-of-box example Admin Roles: “Provisioning Synchronization Manager”.


The following image shows the Corporate User definition in the Provisioning Directory configuration property.

User Data Store and Global User Objects Synchronization

The Global user name of a Global User Object in the Administrative Directory is the link to an identity stored in the user data store. This is, however, a loosely-coupled relationship. As we discussed in the Identity Management/Identity Self-Service part of this book, the attributes of an identity can be changed through the user console Web interface. However, a Global User Object can be manipulated independently through the correlation activities. To keep the Identities and the Global User Objects in sync, we rely on the Inbound and Outbound Synchronization facilities.

Before we dive into the details of the Inbound and Outbound Synchronization, it is worthwhile to highlight some of the special features. The inbound synchronization starts from events occurring on the provisioning engine. They can trigger the corresponding identities to be created on the user data store under a designated container. The outbound synchronization starts from events occurring on the user console or the TEWS interface. They do not always trigger the creation of a global user.

Note: Only identities that have been granted the Provisioning Roles trigger the outbound synchronization to attempt to create a corresponding Global User Object.


Identity and Global User Attribute Mappings

While we are on the subject of synchronization, we need to first point out how we can map the attributes between an identity and a global user object. This is done through the provisioning directory property screen on the Identity Manager Management Console as follows:

Inbound Synchronization

Inbound synchronization keeps CA Identity Manager up to date with changes that occur in the provisioning directory. Changes in the provisioning directory include those made using eTrust Admin Manager or systems with connectors to eTrust Admin.

CA Identity Manager installs a callback mechanism in eTrust Admin. When certain events occur in eTrust Admin, the callback mechanism initiates synchronization in CA Identity Manager. The synchronization uses the attribute mappings and inbound mappings defined on the Provisioning screen of the Identity Manager Management Console.

For inbound synchronization, CA Identity Manager automatically uses a specific user account called the corporate user. No user logs into this account because it is used internally by Identity Manager. However, you need to create this account and give it the appropriate tasks.

You can define the tasks necessary for synchronization or use the tasks included in the Provisioning Synchronization Manager role. The default tasks for synchronization are:

■ Provisioning Create User

■ Provisioning Enable/Disable User

■ Provisioning Modify User

■ These tasks are mapped to inbound events on the Provisioning screen of the Identity Manager Management Console a follows:


Note: The POST_DELETE_GLOBAL_USER is usually not mapped as we do not want the removal of a Global User Object to impact the existence of an identity as we are using Identity Manager to drive the provisioning engine, not the other way around. The use of the Inbound synchronization should be planned carefully.

Outbound Synchronization

Outbound synchronization involves using CA Identity Manager to create and update Global User Objects in the provisioning directory. CA Identity Manager does not trigger a Global User Object to be created in the Administrative Directory just because an identity is created. It only does so when a provisioning role membership is being assigned to an Identity. This relationship needs to be stored in the Administrative Directory. Without the corresponding Global User Object, the membership information can not be retained.

The creation of a Global User Object caused by CA Identity Manager also pushes a password to the Administrative Directory. The user can use that password to log into the eTrust Admin Win32 GUI if authorized.


Updates to existing Global User Objects occur when you use an Admin Task that modifies users. This includes DisableUserEvent, EnableUserEvent, ModifyUserEvent, and ResetPasswordEvent per the Outbound Mappings configuration that follows:

If a Global User Object exists without a corresponding identity in the IME Corporate Directory, you can create the identity in the Identity Manager User Console and the link between them is automatically honored. The Identity to Global User attribute mappings are also put into effect immediately.

By default, outbound synchronization is configured for the Delete User event. When you delete a user in CA Identity Manager, the Global User Object is also deleted along with all the accounts that are correlated to the Global User Object.

Delegated Account Provisioning

Account provisioning is actually done through assigning provisioning roles to identities. In the details given in the next few topics, we recommend that you use the eTrust Admin Win32 GUI for managing a number of account provisioning related objects. For the users who are given the privileges, you must set them up with the appropriate admin profiles similar to the previous discussion in "Delegated Endpoint Management."

Provisioning Roles and Authorities

Similar to both admin roles and access roles, a provisioning role object has administrator rules and owner rules. A provisioning role, however, does not have a member rules. This is because account provisioning includes actions, not just status. Being a member of a provisioning role means a related account provisioning event has already happened. CA Identity Manager does let you provide an identity provisioning role for the accounts the identity may already have. When that happens, the new roles tend to provide new privileges to the accounts that already exist.


Note: An account provisioned through provisioning roles is automatically correlated to the corresponding Global User Object in the Administrative Directory and therefore the identity in the user data store.

PROVISIONING ROLE ADMINISTRATOR RULE

The administrator rules give CA Identity Manager the same powerful tool to delegate account provisioning privileges. An administrator for a provisioning role gives the identity the privileges to assign the provisioning role membership to other identities in scope and causes the corresponding accounts or extra privileges to be provisioned. The revoking of the provisioning role membership can also result in the removal of those accounts or privileges.

As a result, you should make the system administrators of the managed endpoints the administrators of the appropriate provisioning roles for them to continue to provisioning accounts to the users. With this tool, these administrators can continue to do their jobs without having to use the native tools to ensure that the provisioning tasks are always being accomplished consistently. At the same time, an added benefit is that they always know what accounts a user has.

PROVISIONING ROLE OWNER RULE

A provisioning role owner may be the business persons who work with their supporting staff to decide at the business level what provisioning roles are needed to support a business application. Provisioning roles are then created to allow the support staff to define provisioning role administrators through Delegated Role Administration.

PROVISIONING ROLES AND ADMINISTRATIVE DIRECTORY

Similar to the relationship of identities and Global User Objects, a provisioning role also has a corresponding role object stored in the Provisioning Administrative Directory. The difference is that an identity object resides on the user data store, while a provisioning role resides on the Policy Data Store and can actually be exported into the RoleDefinitions.xml file. We recommend that you create a provisioning role from the CA Identity Manager User Console or its equivalent. From the User Console, the administrator and owner rules can be set up to allow the provisioning role to be managed using the Delegated Role Administration facility.

We do, however, suggest that you do not manage the provisioning policies through User Console for CA Identity Manager r81. SP1 but use the eTrust Admin Win32 GUI. More details about this subject are discussed in the next section. The out-of-box sample for Provisioning Role Admin Tasks allows you to view and modify the provisioning policies a provisioning role can have. Simply remove or hide the Provisioning Policies tab from the Admin Tasks that allow you to specify the policies. This is because a number of other important account policies features are not yet available through the User Console.


Note: For the provisioning roles that are created through the eTrust Admin Win32 GUI directly, they must first be given the Owner Rule using the out-of-box sample “Reset Provisioning Role Owners” Admin Task before you can manage them through the User Console.

Provisioning Policies

A provisioning policy is a template that determines how an account is provisioned. A provisioning policy is namespace-dependent. From the following sample Active Directory policy, you can see that a policy can be quite comprehensive and complex:

RULE STRING

The notation of %UN%, %UF%, and so on are rule strings that are replaced with the values from corresponding Global User Object during the actual provisioning process. For example, the %UN% is the Global user name; the %UF% is the First Name of a Global User Object. A rule string like “%UL:1,3%%UF:1,2%” takes the first three characters of the Global User last name and the first two characters of the first name to form a new value. %$func(<arg1>, …, <argn>)% and %*$func(<arg1>, …, <argn>)% return single value and multiple values for a function provided in a program exit. “%#ldap-attribute%” returns


an explicit Global User attribute according to its LDAP attribute name. See the CA Identity Manager documentation for further details about available rule strings.

Note; Values like first name and last name on the Global User Objects can be populated from the identity in the user data store through the outbound synchronization setting.

REQUIRED ATTRIBUTES

A required attribute is demanded by the namespace. The lack of such attributes causes the provisioning of an account to fail. By convention, the required attributes are marked with an asterisk as shown on the sample Active Directory policy.

MANAGED ENDPOINT SUPPLIED ATTRIBUTES

To help enforce integrity, the managed endpoint dependent attributes are only available when a managed endpoint (also knows as a directory) is associated with the policy. For example, unless you know which AD-managed endpoint this policy applies to, you would not know what groups are available to be set on the policy. This is also part of the reason why a managed endpoint must be explored first before it can be managed. The explore is the action to make information like groups available for the account policy.

CAPABILITY ATTRIBUTES

Account attributes like groups are known as capability attributes as they do impact the privileges an account has on the managed endpoint. The designation of a capability attribute is namespace-dependent and is determined by the design of the connectors.

Capability attributes play significant roles when a policy is marked as a Strong Synchronization Policy. More details about strong synchronization are provided later in this chapter.

OBJECTS RELATIONSHIP AND ACCOUNT PROVISIONING

The Roles tab shows and configures which provisioning roles this account provisioning policy is part of. The relationship between provisioning roles and provisioning policies are many-to-many. So is the relationship between account provisioning policies and directories (that is, managed endpoints). This relationship is viewed or set through the Directories tab.

At the time the Provisioning Engine actually performs account provisioning, it collects all the provisioning roles a Global User Object has based on the information in the Administrative Directory. It then calculates all the combined account provisioning policies to determine how many accounts are to be provisioned and how each account is provisioned with the possibility of multiple policies applied to the same account.


Global User and Account Synchronizations

A Global User Object becomes out-of-sync with its roles and policies when one or more of the following occur:

■ Missing accounts

■ Accounts not assigned to the required account policies

■ Extra accounts

■ Accounts assigned to extra account policies

From the Win32 GUI, you can perform a Check User Synchronization task to report these conditions. A separate Synchronize User with Roles task with the options of Adding Missing Accounts and/or Deleting Extra Accounts can also be used to correct the condition. A potentially expensive ldapsearch command similar to the following can be used to interrogate all the Global Users on the system:

ldapsearch -b "eTGlobalUserContainerName=Global Users,eTNamespaceName=CommonObjects,dc=Forward,dc=eta" -h localhost -p 20389 -D "eTGlobalUserName=etaadmin,eTGlobalUserContainerName=Global Users,eTNamespaceName=CommonObjects,dc=Forward,dc=eta" -w password (eTGlobalUserName=*) eTPolicyDN eTSyncDelete eTSyncUsers eTSyncUserDN eTSyncDetail

The output of this command returns entries for all the Global User Objects. You need only pay attention to those with eTSyncDetail values.

In addition, you can also Check Account Synchronization. Check account synchronization checks the accounts to verify if the capability attributes are compliant with the policy rules. This action identifies which accounts are out-of-sync with the policies to which they are assigned. Likewise, a separate Synchronize Account with Policies task can be performed to correct the issues. The following is another potentially expensive ldapsearch command that can help you obtain the same information:

ldapsearch -b "eTGlobalUserContainerName=Global Users,eTNamespaceName=CommonObjects,dc=Forward,dc=eta" -h localhost -p 20389 -D "eTGlobalUserName=etaadmin,eTGlobalUserContainerName=Global Users,eTNamespaceName=CommonObjects,dc=Forward,dc=eta" -w password (eTGlobalUserName=*) eTSyncAccounts

The output of this command returns all Global User Objects. You need only pay attention to those with no eTWarningMsg entries.

Note: In the given ldapsearch examples, you need to replace the italicized words with your own specific values:


STRONG SYNCHRONIZATION VERSUS WEAK SYNCHRONIZATION

Strong synchronization is a feature CA Identity Manager offers to allow a highly secure environment to tie down their account privileges. For accounts that have more privileges, expressed in the capability attribute discussed earlier, than what the policies that have applied to it, the extra privileges are removed as a result of an account and policies synchronization.

Since the strong synchronization has such an impact to the accounts, it really needs to be well-planned to prevent the accidental removal of necessary privileges for the production system to function.

Most implementations at the early stages tend to stay with weak synchronization, which means the account/policies synchronization only makes sure the accounts possess the minimal privileges specified on the policies, but does not remove any additional ones.

For more detail about strong synchronization, see the CA Identity Manager documentation.

Identity Account Synchronization Events

Global User and account synchronization occurs at the Provisioning Engine level. For an identity management driven account management system, we rely on the CA Identity Manager User and Account Synchronization Events feature.

USER SYNCHRONIZATION

User Synchronization triggers the identity policy to be evaluated. During user synchronization, an identity policy assigns provisioning roles membership to an identity and causes accounts to be provisioned. By setting the Set User Synchronization option to On task completion or On every event will cause the identity policy to be evaluated as the event occurs. Identity policy is discussed in more depth in Chapter 8.


ACCOUNT SYNCHRONIZATION

There are actually three types of account synchronizations, account status, account password, and account policies. Here, we focus on the account policies. Account status and account password are described later in this chapter.

The account policies-related account synchronization causes a different version of the Global User and account synchronizations discussed previously to be sent to the Provisioning Engine. Instead of asking the Provisioning Engine to synchronize the corresponding Global User Object with all the roles, the account synchronization event actually takes two parameters, the Global User Object and a provisioning role, and only considers involving those activities that are related to the specified provisioning role.

To allow the account provisioning to function automatically, you need to have the Account Synchronization set to On every event for any of the Admin Tasks that would impact the provisioning roles memberships. Or, you can manually do the synchronization from with the Win32 GUI or its equivalent. The Primary Objects on these Admin Tasks are either User or Provisioning Role.

Provisioning Engineering

The complexities of the provisioning roles design, provisioning policies design and the combination of the two can easily create the need for provisioning engineering to do the job right. Growing from the earlier discussion of role engineering, the added complexities include:

■ Provisioning Policies Design

■ Weak versus Strong Account Synchronization

■ Identity Policies (to be discussed in Chapter 8) that handle the automation of assigning Provisioning Roles membership to users.


Delegated Account Services

After you have correlated the accounts to their rightful owners, you can consider offering account services that include account password change, suspension, resumption, and unlocking services, which you can configure using a page similar to the following:

Traditionally, issues like these are usually resolved by first contacting the help desk, and then eventually done by Help Desk personnel or sometimes by special support groups of the managed endpoints. With CA Identity Manager, these tasks have become a lot easier. First, all of the accounts are gathered together and one can easily provide help without having to possess the special knowledge of all the platforms that are involved. Secondly, the low technical knowledge requirement actually makes it easy to distribute the workload among employees.

Looking back to our discussion on the assisted identity services in "Delegated Identity Management" chapter, we can now confidently provide Supervisor Assisted Account Services, Supervisor Delegation Assisted Account Services, and Help Desk Assisted Account Services without having to fear the lack of special knowledge of the ones who offer help.

Identity/Account Status Propagation

Account services can be applied to the accounts of their owners individually or as a group. The first application for this concept is related to the enabling or disabling of an identity.

For an identity management system that also offers account provisioning services, a legitimate question is to ask whether the enable/disable of an identity needs to trigger the same for all the accounts the individual may have. This depends on your organization's policies. The Account Synchronization setting on the Admin Task determines the behavior. The primary object on these Admin Tasks is the user.

The types of the accounts the identities possess need to be considered when setting up the policies. For example, you may not want to lightly cause the system accounts to be disabled. Since you may actually want to give the users multiple identities to better manage these accounts, your policies are likely to be designed around the different types of identities you need to manage.


Password Synchronization and Propagation

It is debatable whether it is a good idea to synchronize all the account passwords a user has. From the security point of view, one can argue that the compromise of one password might allow intruders to gain access to all accounts the victim has. Another argument is that synchronizing passwords forces you to use the least strict password policy across all the different types of managed endpoints.

On the practical side, even when there are only a few passwords to juggle, many users have a difficult time remembering them. As a result, many organizations actually apply more restrictive policies to the users who have access to more critical systems and allow the general public to have relaxed policies.

PASSWORD PROPAGATION

Password propagation is probably a better term than password synchronization. To synchronize passwords, we first need to identify the sources where the changes start and take the changes to all the places where passwords also exist and make them all the same. Therefore, all the passwords are actually replicating to each other automatically, and we must have a way to capture the new password from the origin of the change and then propagate it to other places.

The CA Identity Manager Provisioning Engine infrastructure was designed to honor the native account provisioning APIs. As a result, CA Identity Manager has only a few remote agents to support namespaces that do not offer remote account provisioning APIs. Based on this design, the possibilities of capturing password changes at the managed endpoint level are limited to Microsoft Windows, UNIX PAM, eTrust Access Control, CA ACF2, and CA Top Secret. In particular, a Microsoft compliant password exit is provided to capture Domain password changes to Microsoft Active Directory and Windows NT Domains.

CA Identity Manager can be configured so that when users reset their own passwords on the User Console, the same password can be pushed through the Provisioning Engine to all the accounts the users have. To do this, the Account Synchronization at the Admin Task level needs to be set to happen on every event.

If you are considering account password synchronization, you need to pay attention to all the possible Admin Tasks where the password could be set and decide whether you actually want the particular task to synchronize passwords. The following is a list of examples taken from our three IMEs:

■ Identity Self Service Password Reset

■ Help Desk Assisted Password Reset

■ Supervisor Assisted Password Reset

■ Supervisor Delegation Assisted Password Reset

■ Self Authentication


■ Password Expiration (Include all possible scenarios)

We have seen examples where organizations initiate password propagation if individuals make password changes themselves. We have also seen reservations about the same behavior, especially if the Help Desk in an organization initiates changes as password expire. More importantly, there are concerns that propagating passwords requires additional auditing controls to be in place.

Ultimately, the decisions around password propagation are determined by a combination of organizational policies and technical capabilities.

Sample Delegated Account Management Services

NeteAuto has no immediate plan to provide account provisioning services to the customer and vendor populations. The organization does want to offer vendor visitor access over the NeteAuto corporate network. The possible scenario is to offer the vendor visitor a login ID and password with can be used to authenticate on NeteAuto proxy servers.

In this chapter, we only discuss the services and roles that are designed for the Employee IME.

Employee Delegated Account Management Services

NeteAuto Employee Delegated Account Management services provide delegated account provisioning services to the employees. To accomplish the goals, the following services are provided:

■ Account Provisioning Engineering

■ Account Provisioning

■ Supervisor Assisted Account Service

■ Supervisor Delegation Assisted Account Service

■ Help Desk Assisted Account Service

■ Account Management Related System Management

The Account Provisioning Engineering service uses the RBAC approach to determine what the different account provisioning possibilities are. Since there can be so many systems supporting so many business applications, the service can have many sub-projects to work with different business folks to actually get the job done.

The Account Provisioning services actually provision accounts to employees by assigning them the provisioning role membership.


The various assisted Account Services are designed to help the employees' need to suspend, resume, password reset, and unlock services at the individual account level.

SERVICE: ACCOUNT PROVISIONING ENGINEERING

Account Provisioning Engineering provides provisioning role and policies engineering services including maintaining all the provisioning roles and provisioning policies. The individuals who provide this service use the Identity Manager User Console to create provisioning roles and then use the eTrust Admin Win32 GUI to perform all the provisioning policies related activities plus assigning provisioning policies to provisioning roles.

To do this job right, the engineer who performs this job must work with the business folks who actually own the systems and business applications. The Account Provisioning Engineers do not actually perform account provisioning for the employees. Instead, an Account Provisioning engineer creates provisioning roles using the EIM Provisioning Role Owner Admin Role in the Owner Rule and EIM Provisioning Role Administrator Admin Role in the Administrator Rule. As a result, the individuals who are performing this service must have the basic RBAC training.

SERVICE: ACCOUNT PROVISIONING

The account provisioning service helps provision accounts to individuals using pre-determined provisioning roles. To provisioning accounts, a Provisioning Role Administrator manually assigns a provisioning role membership to an identity. Consider the following:

■ Provisioning roles can actually have different administrator rules and therefore be administrated by different sets of individuals.

■ To help automate the account provisioning service you can use the rule-based facilities available through identity policies described in Chapter 8.

SERVICE: SUPERVISOR ASSISTED ACCOUNT SERVICE

In addition to the Delegated Identity Management service, supervisors can provide account services to their employees.

SERVICE: SUPERVISOR DELEGATION ASSISTED ACCOUNT SERVICE

In addition to the Delegated Identity Management service, supervisor delegations can provide account services to their colleagues.

SERVICE: HELP DESK ASSISTED ACCOUNT SERVICE

In addition to the Delegated Identity Management service, the Help Desk can provide account services to all employees.


SERVICE: ACCOUNT MANAGEMENT RELATED SYSTEM MANAGEMENT

This service covers the management and maintenance for the eTrust Admin Server (Provisioning Engine) infrastructure.

Employee Delegated Account Management Roles

To provide the Delegated Account Management services, the Employee IME needs to add the following admin roles:

■ EIM Provisioning Role Owner

■ EIM Provisioning Role Administrator

■ Provisioning Synchronization Manager (CorpUser)

The following roles need to be modified to include the new Admin Tasks to allow them to perform the necessary duties.

■ Supervisor

■ Supervisor Delegation

■ Help Desk

ROLE: EIM SUPERVISOR

EIM Supervisor was first defined in Delegated Identity Management. Here, we give the supervisors additional privileges to help provide account services to their direct reports.

ROLE: EIM SUPERVISOR DELEGATION

EIM Supervisor Delegation was first defined in Delegated Identity Management. Here, we give the supervisors additional privileges to help provide account services to their colleagues.

ROLE: EIM HELP DESK

EIM Help Desk was first defined in Delegated Identity Management. Here, we give the supervisors additional privileges to help provide account services to all employees.


ROLE: EIM PROVISIONING ROLE OWNER

Provisioning Roles Owners deliver the account provisioning engineering services. They use the Identity Manager User Console to maintain provisioning roles definitions and use the eTrust Admin Win32 GUI to handle the provisioning account policies, including assigning account provisioning policies to the provisioning roles.

Notes:

■ As a matter of procedure, a Provisioning Role Owner uses the Provisioning Role Owner Admin Role for the Owner Rule for both new provisioning roles and roles that need to have their owners reset.

■ Likewise, Provisioning Role Owner sets the administrator rule always to Provisioning Role Administrator.

Member Rules


■ Anyone who has the “EIM Provisioning Role Owner” value in the multi-value attribute “Admin roles.”

■ Scope Rules: User (organization Employee and lower); Group one; Organization none; Access none.

ROLE: EIM PROVISIONING ROLE ADMINISTRATOR

This role helps handle account provisioning services to employees by managing the provisioning role membership.


Member Rules


■ Anyone who has the “EIM Provisioning Role Administrator” value in the multi-value attribute “Admin roles.”

■ Scope Rules: User ( organization “Employee” and lower); Group, Organization, Access: none.

Administrator Rules



Note: To achieve and automate the RBAC Provisioning Role assignments, you must use the Identity Policies discussed in Chapter 8.

ADMINISTRATOR RULES



ROLE: PROVISIONING SYNCHRONIZATION MANAGER

The Provisioning Synchronization Manager is a system role used to perform the inbound synchronization.

Member Rules


■ User ID = “CorpUser”

■ Scope Rules: User (organization Employee and lower); Group none; Organization none; Access none.


Support Non-Standard Namespaces

The CA Identity Manager provisioning engine is shipped with a number of out-of-the-box namespaces. In the real world, we occasionally see that certain off-the-shelf commercial namespaces are not supported. It is also almost certain that it does not support your own custom applications.


eTrust Admin is shipped with an SDK that lets you develop the support for the non-standard namespaces. The commonly seen projects include:

■ Namespace API Based: this type of project is usually done using the base SDK example and relies on the namespace API to provide the communication between the Distributed Connector Server and the managed endpoint system.

■ LDAP Based: the eTrust Admin SDK comes with an extensible LDAP kit that uses a configuration file to add the support of additional LDAP object classes and attributes. A set of easy-to-use utilities can convert the configuration files into required DLL and data files.

■ ODBC Based: the eTrust Admin SDK provides an ODBC based example that can be used as a model to quickly implement ODBC-based custom connectors. The example code provides the generic ODBC tools to shorten the development effort.

DISTRIBUTED CONNECTOR SERVER

The recent introduction of the Distributed Connector Server has allowed us to put a custom developed namespace on its own Distributed Connector Server. This gives the custom made connector the opportunity to mature without disabling other fully tested connectors should it ever crash because of quality issues.

CONNECTOR XPRESS

Connector Xpress is another new feature designed to reduce the need for developing custom connectors. This feature is continuing to be enhanced to add more features. Appendix I gives an example of how you can use it.


The provisioning directory is a LDAP directory. You can secure the communication between the CA Identity Manager server and the provisioning directory by setting Security Connection to TRUE when the provisioning directory is created from the Identity Manager Management Console. This configuration forces a Secure Sockets Layer (SSL) connection to the provisioning directory.

eTrust Admin can manage many different types of endpoints. It is also possible to secure the communication between the eTrust Admin server and the endpoints. For example, an Active Directory managed by eTrust Admin can be configured to use LDAP with SSL or LDAP without SSL. In a real word implementation, we recommend LDAP with SSL encryption as the communication channel.

User Interface Customization

In the current release (CA Identity Manager r8.1 SP1), the user Account tab displays two types of account attributes: primary attributes and secondary attributes. Primary attributes include Account Name, Endpoint Type, Endpoint and Source. Secondary attributes include


Suspended, Locked and Password (Indicates whether an administrator changed the account password). If you want to retrieve other account information and display it in the Identity Manager User Console, you can write a logical attribute handler (LAH) to accomplish the goal.


WHERE TO STORE USER INFORMATION

Before the initial roll-out, you must decide where to store user information. If a provisioning directory is required in your system, you have the following options:

■ Store all information in a single eTrust Admin Administrative Directory

■ Store user information in a corporate directory, and user account and provisioning information in a provisioning directory.

Another consideration is whether your users reside in one user store. If so, you need to create multiple Identity Manager Directories and IMEs to manage these users. As an alternative, you can use eTrust Admin to manage these user directories. Then you use CA Identity Manager to directly manage the eTrust Admin Administrative directory and use the provisioning server to indirectly manage the users and accounts in the enterprise user stores.

IMPORT USERS INTO A NEW USER STORE

After you decide how to store user data, you may need to import users from one store to another. Depending on your implementation, you can use CA Identity Manager or eTrust Admin to import users. After importing users into a new user store, you can use identity policies to apply changes to imported users. Identity policies are covered in more detail in Chapter 8 of this book.

From the CA Identity Manager side, using TEWS is one of the options to import users. However, the security processing and business logic processing caused by identity policies processing may cause performance issues.

From the eTrust Admin side, you can use its batch utility (etautil) or the explore/correlate process to add users in the eTrust Admin directory. Inbound synchronization must be used to add users in the corporate directory if it's separated from the provisioning directory, and to honor identity policies.


With the help from the provisioning engine, eTrust Admin, CA's identity management solution can help organizations to:

■ Achieve operational efficiency

■ Meet regulatory compliance


■ Reduce costs

■ Mitigate risks

■ Improve service

Similar to delegated identity management, the delegated account management feature allows Help Desk or delegated administrators to quickly look up user account information and provide the services requested. Since an average user in a medium-to-large organization often has multiple accounts, the delegated account management feature allows authorized people to manage all of these accounts in a centralized application rather than in each endpoint in the organization. With account synchronization, it can save up to 15-30 minutes for each customer request. For a 10,000 employee organization, even if each user has only 1 request per year, that is 2,500-5,000 hours saved.

Using provisioning policies, auditing and reporting features, organizations can reduce their security risk and meet government compliance requirements. The consequence of not implementing the account management may be a serious security breach and compliance violation, which can significantly impact an organization's bottom line.

Deployment and Performance Considerations

For Delegated Account Management purposes, our deployment considerations need to go beyond what we have for Identity Management. The introduction of the Provisioning Engines now adds components like Provisioning Services, Superagent Services, and the Administrative Directory. Our experience shows that the tuning of the Administrative Directory has yielded significant performance improvements. The following are some of the important tuning areas. See CA Identity Manager and CA Directory documentation for more information:

■ Use the eTrust Directory DXCache for user attributes referenced by IM policies

■ Add additional indices, if necessary, for user attributes referenced by IM policies

■ Increase the number of available connections to the Admin Repository database

■ Tune the Ingres database that is used by the eTrust Directory

Also keep in mind that only those corporate users that require provisioning need to have a representation in the provisioning directory. In many cases, this is a subset of the users in the corporate user data store. And you can also control what events should trigger synchronization. Since provisioning is a relatively expensive process, reducing unnecessary traffic between the CA Identity Manager server and the provisioning server can help to improve the system's overall performance.

Patches and Upgrades

With the general patches and upgrades consideration stated in the Introduction chapter in mind, we focus on the special patches and upgrades need of the provisioning infrastructure of the CA Identity Manager.


The patches and upgrades of the provisioning engine can be approached from the programs that run to do things and the data these programs use to do things. In other words, you can break the upgrade of the provisioning engines into the four steps:

1. Break the Link between the Programs and the Data

2. Upgrade/Patch the Programs

3. Upgrade/Patch the Data (the Administrative Directory)

4. Re-establish the Link between the Programs and Data

Using this approach, we have seen implementations rebuild some of the eTrust Admin Servers and link them back to already upgraded data instead of trying to upgrade both the data and the programs on all the machines.

The challenge of an eTrust Admin Server upgrade is caused in part by the way it uses LDAP. With the need to support all perceivable namespaces, the original design chose to use multiple custom LDAP object classes for each namespace. Over time, the product development has seen the need to upgrade the base data structure and the need to update the original LDAP schema definitions. As a result, we have seen that it demands more attention for upgrades that involve custom namespaces.


ADMINISTRATIVE DIRECTORY MAINTENANCE

Explore and correlate activities can trigger a lot of objects to be added or removed from the Administrative Directory. Because the Administrative Directory is an LDAP database, we recommend that you tune the database after such activities. Instead of having to remember to tune the database manually, it is a common practice to use scheduled maintenance jobs to automate this task.

Note: Directory exploration and account correlation are resource-intensive operations that establish and modify the user-management infrastructure used by all subsequent requests. To ensure the integrity of the data assembled by exploration and correlation, subsequent requests to the eTrust Admin server can be queued for processing until the completion of the exploration and correlation. We recommend that you run the Explore, Correlate, and Update steps individually and use the dxtunedb utility to tune the database after each step to reduce your explore and correlate time.


Chapter 7 : Account Self-Service Now that we have established the Delegated Account Management system, the computer accounts individuals have are correlated to the owners. Minimally, the Help Desk can locate all these accounts and provide assisted account services. You can consider offering the Account Self-Service without waiting for any of the services mentioned in the previous chapters are fully implemented. The minimum prerequisites for these services are a basic Identity Self-Service, the Account Correlation Service, and then the adequate infrastructure.

CA Identity Manager account self-service has evolved over the years. From the product documentation, online help, and some of the CA engineers you may have contact with in Support, you might hear about technologies like SAWI/DAWI, IAM Self-Service, and CA Identity Manager Account Self-Service. In this book, we focus on the latest CA Identity Manager Account Self-Service as it is the stated direction for CA Identity Manager.

The Account Self-Service is generally considered an extension to the Identity Self-Service. The common services include:

■ Account Services Self-Help

■ Request Account Privileges of Interest

In this chapter, we also highlight the CA Identity Manager Workflow feature and how you can use it to handle the approval process required for the requesting extra account privileges.

Account Service Self-Help

Similar to Identity Self-Service, after we have established the ability to offer the various assisted Account Service, the next service to consider is the Account Service Self-Help. The technical prerequisites for this service include only the Identity Self-Service and the Account Correlation Service.

In Global User Object and Account Correlation in the previous chapter, we pointed out that there were various types of accounts an individual may need to use or have control over, namely Personal Accounts, Custodial Accounts, Shared System Accounts, Indirect Shared System Accounts, and Personality System Accounts. Of these, our interest lies primarily on the Personal Accounts and Custodial Accounts. The usual suggestion is that individuals should have an identity that correlates to all the personal accounts and then use a second identity to own all the custodial accounts. This approach allows individuals to have better control over their personal accounts and avoids the hassle of having to locate these accounts among a potential large number of custodial accounts.

146 Account Self-Service

Password Synchronization/Propagation Consideration

In the previous chapter, we argued that it is not advisable to automatically propagate passwords to all accounts an individual has by making sure the Account Synchronization flag is turned off at the Admin Task level. When you consider Account-Self Service, you should review company policies to decide whether a self-help initiated password change should propagate the password to all accounts the individual has, or whether the individual still needs to make a conscious decision to do so.

Request Account Privileges of Interest

Since you can never fully anticipate the needs of all your users, a practical approach is to set up a system for people to request extra privileges and require an approval process to grant the privileges.

The considerations involved in this type of services include the following:

■ Packaging the privileges people may require

■ Displaying the packages for self requesting

■ Approving process for the request

Privilege Package

What privileges? With all the different types of computer accounts in an organization, there can be many combinations of the privileges for what a user may need. One way to express the privileges the user may need is to do use the provisioning roles so that your system is capable of expressing and managing this service.

Privilege Package Display and Self Request

With the privilege packaging resolved, you now need to see how the list of packages can be presented for people to request. With CA Identity Manager, the Self-Subscribing Group concept is an appealing feature to be considered. You can use Self-Subscribing Groups to represent the Account Privilege Packages and allow users to request these groups. Later you can use the Identity Policies in Chapter 8 to actually assign the provisioning roles to requesters. Self-Subscribing Group and provisioning roles can have many-to-many relationships.

The Account Privilege Package display needs to provide the necessary information for people to make an educated guess on what they may be requesting. Consider providing the following:

■ Package Name: a short name for tracking purposes.

■ Package Brief Description: a brief description of the contents of the package.


■ Package Detail Description: a link to separate Web page that gives details on the privilege package.

■ Package Category: a category name that tends to reflect the primary group of possible requesters.

A relevant question that may arise during the design is whether all packages are supposed to be made viewable for all participants. This question is certainly valid. However, you need consider whether the effort of maintaining this type of relationship between the package and the requester is cost effective. The approval process may be enough already. Or, if the package is very sensitive, then you should not display it to users.

Request Approval

Once the request can be made, you can then design the approval process. You need to enable the approval process, decide who (known as workflow participants) is going to approve it, and notify the approvers for them to come to approve the request.

ENABLE APPROVAL

By default, the request for the Self-Subscribing Group does not actually require approval. Once the WorkPoint workflow is configured and CA Identity Manager Workflow is enabled, you can change the workflow process definition at the Admin Task level as follows to make the approval required:

The out-of-box sample workflow process has the “APPROVERS_REQUIRED” set to “NO”:


It means that if the system cannot resolve the list of approvers, then the request is approved automatically. Therefore, you may want to change it to YES to ensure that it always goes through the approval process.

WHO TO APPROVE

From the Activity Properties page in the WorkPoint Designer, you can specify the participants by using the following types of participant resolvers:

■ Group Type Participant Resolvers

■ Role Type Participant Resolvers

■ Filter Type Participant Resolvers

■ Custom Type Participant Resolvers

See the CA Identity Manager Operations Guide for more detail and the online CA Identity Manager Developer's Reference for information about writing your own custom type participant resolvers.

NOTIFY THE APPROVERS

The notification of a workflow request is done through email notification. See Appendix G and Appendix H for further details.

Sample Account Self-Services

Like Delegated Account Management, we need only discuss Account Self-Service for the NeteAuto Employee IME.

Employee Account Self-Service (Services)

The following additional services are being added to the NeteAuto Employee IME:

■ Employee Account Service Self Help

■ Employee Account Privileges Package Request

■ Employee Account Privileges Package Request Approval

■ Employee Account Privileges Package Management

SERVICE: EMPLOYEE ACCOUNT SERVICES SELF-HELP

Employee Account Service Self-Help gives the employees the ability to suspend, resume, unlock, and reset passwords on all the correlated accounts they own from the Identity Manager User Console.


SERVICE: EMPLOYEE ACCOUNT PRIVILEGES PACKAGE REQUEST

Employee Account Privileges Package Request service allows the employee to proactively request the extra account privileges packages they need. A workflow process is triggered to process such a request. A sample of such services follows:

This service is implemented through the use of Self-Subscribing Groups and the Admin Task-level approval of the AddToGroup event.

SERVICE: EMPLOYEE ACCOUNT PRIVILEGES PACKAGE REQUEST APPROVAL

This service approves or denies an employee account privileges package request.

SERVICE: EMPLOYEE ACCOUNT PRIVILEGES PACKAGE MANAGEMENT

To make a new Account Privileges Package available for employees to request, the following is a list of tasks to perform:

■ Work with Provisioning Roles Owner to determine what package to make available for employees to self-request

■ Create a Self Subscribing Group (and its Organization Unit if necessary)

■ Create an Identity Policy to trigger the Provisioning Role(s) to be assigned to the requester (see Chapter 8)

Employee Account Self Service (Roles)

NeteAuto decides to add the Employee Account Service Self Help and Employee Account Privileges Package Request to the Employee Self Service Admin Role. The Employee Account Privileges Package Approval is to be performed by the provisioning roles administrator as they are responsible for performing account provisioning services. The Employee System Manager has the added responsibilities of handling the Account Privileges Package Management tasks.




End users can manage their accounts from the Modify User's Account tab or by requesting for provisioning roles. To ensure the information has been securely transmitted, in particular the user's password, implement SSL to protect the communication between the user's browser and the Web server, as well as the communication between CA Identity Manager server and the corporate and provisioning directories.

If you have custom code written to enhance the account self-service functions, you should also protect the communication between the custom code and the CA Identity Manager server.


To implement account self-service, you can start with account password self management because it is relatively easy to implement and you can receive quick ROI.

The Graphical Identification and Authorization (GINA) option provides a way for users to maintain their passwords in the case of a forgotten password or login lock-out. If you plan to roll out this service to end users, this option must be installed and set up on a Microsoft Windows system. You can use a software delivery application, such as Unicenter Software Delivery, to distribute and simplify the roll-out process.

The next step is to implement self-provisioning management. For routine requests, you can set up identity policies to automatically trigger provisioning for users. For requests that need additional attention, you can create a workflow to control the provisioning process.


Similar to identity self-services, the main benefits for implementing account self-service is to improve productivity and user satisfaction.

A medium to large size organization often has multiple endpoints to be managed and its users often have multiple accounts across the organization. For a 10,000 employee organization, assume the average employee has four accounts to be managed. Each employee has one request per year for account password reset, and it takes a modest 10 minutes to complete the process for each account. The result is 6,666 helpdesk hours, which is more than three full time employees.

In addition to the time saved by the Help Desk staff by offering account self-services, the end users can manage their account at anytime and anywhere as long as they have access to the account self services. If the provisioning service is also available to end users, it will provide further cost savings. While identity self-service is often the first feature to be implemented by an organization, account self-services often follow soon thereafter.



On the Accounts tab, the Source field provides description of how the account was created: either the user received a provisioning role or the account was created in eTrust Admin. This attribute may take significant time to display. You can configure the Accounts tab to remove this field if it is not required.

Furthermore, secondary attributes must be retrieved directly from the endpoint. These attributes take longer to display than primary attributes. By default, CA Identity Manager displays primary and secondary attributes when a user initially accesses the Accounts tab. To reduce the amount of time CA Identity Manager takes to load the Accounts tab, you can configure CA Identity Manager to display only primary attributes. In this case, administrators can use a Get Secondary Attributes button to retrieve and display the secondary attributes as needed.

If you allow users to request provisioning roles and do not want to expose the Provisioning Roles tab, you can use a user attribute to indicate his request and use identity policies to add or remove provisioning roles for the user.


Account self-services involve both the CA Identity Manager server and the provisioning engine. You should follow the operation and maintenance advice outlined in previous chapters. The typical tasks related to the provisioning engine are:

■ Back-up or recover your eTrust Directory database information

■ Fine-tune your eTrust Directory database

■ Generate log files to predict and identify sources of system or security problems


Chapter 8 : Identity Policies and Automation Throughout the previous chapters, we have shown the effectiveness of the CA Identity Manager rule-based engine for managing administrators and owners rules. It works equally well for members rules for both Admin Roles and Access Roles. With these cases, the rule-based engine uses the attributes of an identity object to determine whether the identity satisfies the rules being evaluated. In short, the satisfaction of the rules determines the status of an identity.

Identity policy is designed to give the provisioning roles the similar rule-based facilities that Admin Roles and Access Roles have. In this chapter, we introduce identity policies. We describe in more detail what it can do. We further give examples on how to use it to automate some of the account provisioning activities.

Even though identity policy is the tool to help create rule-based provisioning roles, it does not just stop there. We describe how to use identity policies to help automate the management of provisioning roles, and look into using them in other identity management automation situations. We also describe new features like compliance and certifications and briefly share with you the possibilities of generating compliance reports.

In the sample NeteAuto customer identity management environments, we present an example that uses an identity policy to set the manager value for a self-registered customer. We create a self-service application for customers to certify themselves.

In the sample NeteAuto employee identity management environments, we use identity policies to grant a user the corresponding provisioning roles based on the self-subscribing group the user has been approved to help implement in the Employee Account Privileges Package Request self-service.

Since a NeteAuto employee may actually obtain the privileges they have on the vendor identity management system from the employee management system, the identity policies that are designed to enforce segregation of duties for the privileges that exist on the vendor IME and the privileges that exist on the employee IME.

Identity Policies

There are two reasons why a provisioning role can not support regular member rules.

First, provisioning role memberships actually trigger actions. They are not just statuses. When you modify the provisioning role memberships an identity has, CA Identity Manager might need to create new accounts, change the account privileges, and/or remove existing accounts for the identity. These actions need to be controlled activities. For example, when you modify the member rules of an Admin Role, you do not expect any identities to be

154 Identity Policies and Automation

affected immediately. Rather the effect of the changes only becomes relevant when any of the identities log into CA Identity Manager. With provisioning roles membership, it does not really work this way as it is rather difficult for a managed endpoint to have to proactively ask CA Identity Manager when any of these activities need to happen.

Second, to allow the provisioning engine to work more efficiently, the provisioning engine uses its own Administrative Directory to track all provisioning-related information. It does not really consult the CA Identity Manager server during the account provisioning activities.

Identity Policy

An identity policy is a set of business rules that apply when a user meets certain conditions or when the user no longer meets the conditions. The attempts to evaluate the identity policies occur when there are changes to an identity or when the administrator deliberately tries to synchronize an identity against the current identity policies. More specifically, the out-of-the-box sample Synchronize User Admin Task and the user related Admin Tasks that have Synchronize User enabled are the ones that can trigger the evaluation of the identity policies against the identity object.

When any of the business rules apply, they are capable of:

■ Automating certain identity management tasks

■ Enforcing compliance

■ Enforce segregation of duties

Identity Policy Set

To simplify identity policy management, identity policies are grouped in identity policy sets. An identity policy set has owner rules that designate who can manage and change the rules.

Identity Policy Actions

When a user matches an identity policy, the Identity Policy Apply Actions are executed against the user. When a user no longer meets a previously met policy, the Identity Policy Remove Actions are executed.

The specific apply and/or remove actions associated with an identity policy may include:

■ Assigning or revoking admin and access roles

■ Assigning or revoking group membership

■ Updating attributes in a user profile

■ Assigning or revoking provisioning roles if you are using a provisioning directory


■ Sending audit messages and/or log compliance violations

APPLY ONCE

For each identity policy, you have the option to decide whether to apply the identity policy actions only once as shown in the following Policies tab:

If the Apply once check box is checked, the Identity Policy Apply Actions are applied only once when the user first meets the condition. As a result,

■ Related changes made to user after the identity policy is applied are preserved.

■ Updates made to the Identity Policy Apply Actions are not applied to users who previously met the condition.

If the Apply once check box is not checked, the Identity Policy Apply Actions are applied only when the user is evaluated against the identity policy and meets the condition. As a result:

■ Related changes made to user are overwritten

■ Updates made to the Identity Policy Apply Actions are applied subsequently

When a user no longer meets the condition in an identity policy, the Identity Policy Remove Actions are applied regardless of the Apply Once setting.

Note: For an identity policy, if you want to have different Apply Once policies for different users, you can create two identity policies applied to two different sets of users. One policy has Apply Once enabled, and the other policy has Apply Once disabled.


Identity Policy Rules

Policy conditions are the rules that determine the set of users to which an identity policy applies. The following shows the conditions you can choose for a rule:

This list of options is similar to the rule-based engine we have seen thus far except for the two new additions:

■ in <administrative-union-constraint>

which means the user meet at least one constraint

■ in <administrative-intersections-constraint>

which means the user meets all of the constraints

The constraints rules allow you to refer to member, administrator, and owner of the Admin Role, Access Role, and Provisioning Role. In addition, you can also use member of group rules in it.

Note: Frequently, people use the intersection rule to detect Segregation of Duties conditions.

Data Model Changes

The use of an identity policy, however, changes the data model of the underlying CA SiteMinder and the earlier version of this product, Netegrity IdentityMinder. Both versions of CA SiteMinder support and somewhat encourage the idea of sharing a user data store with other applications. Basically, they do not actively watch over the user data store to see if it is being modified. This is the beauty of the original CA SiteMinder policies and IdentityMinder rule-base engine as they are designed to be passive. These rules are only evaluated as the user objects are being used. The introduction of identity policy changes this. An identity policy actively triggers actions as the attributes of an identity are being changed. This means that if another application modifies the shared user data store, then the identity policy may not be applied.


Triggering Identity Policies

You can trigger identity policies using automatic or manual synchronization.

To configure an Admin task to automatically trigger identity policies, you need to set User Synchronization to On Task Completion. If you select the On Task Completion option for a task that includes multiple events, CA Identity Manager does not synchronize users until all of the events in the task complete. If one or more of those events require workflow approval, this may take several days. To prevent CA Identity Manager from waiting to apply identity policies until all events complete, select the On Every Event option.

You can manually synchronize users against the identity policies by using the out-of-the-box sample Synchronize User task in the Identity Manager User Console.

Note: For the Synchronize User task to work properly, the User Synchronization option must be set to On Task Completion or On Every Event, and the Account Synchronization option must be set to On Every Event. These options are set in the Profile tab for the Synchronize User task.

The Synchronize User task also includes the following tabs:

■ Currently Matched Policies

■ Policies Already Applied

■ Synchronization Summary


The manual synchronization is useful under the following circumstances:

■ Identity Policies change over time. The changes do not apply to any users that have already existed. You can consider using manual synchronization periodically to ensure all identities continue to conform to the policies.

■ Although not desirable, sometimes you may allow certain authorities in your identity system to access your backend user data store directly. As a result, those changes may not have been subjected to the identity policies evaluation. In such cases, you need to use the manual task to synchronize users with identity policies.


■ You may want to manually synchronize a user with identity policies to ensure that a user account has the right privileges, or complies with a compliance policy.

■ You can use the manual synchronization task to examine your identity policies to ensure they work correctly according to your design.

Identity Policy Evaluation

The following procedure describes how CA Identity Manager evaluates and applies identity policies:

■ CA Identity Manager determines the set of identity policies that apply to a user.

■ CA Identity Manager compares the set of identity policies that apply to a user with the list of policies that have already been applied to that user.

Note: The list of policies that have been applied to a user is stored in the %IDENTITY_POLICY% well-known attribute in the user profile.

■ If an identity policy is on the list of applicable policies, and the policy has not been applied to the user previously, then CA Identity Manager adds the policy to the allocation list.

■ If an identity policy is on the list of applicable policies, the policy has been previously applied to the user, and the Apply Once setting for the policy is disabled, then CA Identity Manager adds the policy to the reallocation list.

■ If an identity policy is not on the list of applicable policies, and the policy has been applied to the user, and the user no longer matches the policy condition, then CA Identity Manager adds these policies to the deallocation list.

■ After CA Identity Manager evaluates all of the policies for a user, it applies policies in the following order:

– Identity policies from the deallocation list

– Identity policies from the allocation list

– Identity policies from the reallocation list

■ After the identity policies have been applied, CA Identity Manager reevaluates the policies to see if any additional changes are needed based on changes that occurred in the first synchronization process (steps above). This is to ensure that changes made by applying identity policies did not trigger other identity policies. The number of re-evaluations is controlled by the Recursion Level value.


Note: The identity policies feature is enabled by default with the Recursion Level set to 1. You can configure it the Advanced Settings on the CA Identity Manager Management Console.

Identity Policy Automation Applications

Identity policies grow out of the need to provide CA Identity Manager with a rule-based account provisioning engine. Because the engine is designed to react to the result of changes, it can also be used to automate the identity components of an identity management system.

Account Provisioning

So far, we have seen how member rules help create a delegated rule-based management scheme for admin roles and access roles. Identity policy is designed to give the provisioning roles similar features.

To do this, you need to use the following actions on the Identity Policy Add and Remove Actions page while creating the identity policies:

■ Make member of provisioning role

■ Remove member from provisioning role

For example, in an Employee Resources policy set, employees with the Manager or HR Administrator title are granted membership in the Corporate NT Domain Role. If the provisioning directory has been configured, this policy set may trigger NT accounts to be created for Managers and HR Administrators.

Provisioning Administration Delegation

To do this, we need to use the following actions on the Identity Policy Add and Remove Actions page while creating the identity policies:

■ Make administrator of provisioning role

■ Remove administrator from provisioning role


For the identity component of your identity management system, you can use identity policies for identity management to do the following:

■ Manage delegated administration roles and access roles

■ Manage identity group membership

■ Automate user profile provisioning

Admin Roles and Access Roles Delegations

You can use identity policies to automatically assign or remove users as members or administrators for any of the roles that use delegation actions when users meet the policy conditions. You can take the following actions on apply policy and remove policy:

■ Make member of access role

■ Make administrator of access role

■ Make member of admin role

■ Make administrator of admin role

■ Remove member from access role

■ Remove administrator from access role

■ Remove member from admin role

■ Remove administrator from admin role


For example, in the following Employee Resources policy set, employees with the Manager or HR Administrator title become members of the admin role User Manager. When they lose the manager title, they are removed as members of admin role User Manager.

Some admin roles and access roles may not have delegation actions for identity policies to act on and must rely on identity policies to modify the user's attributes to fit into the role. Since you must be sensitive to the authorities of any attributes to be changed, you may want to use the Admin roles attribute as suggested in the “Delegated Identity Management” chapter for this purpose, and create the corresponding delegation actions for them.

Identity Group Membership Management

You can use identity policies to automatically assign or remove group membership from users when users meet the policy conditions. You can take the following actions on apply policy and remove policy:

■ Add to group <group-name> [...]

■ Add to <group-name> in user's organization

■ Remove from group <group-name> [...]

■ Remove from <group-name> in user's organization

For example, in the Employee Resources policy set, employees with the HR Administrator title are added to group HR Department. When they lose the HR Administrator title, they are removed from group HR Department.

User Profile Provisioning Automation

You can use identity policies to update user attributes when users meet the policy conditions. You can take the following actions on apply policy and remove policy:


■ Set <single-value-user-attribute> to value

■ Remove a value from a <single-value-user-attribute> by using the Set <single-value-user-attribute> rule but provide no value in the setting

■ Add <value> to <multi-value-user-attribute>

■ Remove <value> from <multi-value-user-attribute>

The user profile provisioning is sometimes used to help implement the delegation capability roles that do not use delegation actions. However, we do not recommend it for common use. See the “Admin Roles and Access Roles Delegations” section earlier in the document for more details.

For an employee identity management system, you may think of having a user enter an office code and use an identity policy to populate the street address, city name, etc. However, this is not recommended. More details on authority concerns will be addressed in the next section.

Identity Policy and Authority Considerations

Identity policies are designed to react to changes to user objects. Identity policies can be enabled/disabled at both the IME level and at the individual task level.

Note: Use caution when considering the use of identity policies for user profile provisioning automation. You can easily violate the authorities of other components in your identity management system. For example, we mentioned the office code scenario in last section. If you choose to use an identity policy to handle the population of the street address and so on, you may be violating the authorities held by entities in your organization, such as your human resources system.

Using identity policies to help create rule based account provisioning is a common scenario as there are no member rules to help assign a provisioning role membership to a user. Identity policies are the closest we can get to providing a member rules-like concept to provisioning roles.

Given the nature of the CA Identity Manager rules, there is hardly any reason for you to use identity policies to help delegate Admin Roles or Access Roles. Other than segregation-of-duties and compliance checking, if you can express the idea to use identity policies, you should be able to use the rules directly.

The CA Identity Manager group support is similar to the provisioning role. Again there are no member rules for a user to become a member of a group. However, a group is a concept that exists in the user data store. This makes it work just like a special type of attributes a user can have. That is the reason why we only use the Self-Subscribing Group in this book. The importance of groups is usually seen when other applications are sharing the user data store and use the group features for their purposes.

An identity policy has the following privileges:


■ Administrator privilege of all access roles, admin roles, and provisioning roles

■ Administrator privilege of all groups

■ Privilege to change any raw attributes of any identity that is involved

If you want to use identity policies to help manage group membership and other user profile attribute provisioning, you need to make sure that you do not violate any of the existing authority systems that are already in place. For example, if the Human Resources system has the authority over an employee's office address, then the identity policies should not try to modify this attribute.

To resolve authority conflict, many implementations use the Identity Manager Workflow feature to allow the appropriate parties to approve the actual changes.

Compliance and Reporting

Compliance is corporate governance that includes a wide range of procedures that ensure a company and its employees comply with established business policies. These compliance procedures often involve documenting, automating, and auditing the allocation of entitlements to applications and systems.

CA Identity Manager includes the following features, which support compliance management:

■ Compliance Policies

■ User Entitlement Certification

■ Compliance Reports

Consider the following:

■ Auditing should be used closely with the compliance features to ensure your identity management system has the highest degree of integrity.

■ For auditing level, you can choose NONE, OLD, OLDCHANGED, NEW, NEWCHANGED, BOTH or BOTHCHANGED.

■ You can further identify what you want to audit by specifying AuditEvent, AuditProfile, AuditProfileAttribute and EventState in the auditSetting.xml file.

■ Ensure you periodically back up and clean up your audit database so that it does not cause performance issues for your system.


Compliance Policies

An identity policy is a set of business changes that occur when a user meets a certain condition or rule. Compliance policy is a special type of identity policy that prohibits users from having certain privileges if they have other privileges. To support compliance, you can use identity policy sets to:

■ Enforce compliance

■ Enforce segregation of duties

As an example, identity policies can define roles that are mutually exclusive and cannot be granted to the same user concurrently. In the following example, you can prevent a user from possessing both Vendor Visit Registrar Admin Role and Vendor Receptionist Admin Role. When this condition is detected during the evaluation of an identity policy, it removes the Vendor Visit Registrar role from the individual and logs a compliance violation message. In business terms, this policy may be used to prevent someone from having the privilege to register a visitor and check-in/check-out the visitor for any kind of cover-up activities.

In this policy, we make sure that the Apply Once is disabled, and Compliance is enabled. Use the in <administrative-intersection-constraint> option to define a set of conditions, and use the Remove member from admin role and Compliance violation messages in the policy action.

Note: To allow the Remove member from admin role to work properly, you must be able to remove the user role through the Delegation Actions first.


User Entitlement Certification

The basic design for user entitlement certification is to require managers to periodically review and approve the roles of the users they manage. Using the certification tasks, certification process owners can:

■ Identify a set of users that require certification.

■ Determine a certification period, such as a fiscal quarter, in which the selected users must be certified.

■ Notify the managers that they have pending certifications to do. CA Identity Manager uses the USER_MANAGER notification rule in the email templates for user certification to determine the user's manager.

■ Allow the managers to certify or remove privileges.

■ Determine the actions to take for those users who are still not certified when the certification process ends.

The following example describes the steps in the user certification process and illustrates the actions that CA Identity Manager takes at each step. This is not the default process, but is the process most commonly used.

CERTIFICATION PROCESS MECHANISMS

The basic CA Identity Manager user entitlement design gives us the essential mechanisms using Admin Tasks that:

■ Put selected users into the REQUIRES_CERTIFICATION state through the Start Certification Process


■ Suggest sending two types of email notifications during the course of the certification period

■ Allow users, usually managers, to certify those who require certifications, remove privileges if necessary, and change the users to the CERTIFIED state

■ Put selected users who have the status not equal to CERTIFIED into the NOT_CERTIFIED state and take the pre-configured actions

CONCURRENT CERTIFICATION PROCESSES

Since you can actually configure your own Admin Tasks using the out-of-the-box samples, you can provide your own designs around the given mechanism. Although somewhat limited, you can actually have multiple certification processes running against different sets of users at the same time for different business applications without having to create any custom programs.

SELF CERTIFICATION

Certification requires running an Admin Task against one or more users. However, you can use a simple JSP Web Services Client program to help you create a self-certification mechanism that you can integrate with other business applications. For example, customers can be asked to view the Privacy Statement periodically to satisfy the certification requirement and become certified.

A sample JSP is provided in the zip file that accompanies this book.

Compliance Reports

CA Identity Manager includes sample reports that display the compliance status for users in your environment. Using this report, you can see which users are not compliant with your business policies. Sample reports display the compliance status and last certified date for users. Using this report, you can see which users fail to comply with your business policies. You can view reports from CA Identity Manager or run them in batch.

Three reports are included by default:

■ Certification Status Overall pie chart

■ Certification Report

■ Certification Status

To view the sample reports in CleverPath Reporter, navigate to the im_admin_tools_dir\imrexport\ReportDefinitions\CPR42 directory.

Note: CleverPath Reporter is required to view the sample reports.


SAMPLE COMPLIANCE REPORTS

The following shows an example of a Certification Status Overall pie chart:

The following shows the upper portion of a Certification Report:


The following shows the lower portion of a Certification Report:


The following shows an example of a Certification Status.

Sample Identity Policies and Certification Services

Initially, NeteAuto does not have the need to use any of the identity policies or Certification Services on the vendor populations. In this section, we focus on the Self-Services need for both the customer and employee populations.

Customer Certification and Identity Policies Services

The NeteAuto Customer IME is offering the following additional services to set up the infrastructure that allows NeteAuto to keep up with existing and potentially new government regulations over the Internet:

■ Customer Status Certification (View Privacy Statements)

■ Customer Status Certification Owner Identity Policies

■ Customer Service Assisted Customer Status Certification

■ Customer Status Certification Management


SERVICE: CUSTOMER STATUS CERTIFICATION

Customer Status Certification is a service that helps NeteAuto ensure that the registered customers are periodically being informed with any kind of government regulation. For example, as NeteAuto opens self-service to its customers, it wants to use the Customer Identity Management system to help ensure the customer has actually acknowledged the Privacy Statement it has published online periodically and to disable the customer if the acknowledgement is not received in a period of time.

Initially, NeteAuto established a Self-Certification Web application that shows the customer the Privacy Policy and requires the customer to click the Accept button to complete the self-certification. NeteAuto customers who are not yet certified have an additional entry on the screen when they log into the Customer IME shown below:

SERVICE: CUSTOMER STATUS CERTIFICATION OWNER IDENTITY POLICIES

NeteAuto starts with a simple identity policy to set all the registered customers an Owner indicated in the field of Manager. Over time, more sophisticated rules can be developed to classify the customers.

SERVICE: CUSTOMER SERVICE ASSISTED CUSTOMER STATUS CERTIFICATION

With the Customer Status Certification process in place, there may be a time where a registered customer can be locked because of non-compliance. This service is needed to help the customer re-certify in the case of a lock.


SERVICE: CUSTOMER STATUS CERTIFICATION MANAGEMENT

The management cycle of NeteAuto's Customer Status Certification process includes the following:

■ Begin Certification Process: scheduled on an annual basis through a batch processing job

■ Mail Notification: scheduled immediately after the process begins to notify the customers that they need to go online to fulfill the certification requirement

■ Final Mail Notification: scheduled 30 days before the end of the certification progress to remind the un-certified customers that they still need to fulfill the certification requirement

■ End Certification Process: scheduled at the end of certification period to disable the customers who have not satisfied the certification requirements.

The sample Web Services documents and a generic utility are located in Appendix I which you can use to schedule these activities through batch jobs.

NeteAuto's customers are given an additional menu where they can certify themselves after satisfying the status certification requirements.

Customer Certification and Identity Policies Roles

NeteAuto needs to add the following new Admin Roles:

■ Self Certification

■ Customer Certification Manager

ROLE: SELF CERTIFICATION

Self Certification Role makes the Customer Certification Service available to the customer.

Member Rules


■ Anyone who has the “Certification Status” equal to the value of “REQUITED_CERTIFICAION”

■ Scope Rule: User none; Group none; Organization none; Access none.


ROLE: CIM CUSTOMER CERTIFICATION MANAGER:

Customer Certification Manager manages the customer status certification process. This role is primarily used by the scheduled job.

Member Rules


■ Anyone who has the “CIM Customer Service Representative” value in the multi-value attribute “Admin roles.”

■ Scoping Rules: User in ( organization "Customer" and lower ); Group none; Organization none; Access none.

Employee Identity Policies Services

We implemented two identity policy sets on the NeteAuto Employee IME. One of them is used to support the Employee Account Privileges Package Request self service, see the "Account Self-Service" chapter for more detail. The other is used to enforce segregation of duties for the Vendor IME.


SERVICE: ACCOUNT PRIVILEGES PACKAGE GRANTING IDENTITY POLICY SET

Each Policy Condition is assigned to a member of a certain group for each Self-Subscribing Group designed to trigger provisioning roles membership to be assigned to the user. The corresponding Add/Remove actions just do as intended as follows:

SERVICE: VENDOR IME COMPLIANCE IDENTITY POLICY SET

Initially, there is only a single identity policy set to ensure that if an employee happens to have both the Vendor Visit Registrar Admin Role and Vendor Receptionist Admin Role, the Vendor Visit Registrar Admin Role is removed and a compliance violation message is logged. See the screen in the previous topic under the discussion of Compliance Policies.

Employee Identity Policies Roles

The Admin Role Employee System Manager manages all identity policies.


Identity Policies Evaluation Considerations

The introduction of identity policies can have significant impact on how identities are being administered in your identity management system. Here is a list of scenarios:

■ Initial Set of Identities

We start a CA Identity Manager system using a user data store. This user data store can start empty or can be a shared user data store other applications are using. The question is whether any of the existing identities need to be evaluated against the identity policies.

■ New Identity Policies


If we are introducing new identity policies, the same question applies. Do we need to apply these policies to all existing identities?

■ Administer Identities through CA Identity Manager

When the identities are administered through CA Identity Manager User Console or the TEWS interface, the changes to the identities are usually subject to the identity policies based on the User Synchronization setting on the Admin Task:

■ Administer Identities through IM API

When the identities are administered through the IM API, the changes to the identities are not subject to the identity policies.

■ Administer Identities through the Provisioning Server

When the identities are administered through the legacy provisioning server interfaces, the inbound synchronization allows these changes to go through the identity policy evaluation. The inbound synchronizations exist as program exits on the provisioning server. They intercept changes to the global user objects and then use the CA Identity Manager call-back interface to feed back to the system. These interfaces and facilities include:

> etautil batch utility

> SPML

> Universal Feed Option

> PeopleSoft Feed Option

> Explore and Correlate that creates new or modifies existing global user objects

■ Apply Identity Policies to Specific Identities

There are opportunities when we may want to explicitly cause identity policies to be applied to certain identities. You can use the CA Identity Manager Synchronize User Task through either the Identity Manager User Console or the TEWS interface for this purpose.

New Identity Policies Roll-out Consideration

A set of identity policy sets can be imported into the system using an XML file through the usual role and task settings import on the Identity Manager Management Console:


Examples of the XML file format are available in the RoleDefinitions.xml file. This file can actually contain all the Roles and Tasks definitions for an Identity Manager Environment. It has a section called Identity Policy Set Information. Each set contains the identity policy elements that make up the set and owner policies.

We can also consider using the TEWS interface to load the identity policy sets.

After the new identity policies are in place, if we need to make sure the relevant identities do conform to these policies, then one way to do it is to use TEWS to invoke Identity Manager Synchronize User Task over these identities.

Ongoing Operations for Identity Policies

USING IDENTITY POLICY FOR DATA TRANSFORMATION

In some cases, you may want CA Identity Manager to transform data before it is stored in the user store. Using identity policies, you can define conditions that trigger changes to an object managed by CA Identity Manager. For example, you can use an identity policy to transform a partner code from an external data source to a partner name in a user attribute managed by CA Identity Manager. To ensure that all data is up-to-date, you can synchronize users with identity policies manually or automatically.

An identity policy is not the only solution for data transformation. You can also use logical attribute handlers (LAH) to achieve the same result. Logical attribute handlers are custom Java code that transform user attribute values used in CA Identity Manager. Although LAHs require programming skill, they are more flexible and often can offer better performance compared with identity policies.

USING IDENTITY POLICY FOR BUSINESS LOGIC IMPLEMENTATION

You can customize CA Identity Manager to implement the business logic that your company requires. CA Identity Manager includes several options for implementing custom business logic, identity policies are one of them. You can use identity policies to define a set of business changes that occur when a user meets a certain condition or rule. For example, identity policies can automate certain identity management tasks, such as assigning roles, or enforce business rules, such as preventing users from signing and approving checks over $20,000.

While identity policies are relatively easy to implement, you should also look at other options before you settle on them. Other possible options include logic attribute handlers, business logic task handlers and Workflow. Although those options are not as easy to implement as identity policy, they are often more flexible and can provide better performance.


Initial Roll-out versus Ongoing Operations User Entitlement Certification

To prepare the roll-out of entitlement certification, you must consider the following factors:

Certification Status


> The %CERTIFICATION_STATUS% and %LAST_CERTIFIED_DATE% well-known attributes are configured in the directory configuration file (directory.xml)

> CERTIFICATION_STATUS (Required)

> Certification roles and tasks are deployed when defined

> Modified by the begin and end process and user certification tasks

> Values are REQUIRES_CERTIFICATION, IN_CERTIFICATION, CERTIFIED, and NOT_CERTIFIED

> LAST_CERTIFIED_DATE (Optional)

> Set to the last date the user was certified

> Can optionally be used as the search criteria for process tasks, using the today search function:

> LAST_CERTIFIED_DATE >= ${today(IsoDate,-60)}

Certification Notification Mechanism


> Email notifications must be enabled and configured correctly. It uses default email templates for Reminder and Final Reminder emails.

> When CA Identity Manager sends email notifications

By default, CA Identity Manager is configured to send email notifications for the following events:

> CertificationRequiredNotification

> CertificationRequiredReminderNotification

> CertificationRequiredFinalReminderNotification

> CertificationNonCertifiedActionPendingNotification

> CertificationNonCertifiedActionCompletedNotification


If you do not want CA Identity Manager to send email notifications for these events, modify the email notification configuration in the Identity Manager Management Console with respect to the following:

> The users to whom CA Identity Manager sends email messages

By default, CA Identity Manager sends email notifications to the manager of a user who requires certification. CA Identity Manager uses the USER_MANAGER notification rule in the email templates for user certification to determine the user's manager. You can modify the email template if it's necessary.

> The content of the email messages

The content of the email messages that CA Identity Manager sends is determined by an email template, which includes static text (such as the phrase "requires certification") and variable text specific to a given context (such as the name of the user who requires certification). You can use a default template as installed or customize it to suit your needs.

In addition to the email notification generated by certification tasks, you can use the certification events to start workflows to enhance the certification process.

Initial Roll-out versus Ongoing Operations for Compliance Reporting

CA Identity Manager reports let you see the current state of an IME. You can use this information to ensure compliance with internal business policies or external regulations.

You generate CA Identity Manager reports from management data, which describes the relationship between objects in an IME. Examples of management data include the following:

■ A user's profile attributes

■ A list of roles that contain a certain task

■ The members of a role or group

■ The rules that comprise a role

Management data includes information from two sources:

■ The user store contains information about users, groups, and organizations.

■ The CA SiteMinder policy store contains information about the relationship between objects in the user directory.

To generate management data, you need to export data from the CA SiteMinder policy store and the user directory to the database. The data you export provides a snapshot view of management data in the IME.


To generate management data, use the CA Identity Manager export tool. The syntax is:

IMRExport <options> <export command file>

Once you have exported management data to the report database, you can run and view the report using standard reporting tools, such as CA CleverPath Reporter. CA Identity Manager includes several sample reports that you can use as installed, or customize to suit your needs.

Reports for Return on Investment (ROI)

CA Identity Manager provides the following general types of ROI:

ROI FOR USING IDENTITY POLICIES

While today's companies have benefited from technology advancements, enterprise systems have become more complex and require significant investment to manage. It is very common that an average employee in a medium sized company has multiple accounts and may request admin and provisioning roles as well as group membership based on different criteria. By taking advantage of the identity policy feature of CA Identity Manager, many of the tasks can be automated and achieve significant savings and impressive ROI in a short period.

For a 10,000 employee organization, the average employee might make two requests per year for admin roles, provisioning roles or group membership. It takes the system administrator an average of 15 minutes to implement the requested changes. The system administrators need to spend 5,000 hours per year to facilitate these changes. That is 2.5 full time system administrators or $250,000 in labor costs alone assuming the salary and benefits for the average system administrators are $100,000 per year.

Furthermore, for the employees requesting the changes, they lose at least 5,000 hours per year, which translates into $200,000 lost productivity assuming their average labor cost is $80,000 per employee per year. Therefore, the total cost is $450,000 for the system administrator and end users.

Assume 50% of the changes can be automated using identity policies. It will result in a savings of $225,000 per year. Assume a system administrator spends 50% of his time managing identity policies, the cost is only $50,000 per year. The ROI is an impressive 450% for the first year. In subsequent years, since the system administrator can spend less time on maintaining identity policies, the ROI will be even higher.

ROI FOR USING ENTITLEMENT CERTIFICATION AND COMPLIANCE REPORTS

The value of using entitlement certification is to ensure the compliance of business policies through periodically reviewing and approving the roles of users. In addition to that, you can use compliance reports to display the compliance status for users in your environment. Using these reports, you can see which users are not compliant with your business policies.


While it is not easy to put a price tag on enforcing the compliance of business policies, according to the 2003 CSI/FBI Computer Crime and Security Survey, insider unauthorized access to data and its theft costs companies an average of $300,000 per incident. Entitlement certification and compliance reports are effective tools to prevent such expensive incidents from happening.

Another benefit provided by entitlement certification and compliance reports is ensuring compliance with government regulations. Without of the help of entitlement certification and compliance reports, organizations must often spend numerous hours to enforce IT policy compliance and collect data to create reports to show the results of such efforts.

Deployment and Performance Considerations

Real world production deployments differ in hardware and software configurations, underlying directory and policy models, and end user usage patterns. Thus it is impossible to provide a cookbook solution that will solve all performance issues for all possible deployment scenarios. It requires a methodological approach to test, analyze, re-configure, and re-test in your particular deployment to achieve optimal performance.

A CA Identity Manager deployment typically follows the multi-tiered enterprise application layout, with the following tiers:

■ Web Tier

> Hardware HTTP / Network load balancers (optional)

■ HTTP / Web Server

> SiteMinder Agent

> J2EE Application Server Plug-in

■ Application Server Tier

> J2EE Application Servers

> JMS Servers (usually embedded with J2EE servers)

> Identity Manager Server (deployed on J2EE application server)

■ Policy Server Tier

> CA SiteMinder Policy Servers

■ Provisioning Server Tier

> eTrust Admin Server Provisioning Server

> eTrust Admin Distributed Connector Server

■ Back End / Data Tier


> LDAP Directory Servers

> Database Servers

See the administrative and performance tuning guides for each of the components for more in-depth performance analysis and tuning. In this chapter, we focus on settings that directly impact the performance of identity policies.

IMPROVE DIRECTORY SEARCH PERFORMANCE

Improving the search performance of your directories involves the corporate directory and the provisioning directory:

Corporate Directory

■ Index the attributes that administrators can specify in search queries.

■ Override the default directory timeout setting by specifying values for the following search parameters in a directory configuration file (directory.xml):

timeout

The maximum number of seconds that CA Identity Manager searches a directory before terminating the search.

maxpagesize

The maximum page size for search results (LDAP only).

maxrows

The maximum number of rows returned after a search (LDAP only).

■ Tune the user directory.

Provisioning Directory

Use the latest CA Identity Manager and CA SiteMinder releases. In releases after CA Identity Manager r8.1 CR3 and CA SiteMinder r6.0 SP4 CR4, search operations to execute eTrust Admin user attribute lookups to match identity policy rules have improved. This enhancement improves the performance of the Synchronize User Event.

Initial Roll-out of Identity Policies

If you plan to roll-out large numbers of identity policies, you may want to consider turning off task persistence and auditing temporarily because they may negatively impact the overall CA Identity Manager performance. If task persistence and auditing are required when CA Identity Manager processes a large number of transactions, you should consider increasing the JDBC connection pool used by the task persistence and auditing services.


Admin Task's User Synchronize Option

If you do not use identity policies in your system, you can safely set the User Synchronization option to off to eliminate checking for identity policies. You can also set User Synchronization to off at the IME level using the Management Console.

The Additional Synchronize User Event

By default, the sequence of the Synchronize User Task operations is as follows:

■ Invoke an initial Synchronize User Event. This is the primary event of the Synchronize User Task

■ Upon completion of all task events, including the primary event or any subsequent events generated as a result of the applicable identity policy change actions, if the task's User Synchronization flag is set to On task completion an additional Synchronize User Event is generated.

The purpose of this secondary event, in the Synchronize User Task case, is to handle situations where change actions from the processing of one identity policy may be a condition for a subsequent identity policy that has already been evaluated. If your identity policies do not rely on the change action of another policy, you can turn off the generation of this second event, which may greatly improve the efficiency of executing user synchronization against identity policies.

JMS TUNING

CA Identity Manager uses JMS heavily in its event processing. Tuning the JMS options can have significant impact on CA Identity Manager performance. See the J2EE Application Server documentation for more in-depth descriptions of performance analysis and tuning.

CA IDENTITY MANAGER TO POLICY SERVER AGENT CONNECTIONS

CA Identity Manager uses the CA SiteMinder Agent API for connecting to the CA SiteMinder policy servers. For a busy CA Identity Manager deployment, you may want to increase the connection settings specified in the %IdentityMinder.ear%\policyserver_rar\META-INF\ra.xml files. Defaults are as follows:

■ ConnectionMax = 30

■ ConnectionMin = 2

■ ConnectionStep = 4

Note: Make sure that the combined number of connections defined in ra.xml (ConnectionMax property) for all CA Identity Manager instances in a cluster (and the connections used by CA SiteMinder agents) is less than the Maximum Connections defined for the Authentication Server in the Policy Server Management Console. For example, if you


have 10 CA Identity Manager instances going against the same Policy Server, the default value of 256 is not enough since the default ConnectionMax property is 30.

INCREASE THE NUMBER OF POLICY SERVER USER DIRECTORY CONNECTIONS

The Policy Server provides a mechanism to increase the number of concurrent directory operations across execution threads. The mechanism relies on additional load balancing and fail-over servers each of which point to the same physical server and port.

Adding more load balancing and fail-over servers can be achieved by creating multiple CA SiteMinder User Directory Connections and configure them for load balancing and fail-over. Be sure that each user directory connection points to the same user directory and port. Configuring multiple CA SiteMinder User Directory connections for load balancing and fail-over provides additional connections to the user directory. If one connection is busy, there are other connections available for requests.

ENTITLEMENT CERTIFICATION

Entitlement certification can be a time consuming activity. You need to plan the process carefully, including when to start the certification process, when to send reminder notification, and what to do at the end of the certification process.

To prevent the system from being flooded with certification requests and to improve system performance, you may choose to perform the certification process for a selected number of users at a certain time and perform the certification process throughout the year. Another thing to consider is that you may want to use workflow to improve the certification process.

COMPLIANCE REPORT SCHEDULE

It may be time consuming to export data from the CA SiteMinder policy store and the user directory to the database. Since the data you export provides a snapshot view of management data in the IME, you can schedule the export process to happen outside of normal business hours at pre-determined intervals.

Once the data is exported, many of the reporting tools allow you to schedule reports to be generated against the database at regular intervals, such as daily or weekly.


Appendix A: Third Party Tools In this appendix, we want to quickly present to you the additional third party tools we used for this book. All of these tools are reputable and can be downloaded freely from the Internet. Since we developed our samples on the Windows platform, the tools are primarily for Windows.

All of the tools are meant to be installed on a development workstation first. The GNU utilities, other utility scripts, and Java class/jar files developed for this book may need to go on your production servers for customization or automation purposes.

Apache Tools

The Apache Software Foundation main Web site is at the following:

http://apache.org/ http://apache.org/

The following tools are used for various purposes:

■ Apache Ant 1.5

http://ant.apache.org http://ant.apache.org

Apache Ant 1.5 was used to build the examples for this book. Since Ant is used as a building utility, it really has no impact to the final binaries. We have seen that the new version of Apache Ant 1.6.5 works as well. The benefit of this newer version is that it supports subdirectory name with embedded blanks.

■ Apache Axis 1.3

http://ws.apache.org/axis/ http://ws.apache.org/axis/

Axis 1.3 provides the basic building block for the Web Services tools. Apache Axis is an implementation of the SOAP ("Simple Object Access Protocol") to the World Wide Web Consortium (W3C) at http://www.w3.org/ http://www.w3.org/.

Eclipse Tools

Eclipse is a widely used Java IDE (Integrated Development Environment) that can be found at:

http://www.eclipse.org/ http://www.eclipse.org/

Instead of using the standard Eclipse SDK package, we suggest that you download the wtp-all-in-one package that is available at the Eclipse Web Tools Platform (WTP) Project Home Page:

http://apache.org/

http://ant.apache.org/

http://ws.apache.org/axis/

http://www.w3.org/

http://www.eclipse.org/


http://www.eclipse.org/webtools/main.php http://www.eclipse.org/webtools/main.php

As of this writing, we have been using Release 1.5.3. This all-in-one package also gives you the standard Eclipse SDK development environment.

GNU Tools

The following are the main links where we downloaded the Windows port of the GNU utilities used:

■ http://gnuwin32.sourceforge.net/ http://gnuwin32.sourceforge.net/

■ http://gnuwin32.sourceforge.net/packages.html http://gnuwin32.sourceforge.net/packages.html

In particular, we used:

■ DiffUtils (2.8.7)

http://gnuwin32.sourceforge.net/packages/diffutils.htm http://gnuwin32.sourceforge.net/packages/diffutils.htm

DiffUtils provides utilities that can be used to extract the differences between two text files. We use diff to help extract changes we made to our configurations.

■ Gawk (3.1.3)

http://gnuwin32.sourceforge.net/packages/gawk.htm http://gnuwin32.sourceforge.net/packages/gawk.htm

Gawk is a GNU version of awk that is a pattern scanning and processing language. We use it to convert csv files to XML documents in our Web Services examples.

■ Wget (1.10.1)

http://gnuwin32.sourceforge.net/packages/wget.htm http://gnuwin32.sourceforge.net/packages/wget.htm

Wget is a network utility to retrieve files from the World Wide Web using HTTP and FTP Internet protocols. It is a command line utility.

SUN Java Tools

We use Sun Java SDK to compile some of the sample code provided. Since the Sun Java SDK is actually required for your CA Identity Manager Application Server, this is not an extra effort.

The official supported Sun Java SDK can be found at the CA support site, http://supportconnet.ca.com/ http://supportconnet.ca.com/. As of this writing, it is:

http://www.eclipse.org/webtools/main.php

http://gnuwin32.sourceforge.net/

http://gnuwin32.sourceforge.net/packages.html

http://gnuwin32.sourceforge.net/packages/diffutils.htm

http://gnuwin32.sourceforge.net/packages/gawk.htm

http://gnuwin32.sourceforge.net/packages/wget.htm

http://supportconnet.ca.com/


■ Java Development Kit 1.4.2, Release 7 at: http://java.sun.com/products/archive/ http://java.sun.com/products/archive/

We also used the following tools. However, they have been included in a standard installation of CA Identity Manager. The following is for your reference only. You do not need to download them.

■ Java Activation Framework

http://java.sun.com/products/javabeans/glasgow/jaf.html http://java.sun.com/products/javabeans/glasgow/jaf.html

Java Mail

http://java.sun.com/products/javamail/ http://java.sun.com/products/javamail/

http://java.sun.com/products/archive/

http://java.sun.com/products/javabeans/glasgow/jaf.html

http://java.sun.com/products/javamail/


Appendix B: Sample Files and IMEs Build In this appendix, we present an overview of the sample files that are considered part of this book and give you a quick summary of how you can use these files to build the three sample IMEs introduced in this book. More in depth discussions of some of the files are provided in other appendixes.

Disclaimer

The sample files and IME build procedures given in this appendix have only been tested with CA Identity Manager r8.1 SP1 CR5 using JBoss 3.2.2 as the application server. These examples may not work with other releases of CA Identity Manager and/or other application servers like WebSphere and WebLogic.

For example, the RoleDefinition XML file format in CA Identity Manager r8.1 SP1 CR5 is different than the one used in CR1. Therefore, the RoleDefintion XML files provided with this book do not work with a CR1 installation.

Sample Files Organization

Once you have obtained the zip file that comes with this book, you can unzip it to a development workstation and copy certain files to your CA Identity Manager installation if necessary. The following is the high level directory structure for these files:

customer

APPServer

APPServerJSP

webagent

webservices

wsbatch

employee

APPServer

lah

webservices

wsbatch

GenRoleXML

KMS

samples

NeteAuto

vendor

webservices

wsbatch

With this structure:


customer

Contains the files directly related to Customer Identity Manager (IME) Environment.

employee

Contains the files directly related to Employee IME.

GenRoleXML

Contains a simple sample utility the help you create a portable RoleDefinitions XML file discussed in Appendix D IME XML Files and Tools.

KMS

Contains the MS-SQL scripts to create the sample KMS database to be used with Appendix J Connector Xpress.

samples

Contains the files that you may want to copy into the samples subdirectory that is installed as part of the CA Identity Manager Administrative Tools. It actually contains the sample user data store discussed in Appendix C.

vendor

Contains the files directly related to Vendor IME.

customer/APPServer, employee/APPServer

Contain customized files that need to be copied into the Identity Manager Application Server deployment to allow some of the samples for the Customer IME and Employee IME to work.

customer/webagent

Contains sample files that are needed to configure the WebAgent to provide a different authentication scheme. Depending on the type of WebAgent you are using, these files are to be copied to different subdirectories. For example, if you use the out-of-the-box CA Identity Manager installation that gives you the Servlet Filter Agent, the files and subdirectories underneath it are copied to <APPServerHome>/ SiteMinderAgent.ear/agent_war. If you integrate a standard CA SiteMinder Web Agent, they need to go to the netegrity/webagent/samples subdirectory. In any case, the file loginGB.fcc needs to be stored under the same subdirectory as the standard login.fcc. For more information see Appendix F, "CA SiteMinder Procedures."

customer/webservices, employee/webservices, vendor/webservices

Contain the AXIS based Task Execution Web Services (TEWS) build tool set discussed in Appendix I, "TEWS Client Programs."


customer/wsbatch, employee/wsbatch, vendor/wsbatch

Contain the TEWS batch utility that uses wget and gawk. The TEWS client programs are discussed in Appendix I.

employee/lah

Contains the sample Logical Attribute Handler sample Java program and build tools discussed in Appendix E.

Sample IME Building Procedures

To build the three sample IMEs used in this book, we suggest that you use at least four machines as we need to use three separate CA SiteMinder Policy Servers.

The high level procedures described here are meant to show you a possible approach. These procedures are not meant to show an optimized deployment.

CA Identity Manager Development Workstation

Before you actually start building a CA Identity Manager Server, we suggest that you consider building a Development Workstation to be used for ongoing support. On this machine, you need to install all the third party tools listed in Appendix A. Since Eclipse requires significant memory to work, we recommend a system with 1 GB RAM. Eclipse is highly recommended but not required.

You also want to unzip the zip file of supporting files that accompanies this book on the same machine.

Employee IME Machine

The Employee IME machine is the most complex machine of the three. Even as a light demo test machine, it still requires 2 GB of RAM.

BASE CA IDENTITY MANAGER SERVER

With a good Windows 2003/SP1 Server, you first need to install the Sun Java SDK 1.4.2_07 and the JBoss 3.2.2 that comes as a separate download included in the CA Identity Manager r8.1 3rd Party Components.

The installation of CA Identity Manager r8.1 SP1 comes next. You first need to create a local account imsingres with the administrator privilege. Then, using the installation wizard, you need to use the custom install to select only the following components:

■ Identity Manager Server

– Connect to eTrust Admin


■ Create sample user store and environment

– Install Ingres for audit, reports, CA workflow, and task persistence

Note: We do not want to select CA Workflow or iRecorder

■ Identity Manager Administrative Tools

■ Identity Manager Extension for SiteMinder Policy Server

■ SiteMinder Policy Server (includes eTrust Directory and Ingres database)

This installation gives you a good starting point where you can test the sample out-of-the-box environments and know your installation is functioning correctly.

CONFIGURE THE WORKPOINT WORKFLOW

With the base CA Identity Manager Server working, the next step is to configure WorkPoint Workflow and test it with the sample IME on the base CA Identity Manager Server. To enable the WorkPoint Workflow, you also need to have access to MS SQL Server or Oracle.

PROVISIONING SERVER

You then want to install the eTrust Admin Server on the same machine. Since the required eTrust Directory is installed during the installation of the Base CA Identity Manager Server, we suggest that you download the most recent Cumulative Release of the eTrust Admin r8.1 SP2 from the CA Support Web site. Unzip the etadm-server package and run setup.exe from there. You still want to use the custom installation and provide the following information:

■ Use etrustadmin as the Domain name

■ Select all the connectors except those with a (*) next to them. These connectors require other prerequisites to function

ESTABLISH THE EMPLOYEE IME

Use the following procedure to establish the Employee IME:

5. Remove the out-of-the-box sample neteauto IME and the neteauto Identity Manager Directory. They have served the purpose of allowing us to verify that the system has been installed correctly.

6. Load the NeteAutoDB.ldif into the neteauto database. Use the procedure in Appendix C, "Sample User Data Store."

7. Create the employee and etrustadmin Identity Manager Directories. Find and use the two Directory.xml files, employee-Directory.xml and etrustadmin-Directory.xml, under the employee subdirectory to create these two Identity Manager Directories.


8. Create the Employee IME using the employee-RoleDefinitions.xml. You also need to supply the following information:

– Protected alias name: employee

– Public User: SelfRegUser

– Public alias: employeePub

– System Manager: SuperAdmin

9. Configure the Employee IME using the employee-EnvironmentSettings.xml.

10. Copy all the files under employee\APPServer to the jboss3.2.2\server\default\deploy.

11. Configure CA SiteMinder to secure Web Services. Use the CA SiteMinder procedures in Appendix F.

12. Configure CA SiteMinder to use static keys in preparation for SSO. Use the procedure in Chapter 5, "Web Application Authorization."

13. Configure the JBoss email according to the CA Identity Manager Installation Guide.

14. Restart the Employee IME machine and the Identity Manager services.

15. Modify the two Admin Tasks, CustomerPortal and VendorPortal, with the Customer IME machine name and Vendor IME machine name.

Note: The following URL gives an example on how to link your Employee IME to other Web environments:

http://Your_Employee_IME_Server_Name:8080/idm/ui/default.htm http://your_employee_ime_server_name:8080/idm/ui/default.htm

Customer IME Machine

The Customer IME machine requires at least 1 GB of RAM.


The Base CA Identity Manager Server procedure is the same as the Employee IME described earlier.

This installation gives you a good starting point where you can test the sample out-of-the-box environment and know your installation is functioning correctly.

ESTABLISH THE CUSTOMER IME

Use the following procedure to establish the Customer IME

http://your_employee_ime_server_name:8080/idm/ui/default.htm


16. Remove the out-of-the-box sample neteauto IME and the neteauto Identity Manager Directory. They have served the purpose of allowing us to verify that the system has been installed correctly.

17. Create the customer Identity Manager Directory. Find and use the customer-Directory.xml under the customer subdirectory to create the Identity Manager Directory. Use the Employee IME's machine name to use the same user data store.

18. Create the Customer IME using the customer-RoleDefinitions.xml. You also need to supply the following information:

– Protected alias name: customer


– Public alias: customerPub


19. Configure the Customer IME using the customer-EnvironmentSettings.xml.

20. Copy all the files under customer\APPServer to the jboss3.2.2\server\default\deploy.

21. Configure SiteMinder to secure Web Services. Use the CA SiteMinder procedures given Appendix F.

22. Configure SiteMinder to use static keys in preparation for SSO. Use the procedure given in Chapter 5, "Web Application Authorization."

23. Copy all the files under customer\webagent to the jboss3.2.2\server\default\deploy\SiteMinderAgent.ear\agent_war.

24. Configure SiteMinder to use form-based authentication and use the loginGB.fcc file.

25. Configure JBoss email according to the CA Identity Manager Installation Guide.

26. Restart the Customer IME application server and restart the Identity Manager services.

Note: The following URL gives an example on how to link your Employee IME to other Web environments:

http://Your_Customer_IME_Server_Name:8080/idm/ui/default.htm http://your_customer_ime_server_name:8080/idm/ui/default.htm

Enable TEWS JSP Support

After the Customer IME is started and working, you need to build your TEWS client library and deploy it.

http://your_customer_ime_server_name:8080/idm/ui/default.htm


BUILD YOUR TEWS CLIENT LIBRARY

The privacy.jsp, see Appendix I, requires the presence of your TEWS client library to work. If you have set up a CA Identity Manager Development Workstation, you can build your TEWS client library there. If not, you should download Ant and Axis and install them on your Client IME machine to build it.

DEPLOY THE PRIVACY.JSP AND OTHERS

The customer\APPServerJSP contains the privacy.jsp file and its supporting files. You need to copy this subdirectory using the similar steps used to copy the customer\APPServer. After you have restarted the CA Identity Manager Application Server, use the self-certification provided in our example and develop your own JSP pages based on your TEWS client library.

Vendor IME Machine

The Vendor IME machine requires at least 1 GB of RAM.


The Base CA Identity Manager Server procedure is the same as the Employee IME described earlier.

This installation gives you a good starting point where you can test out the sample out-of-the-box environment and know your installation is functioning correctly.

ESTABLISH THE VENDOR IME

Use the following procedure to establish the Vendor IME

1. Remove the out-of-box sample neteauto IME and the neteauto Identity Manager Directory. They have served the purpose of allowing us to verify that the system has been installed correctly.

2. Create the vendor Identity Manager Directory. Find and use the vendor-Directory.xml under the vendor subdirectory to create the Identity Manager Directory. Use the Employee IME machine name to use the same user data store.

3. Create the Vendor IME using the vendor-RoleDefinitions.xml. You also need to supply the following information:

– Protected alias name: vendor


– Public alias: vendorPub



4. Configure the Vendor IME using the vendor-EnvironmentSettings.xml

5. Configure CA SiteMinder to secure Web Services. Use the CA SiteMinder procedures in Appendix F.

6. Configure CA SiteMinder to use static keys in preparation for SSO. Use the procedure given in Chapter 5, "Web Application Authorization."

7. Restart the Vendor IME machine.


Appendix C: Sample User Data Store In this appendix, we give you the sample NeteAutoGB.ldif used to populate the sample user data store to allow you to try some of the examples discussed in this book.

Utilities

The NeteAutoGB.ldif and three other batch files are included on the sample zip file that accompanies this book. See Appendix B for an overview of all the files. After unzipping the sample zip file, you can copy the content of the samples subdirectory to the same samples subdirectory for the CA Identity Manager Administrative Tools.

Using these files and the embedded eTrust Directory, you can create the NeteAuto user data store we use for this book.

Create the neteauto DSA Using eTrust Directory

CA Identity Manager comes with an embedded eTrust Directory where you can create the NeteAuto LDAP user data store. This sample user data store might have been created automatically by the installation program. If you need to create it manually, you first need to locate the machine where you have eTrust Directory installed. Logon to the machine using an ID that has both Ingres and eTrust Directory privileges. We suggest that you use a system ID.

Assuming you have the CA Identity Manager Administrative Tools installed on this machine and you have the sample files described in Appendix B copied to it, you can run the create.bat to create the neteauto DSA similar to the sample user data store created for you by the install program.

The following is the content for create.bat:

dxnewdsa neteauto neteauto 3895 dc com dc security

dxserver install neteauto

Back Up the neteauto User Data Store

Since we are replacing the out-of-the-box NeteAuto database with our own content, you may want to consider backing up the one you have been using. The dump.bat file stores a copy of your data from the neteauto database into the neteauto_dump.ldif file and sorts it into neteauto_sorted.ldif.

The following is the content for dump.bat:


dxserver stop neteauto

dxdumpdb -S neteauto -p "dc=security,dc=com" -f neteauto_dump.ldif neteauto

ldifsort neteauto_dump.ldif neteauto_sorted.ldif

dxserver start neteauto

Load NeteAutoDB.ldif

Use the load.bat file directly under the samples\neteAuto\Organization subdirectory to shut down the neteauto dsa, overwrite its database content with the NeteAutoDB.ldif content, and restart the dsa. The following is the content of the load.bat:

dxserver stop neteauto

dxloaddb -S neteauto -p "dc=security,dc=com" NeteAutoGB.ldif neteauto

dxserver start neteauto

NeteAutoDB.ldif Content

This sample user data store contains a number of organizations and users for the three IMEs.

Most of the identities stored in the sample NeteAutoDB.ldif are employees. Of these identities, they are categorized into system identities, Employee IME sample users, Customer IME sample users, and Vendor IME sample users.

To simplify the usage of these samples, all identities use “test” as the password.

System Identities

System users are the identities required for an IME to be set up.

■ NeteAuto Administrator: the proxy identity used to create the three Identity Manager Directories for the three IMEs:

uid=NeteAuto Administrator,ou=People,ou=Employee,ou=NeteAuto,dc=security,dc=com SuperAdmin: the identity used as the System Manager for all three Identity Manager Environment. uid=SuperAdmin,ou=People,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ SelfRegUser: the personality identity used for the Public Tasks used for all three IMEs:

uid=SelfRegUser,ou=People,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ CorpUser: the personality identity used for Inbound Synchronization initiated from eTrust Admin. It is only used by the Employee IME:

uid=CorpUser,ou=People,ou=Employee,ou=NeteAuto,dc=security,dc=com


Employee IME Objects

IDENTITIES

■ esm: the identity that has Employee System Manager Admin Role

uid=esm,ou=people,ou=Information

Security,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ hdr: the identity that has Employee Help Desk Admin Role

uid=hdr,ou=people,ou=Help Desk,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ hrmgr: the identity that has Employee Human Resource Admin Role and Employee Supervisor Admin Role. Hrmgr is the manager of hr.

uid=hrmgr,ou=people,ou=Help Desk,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ hr: the identity that has Employee Human Resource Representative Admin Role.

uid=hr,ou=people,ou=Human Resource ,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ bad: the identity that has Employee Self Service and Employee Supervisor Delegation Admin Role.

uid=bad,ou=people,ou=Business

Application,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ badmgr: the identity that has Employee Supervisor Admin Role. Badmgr is the manager of bad and vrr1.

uid=badmgr,ou=people,ou=Business Application

,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ pra: the identity that has Employee Provisioning Role Administrator Admin Role.

uid=pra,ou=people,ou=Information


■ pro: the identity that has Employee Provisioning Role Owner Admin Role

uid=pro,ou=people,ou=Information


ORGANIZATIONS

■ Account Provisioning Packages: the organizational unit used to contain all self-subscribing groups used to request account packages. This object is used in the employee Identity Manager Directory and as a result, self-subscribing groups defined elsewhere are ignored in the Employee IME.

ou=Account Provisioning Packages,ou=Information



ISAccessPackages and SalesAccessPackages: used to organize account provisioning packages and give the users the hints what they are about ou=ISAccessPackages,ou=Account Provisioning Packages,ou=Information Security,ou=Employee,ou=NeteAuto,dc=security,dc=com ou=SalesAccessPackages,ou=Account Provisioning Packages,ou=Information Security,ou=Employee,ou=NeteAuto,dc=security,dc=com

GROUPS

■ ISAnalyst: a self-subscribing group under ISAccessPackages that represents an account provisioning package designated for an Information Security Analyst.

cn=ISAnalyst,ou=groups,ou=ISAccessPackages,ou=Account Provisioning

Packages,ou=Information Security,ou=Employee,ou=NeteAuto,dc=security,dc=comx

■ SalesHomeBase and SalesHQBase: two self-subscribing groups under SalesAccessPackages that represent two account provisioning packages designated for Sales.

cn=SalesHomeBase,ou=groups,ou=SalesAccessPackages,ou=Account Provisioning

Packages,ou=Information Security,ou=Employee,ou=NeteAuto,dc=security,dc=com cn=SalesHQBase,ou=groups,ou=SalesAccessPackages,ou=Account Provisioning Packages,ou=Information Security,ou=Employee,ou=NeteAuto,dc=security,dc=com

Customer IME Objects

IDENTITIES

■ CustomerPublic: the personality identity that provides the Public Directory application in Customer IME.

uid=CustomerPublic,ou=people,ou=Customer,ou=NeteAuto,dc=security,dc=com

■ csr: the identity that has Customer Service Representative Admin Role. This user is a member of the Customer Relationship, Employee organization.

uid=csr,ou=people,ou=Customer

Relationship,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ csm: the identity that has Customer System Manager Admin Role. This user is a member of the Information Security, Employee organization.

uid=csm,ou=people,ou=Information


■ ccm: the identity that has the Customer Certification Manager Admin Role. This user is a member of the Information Security, Employee organization.

uid=ccm,ou=people,ou=Information


GROUPS

■ American Car Owners Group: a self-subscribing group for Customer IME.

cn=American Car Owners

Group,ou=groups,ou=Customer,ou=NeteAuto,dc=security,dc=com


Asian Car Owners Group: a self subscribing group for Customer IME cn=Asian Car Owners Group,ou=groups,ou=Customer,ou=NeteAuto,dc=security,dc=com

■ European Car Owners Group: a self-subscribing group for Customer IME.

cn=European Car Owners

Group,ou=groups,ou=Customer,ou=NeteAuto,dc=security,dc=com

Vendor IME Objects

IDENTITIES

■ vsm: the personality identity that has the Vendor System Manager role. This user is a member of the Information Security organization.

uid=vsm,ou=people,ou=Information


■ vr: the personality identity that has the Vendor Organization Manager role. This user is a member of the Vendor Relationship organization.

uid=vrr1,ou=people,ou=Business

Application,ou=Employee,ou=NeteAuto,dc=security,dc=com

■ vrr1: the personality identity that has the Vendor Visit Registrar role. This user is a member of the Business Application organization.

uid=vr,ou=people,ou=Vendor


■ vrr2: the personality identity that has the Vendor Receptionist role. This user is a member of the Physical Security organization.

uid=vrr2,ou=people,ou=Physical


■ vrmgr: the personality identity that has the EIM Supervisor Admin Role. This user is a member of the Vendor Relationship organization, and he is the manager of the vr user.

uid=vrmgr,ou=people,ou=Vendor



Appendix D: IME XML Files and Tools In this appendix, we discuss the XML files that we used to create our three IMEs. These files are provided under the subdirectory for each IME; see Appendix B for more information about the zip file for this book. We also suggest procedures and tools you can use to create a portable RoleDefinitions.xml file to move some of your role and task definitions from a development environment to a production environment.

IME XML Files

Other than the CA SiteMinder Policy Server utilities that can be used to back up and restore the policy data store, CA Identity Manager uses three XML files to help you create and back up your IME. The exported versions of these files contain the instructions on how they can be configured.

To help create the three sample IMEs, the three XML files for each environment are included in the zip file accompanied with this book; see Appendix B for the overall structure of the zip file.

Directory.xml

Directory.xml is a file used to configure an Identity Manager Directory that describes the structure of a user data store. It is used at the time an Identity Manager Directory is being created. The run-time version of a Directory.xml is stored in the policy data store and can be exported and updated through the Identity Manager Management Console. For more information about this file, see Chapter 2 of this book and the CA Identity Manager Configuration Guide.

The provided Directory.xml files were designed with portability in mind. In this book, we use NeteAuto as our user data store. However, if you have a hierarchical LDAP user data store of your own, it may actually be possible to modify these Directory.xml files so that the objects and attributes map to yours. If this works, then you can further use the corresponding RoleDefinitions.xml to recreate the same sample environment in this book. What makes this portability possible is that we define our own well-known attributes and use only well-known attributes in our directory.xml file.

We have also configured these Directory.xml files so that you only need to specify the machine name and port number where you have your NeteAuto user data store installed. You also need to specify the password for the NeteAuto administrator.

As of this writing, an update is required to the self-subscribing group definition for our intended employee-Directory.xml. As a result, after you have created the employee Identity


Manager Directory, you need to export it and change it with the single line provided in the selfsub.txt file, and then update it using the modified file.

RoleDefinitions.xml

A RoleDefinitions.xml file is a configuration file that contains the definitions of the role and task settings for an IME. You can export and update the run-time version of an existing IME using the Identity Manager Management Console and then use the resulting RoleDefinitions.xml file when creating a new IME.

Provisioning role definitions are also included in the RoleDefinitions.xml. However, you need to take care when using them. This is because a provisioning role actually exists in two places. The definitions that exist in a RoleDefinitions.xml file are a representation of what can be in the Identity Manager Policy Data Store. The real provisioning role actually exists in the Administrative Directory of the Provisioning Server.

To use a RoleDefintions.xml file that contains provisioning roles requires the IME to have a Provisioning Directory first or it does not work. Even when you have met this requirement, make sure the roles exist in the Administrative Directory of the Provisioning Server. If it is necessary to use such a file, you can first use the eTrust Admin Win32 Manager or its equivalent to have the roles created.

EnvironmentSettings.xml

An EnvironmentSettings.xml is a configuration file that contains environment-related settings that are done through the Identity Manager Management Console under Identity Manager Environments, <Environment Name>, Advanced Settings. The WorkPoint workflow, e-mail, logical attribute handler, identity policy setting, Web Services, and provisioning mentioned in this book can be set using an EnvironmentSettings.xml file.

An EnvironmentSettings.xml file contains provisioning settings. The corresponding provisioning directory needs to be defined first as an Identity Manager Directory.

Create Portable RoleDefinitions XML File

Once CA Identity Manager is put into production, you may be asked to address new requirements for your identity management system. The procedure to address the new requirements may include the following:

■ Model the new requirements in a development environment

■ Test the new Admin Role, Admin Task, and so on

■ Perform official User Acceptance Testing

■ Put in change control

■ Move the changes to the production environment


The challenge here is to move the changes to production since your development environment can actually differ from your production environment enough that you cannot export the whole Role and Task Setting and then import it into production. In this section, we suggest that you use some basic tools to help.

Prerequisites

The procedure suggested requires the GNU DiffUtils which can be downloaded from the following URL:

http://gnuwin32.sourceforge.net/packages/diffutils.htm http://gnuwin32.sourceforge.net/packages/diffutils.htm

See Appendix A for other related information.

You also need the three files, prolog.txt, epilog.txt, and GenRoleXML.bat included in the sample zip that accompanies this book; see Appendix B for the structure of the sample zip file.

With the prerequisites met, this section provides two sets of procedures to help you create the portable RoleDefinitions.xml files. The Increment Procedure shows you how to prepare and create an XML file before you start working on the new roles and tasks. The Decrement Procedure is not fail safe, but shows you how to do that after the roles and tasks have been created.

Increment Procedure

The basic procedure is comprised of the following steps:

1. Export the current role and task settings.

2. Use the Identity Manager User Console to model and test the new requirements.

3. Export the new role and task settings after you are satisfied with development effort.

4. Use the diff utility in diff -e to compare the two RoleDefinitions.xml files and generate the differences in a .txt file.

5. Clean up the difference file for the next step.

6. Use GenRoleXML.bat to create the RoleDefinitions.xml file from the .txt file and other utility files.

http://gnuwin32.sourceforge.net/packages/diffutils.htm


The challenge of this approach is that an IME is, by design, a multi-user system. As a result, the development efforts from different individuals can interfere with each other and cause the diff results to be hard to clean up.

Decrement Procedure

Instead of using the increment procedure, you can take a different approach to obtain the differences between two RoleDefinitions.xml files.

The procedure assumes the development of the roles and tasks has been done and takes the following steps:

1. Export the current role and task settings.

2. Use the Identity Manager User Console to remove the Admin Tasks and Admin Roles you want to capture.

3. Export the new role and task settings after the removal.

4. Use the diff utility in diff -e to compare the two RoleDefinitions.xml files and generate the differences in a .txt file.

5. Clean up the difference file for the next step.

6. Use GenRoleXML.bat to create the RoleDefinitions.xml from the .txt file and other utility files.

7. Import the generated xml file to recover the removed roles and tasks.

This approach certainly has the similar challenges caused by the multi-user nature of the system. Also, it is more difficult to remove and capture components at the screen level as it is harder to remove them from the Identity Manager User Console.

Export Role and Task Settings

You use the Identity Manager Management Console under Identity Manager Environments <Environment Name>, Advanced Settings to export the current role and task settings for an IME. When saving the files, you may want to append a version number to them to make it easier for you to use the diff program to determine the differences. For example, you may have customer-RoleDefinitionsS1.xml, customer-RoleDefinitionsS2.xml files.

diff Utility and Clean Up

Once you have the RoleDefinitions.xml files saved and DiffUtil installed, you can use the diff utility to generate the differences between the versions of the file. For example, you can run the command as follows:


diff -e customer-RoleDefinitionsS1.xml customer-RoleDefinitionS2.xml >

diff.txt

The -e parameter asks the diff utility to generate the differences in an edit script format. The order of the two parameters used in the diff command depends on whether it is an increment procedure or decrement procedure. Since we are generating a third file, if you do not remember the order, you can always rerun the diff command using a different order.

To clean up the diff.txt, open it up using notepad and save it into an appropriately named file like newRequirement.txt. The clean-up is a manual process. The following is a list of hints to help you:

■ Entries beginning with a number followed by a “c” can be removed as they tend to be lines that are in different orders between versions.

■ Entries beginning with a number followed by an “a” are lines you want to keep. You must remove the “a” line and the line contains only a single “.”, so that you are keeping everything between them. You can also verify it by looking at the content of these lines to see what objects they are describing.

■ Entries beginning with a number followed by a “d” tell you that there were objects being removed. You can either remove these lines or run the diff command with the parameters in a different order to find out what they are and decide what to do with them.

■ Remember to save the edited content for the GenRoleXML step.

GenRoleXML.bat:

GenRoleXML.bat takes a parameter and assumes that there exists a file with a .txt extension. It concatenates the prolog.txt file, the txt file, and the epilog.txt to form a new .xml file. For example,

GenRoleXML newRequirement

creates a newRequirement.xml.

The actual content of the GenRoleXML.bat is:

@echo off

REM

REM GenRoleXML.bat roleDiffFile

REM

setlocal enableextensions

type "%~dp0prolog.txt" > “%~1.xml”

type “%~1.txt >> %1.xml

type "%~dp0epilog.txt" >> %1.xml


Appendix E: Logical Attribute Handler In this appendix, we discuss the concept of physical attributes, logical attributes, logical attribute handlers and their relations with Admin Task Screens. We also take you through the ManagerDnAdaptor used in this book.

Admin Task Screen and Logical Attribute Handler

A common Admin Task screen displays identity-related attributes in multiple columns. Each column consists of one or more fields that represent the identity-related attributes. To help make sense of the information being presented, a displayed attribute is accompanied by a label called Name. For example, on a user profile screen, “First Name” and “Last Name” might be the “Field Names” associated with the attributes firstname and lastname, respectively, in the underlying user data store. Each field can also be defined with other Web Browser graphical control.

CA Identity Manager also uses the concept of physical attribute, logical attribute and logical attribute handler to allow complex presentations and handling of the identity attributes.

Physical Attribute

Physical attributes are attributes of the underlying user data store. When a task screen field is configured with a physical attribute, a value entered into the field is ultimately written to the data store.

For example, a Last Name field on a user profile screen might be configured with a lastname attribute in the underlying user directory. When a user enters a value into the field and clicks Submit, the value is written to the lastname attribute in the directory. When a user next displays the profile screen, the value is retrieved from the lastname attribute of the directory and displayed in the Last Name field.

Logical Attribute

Logical attribute values are not directly associated with or written to the user data store. A logical attribute value is presented in a task screen field and processed by a logical attribute handler.

The result of the processing may be written to the data store if the logical attribute is mapped to a physical attribute, or the result may be used in some other way. For example, a full name is really a combination of the first name, last name, and possibly others.

The out-of-the-box examples provide a number of logical attributes including the self-service questions and answers.


Attribute Data Flow

When an Admin Task Screen Field is associated with a physical attribute, data in this field flows to and from the corresponding physical attribute in the user data store directly. The attribute value is sent to the task screen from the user data store just before it is displayed. Values are sent from the task screen to the user data store when the user executes (submits) the task and a change is committed.

If a task screen field is associated with a logical attribute, a logical attribute handler is invoked and possibly involves one or more physical attributes on the user data store to determine the actual attribute value and the impact to the user data store.

Logical Attribute Handler

Since a logical attribute handler comes between the logical attribute that exists on the Admin Task Screen and the physical attribute that exists in the user data store, it allows customization opportunities such as the following:

■ Controlling the way physical data is presented on the task screen

■ Validating data that users supply on the task screen

■ Integrating your enterprise's business logic and rules with the presentation of the attribute value

Logical Attribute API

CA Identity Manager provides a set of Logical Attribute APIs to help you with the data presentation on an Admin Task Screen. Logical attribute handler execution occurs in the synchronous phase of task processing and can introduce response time issues if not done carefully. Instead of using LAH, some of the onscreen data values validations can be accomplished through validation rules defined in Java, JavaScript or Regular Expressions.

As you look into the logical attribute handler and Logical Attribute API, the objects and attributes referenced in a LAH have their run-time implications. The LAH can only reference the attributes that are defined on the screen that is associated with the Admin Task. Since an LAH is developed somewhat independent from the design of a screen, there may be a time when you accidentally try to ask an LAH to access attributes that are not defined on a screen.

ManagerDNAdapter Example

In this section, we want to show you an LAH we use for this book.

When we design the Supervisor Admin Role for the Employee IME in Chapter 3, “Delegated Identity Management,” we were forced to use the following scope rule:


where ( Department = admin's User ID )

and who are in (

organization "Employee" and lower )

instead of using

where ( Manager = admin's User ID )

and who are in (

organization "Employee" and lower )

It was because the value of the Manager happens to be a DN and cannot be used to compare with the User ID which happens to be a short name (or uid) of the DN. To address this issue, we use the Department to store the short name to allow the scope rule to work. The new challenge then becomes that we need to populate the user profile using both the DN for the Manager and the short name for the Department. We can certainly ask the user to do both. However, this is error prone.

To address this concern, we decide to take advantage of the LAH facility and create a logical attribute handler that accepts a DN from the data entry and stores it into both the Manager and Department using the desired formats.

Build and Deploy

The sample zip file accompanied with this book contains a subdirectory employee\lah; see Appendix B for the structure. It also comes with the java class file pre-compiled under the employee\APPServer subdirectory. To actually deploy the class file, you need to copy everything including the directory structure under the employee\APPServer to the location of your Employee IME Application Server.

The rest of the discussion in this section is meant for those who want to further look into how compile and deploy the Java class mentioned above.

BUILD

The lah subdirectory of our sample files contains a build.xml and a java program ManagerDnAdapter.java used to provide the functionality we need. To rebuild the class file, use the following procedure:

1. Locate a development machine for the rest of the steps in this procedure.

2. Unzip the file that accompanies this book. See Appendix B.

3. Install the CA Identity Manager Administrative Tools.

4. Modify the build.xml to reflect where you installed the Administrative Tools. The caim.dir is set to C:/Program Files/CA/CA Identity Manager and relies on Ant 1.6.5 to work as Ant 1.5 does not support embedded space in the file name.


5. Install and set up an Ant environment and make sure the command ant is in search path. See Appendix A for where to download ant.

6. Change to the directory employee\lah and issue the following command:

ant

These steps build the ManagerDnAdapter.class and store it directory under:

..\APPServer\IdentityMinder.ear\custom\com\Netegrity\samples

DEPLOY

To deploy the ManagerDnAdapter.class file, copy it to your Identity Manager Application Server, under the following subdirectory:

<APPServerHome>/IdentityMinder.ear/custom/com/netegrity/samples

Register an LAH

An LAH needs to be registered first before it can be used in a CA Identity Manager Screen. You can do it through an EnvironmentSettings.xml file or manually.

USING ENVIRONMENTSETTINGS.XML

At the time you are building the sample Employee IME, you can import the employee-EnvironmentSettings.xml and have this LAH registered automatically. The entries that simplify this procedure are:

<LogicalAttributeHandler name="ManagerShortName" description="" class="com.netegrity.samples.ManagerDnAdapter" objecttype="USER"> <LogicalAttribute name="l_managerLongName" attr="|Manager Long Name|" multivalue="false" optionlist="false"/> <PhysicalAttribute name="p_managerShortName" attr="%GBEIM_Department%"/> <PhysicalAttribute name="p_managerDn" attr="%GBEIM_Manager%"/> </LogicalAttributeHandler>

REGISTERING AN LAH MANUALLY

To register this LAH manually, you can do it from the Identity Manager Management Console, use Identity Manager Environments <Environment Name>, Advanced Settings, Logical Attribute Handlers:

■ Name: ManagerShortName

■ Class: com.netegrity.samples. ManagerDnAdapter

■ Object Type: USER


■ Logical Attributes

> Name: l_managerLongName Attribute Name: |Manager Long Name|

■ Physical Attributes

> Name: p_managerShortName Attribute Name: %GBEIM_Department%

> Name: p_managerDn Attribute Name: %GBEIM_Manager%

The %GBEIM_Department% and %GBEIM_Manager% are well known attributes we used in the employee-Directory.xml and the employee-RoleDefinitions.xml.

Applications

We use the logical attribute |Manager Long Name| in both the LAH Create User Profile and LAH Modify User Profile screens. In both screens, we have a Manager field defined similar to the following screen:


We also have both the Manager and Department attributes defined as Hidden Attributes.

The basic idea is that when a value is entered into the |Manager Long Name| logical attribute and accepted the value is being written into the user data store. It is copied into the Manager field and reformatted into the Department field.

Similarly, to display its value, it is taken from the Manager field whenever the logical attribute |Manager Long Name| needs to be displayed.


Appendix F: CA SiteMinder Procedures In this appendix, we share two sets of CA SiteMinder procedures that provide us the necessary settings required for our sample IMEs.

First, we discuss the procedures required to use CA Identity Manager and CA SiteMinder to enable and secure the Identity Manager Task Execution Web Services. Second, we show you how the CA SiteMinder forms-based authentication method is used to help provide a custom login form and deliver the Public Directory discussed in Chapter 7.

Enable TEWS Security

CA Identity Manager provides a Task Execution Web Services (TEWS) interface that can be used for both integration and automation. Once this interface is enabled, it is available for remote machines to access. As a result, it is essential to make sure that this interface is secured as soon as it is online.

Enable TEWS

By default the TEWS interface is disabled. You enable it from the Identity Manager Management Console under Identity Manager Environments, <Environment Name>, Advanced Settings as shown in the following screen:

Since the default setting does not have this interface secured, it is possible for anyone to access an IME through the TEWS interface and bypass all security immediately after the Identity Manager Application Server is restarted.

To make sure that you have a secured IME, you need to set the TEWS security setting and secure it with CA SiteMinder. Later in this appendix we show you how this is done using two


CA SiteMinder realms and corresponding policies. For more information about TEWS and its security settings, see the CA Identity Manager Developer's Guide.

Secure TEWS

TEWS uses two parameters to determine its security settings. The use_admin_id setting determines whether the <admin_id> tag is used when processing a Web Services request. The required_sm_header setting determines whether the Web Services request needs to be accompanied by a CA SiteMinder-protected session.

These two parameters are set through the web.xml file located under <APPServerHome>/IdentityMinder.ear/user_console_war/WEB-INF. We suggest that you set the use_admin_id to be false and required_sm_header to be true similar to the following:

…

<servlet>

<servlet-name>Tews6Servlet</servlet-name>

<display-name>IM 6.0 Task Execution WebService Servlet</display-name>

<servlet-class>com.netegrity.ims.tews6.ServiceServlet</servlet-class>

<init-param>

<param-name>use_admin_id</param-name>

<param-value>false</param-value>

</init-param>

<init-param>

<param-name>require_sm_headers</param-name>

<param-value>true</param-value>

</init-param>

</servlet>

…

With this setting, TEWS uses the identity that is presented through CA SiteMinder to determine whether the Web Services requests have the privileges to do what they intend to do.

TEWS CA SiteMinder Policies

Once the require_sm_headers of the TEWS security setting is set to true, the access to the TEWS interface must be authorized by CA SiteMinder. There are many ways you configure CA SiteMinder policies. However, we suggest using two CA SiteMinder realms to protect the TEWS interface in our example.

PUBLIC ACCESSIBLE WSDL REALM

Even though we want to secure the TEWS interface, to make it easier for our developer to access the WSDL definitions, we actually want to make the following WSDL URL publicly accessible:

http://Your_Web_Server/idm/TEWS6/IMEName?wsdl


The following screen shows the SiteMinder UI screen for configuring a realm. The Resource Filter is set to /idm/TEWS6/IMEName?wsdl and the Default Resource Protection is set to Unprotected:


SITEMINDER PROTECTED TEWS REALM

To secure the TEWS, we define a separate realm that has the Default Resource Protection set to Protected as shown in the following dialog:

We also need to create an access rule to allow Web Agent actions on GET and PUT and the Resource is set to “*” not the usual “/*” in order to form a resource in the format of http://.../idm/TEWS/ENVName*:


To actually use the rule, we also need the pre-defined CA SiteMinder policy for the IME to include the rule as shown in the following SiteMinder Policy dialog:

Custom loginGB.fcc for Public Directory

CA SiteMinder allows CA Identity Manager to use a customized authentication scheme using a SiteMinder Authentication Schemes configuration.


The following screen shows how we configure our custom IME to use a form loginGB.fcc:

loginGB.fcc

The loginGB.fcc file is a CA SiteMinder Form Credential Collector file. In this case, the FCC detects the word PublicDirectory in the login attempt and logs in as customerpublic automatically. Otherwise, it displays the following login form to collect user credentials:

This form uses a client-side JavaScript. In addition to the color scheme, we also use the logoGB.gif for the NeteAuto logo.

Both loginGB.FCC and logoGB.gif files are included in the sample zip file accompanied with this book; see Appendix B for the structure of the zip file. The files must be copied to the CA SiteMinder Web Agent subdirectory as described in Appendix B.

The following is the content of the loginGB.fcc:

 @username=%USER% @smretries=0

<html>

<head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title>SiteMinder Password Services</title> <SCRIPT LANGUAGE="JavaScript"> function resetCredFields()

{ document.Login.PASSWORD.value = ""; var urlstring = window.location.search.substring(1); var urlindex = urlstring.indexOf("PublicDirectory"); if (urlindex > 0) { document.Login.USER.value = "customerpublic"; document.Login.PASSWORD.value = "test"; document.Login.submit(); } } function submitForm()

{ document.Login.submit(); } </SCRIPT> </head>

<body BGCOLOR="maroon" TEXT="#000000" onLoad = "resetCredFields();">  <IMG align="right" alt=Logo src="/siteminderagent/dmspages/logoGB.gif"> <br><br><br><center>

<form NAME="Login" METHOD="POST"> <INPUT TYPE=HIDDEN NAME="SMENC" VALUE="ISO-8859-1"> <INPUT type=HIDDEN name="SMLOCALE" value="US-EN"> <center>

 <table width="50%" height=200 border=1 cellpadding=0 cellspacing=0 > <tr> <td>  <table WIDTH="100%" HEIGHT=200 BGCOLOR="beige" border=0 cellpadding=0 cellspacing=0 > <tr> <td ALIGN="CENTER" VALIGN="CENTER" HEIGHT=40 COLSPAN=4 NOWRAP BGCOLOR="beige"> <font size="+1" face="Arial,Helvetica"> <b>Please Login</b></font> </td> </tr>


<tr> <td colspan=4 height=10> <font size=1> </font> </td> </tr> <tr> <td WIDTH=20 > </td> <td ALIGN="LEFT" > <b><font size=-1 face="arial,helvetica" > Username: </font></b> </td> <td ALIGN="LEFT" > <input type="text" name="USER" size="30" style="margin-left: 1px"> </td> <td WIDTH=20 > </td> </tr>

<tr> <td colspan=4 height=10> <font size=1> </font> </td> </tr>

<tr> <td WIDTH=20 > </td> <td > <b><font size=-1 face="arial,helvetica" > Password: </font></b> </td> <td ALIGN="left" > <input type="password" name="PASSWORD" size="30" style="margin-left: 1px"> </td> <td WIDTH=20 > </td> </tr>

<tr> <td colspan=4 height=10> <font size=1> </font> </td> </tr>

<tr> <td colspan=4 NOWRAP WIDTH="50%" HEIGHT="25" align="CENTER"> <input type=hidden name=target value="$$target$$"> <input type=hidden name=smquerydata value="$$smquerydata$$"> <input type=hidden name=smauthreason value="$$smauthreason$$"> <input type=hidden name=smagentname value="$$smagentname$$"> <input type=hidden name=postpreservationdata value="$$postpreservationdata$$"> <input type="button" value="Login" onClick="submitForm();"> </td> </tr>

<tr> <td colspan=4 height=5> <font size=1> </font> </td> </tr> </table> </td> </tr> </table> </form></center>

<script language="javascript"> document.forms["Login"].elements["USER"].focus(); </script>


</body> </html>


Appendix G: Email CA Identity Manager can be configured to generate automatic email notifications at the various stages of an Identity Manager event. In this appendix, we show you how to configure E-mail notification.

Email Notification

You can configure CA Identity Manager to generate automatic email notifications when a task or event is in progress or is complete. The following are some typical business scenarios when an email notification is helpful:

■ An employee (CA Identity Manager user) requests a temporary password through the forgotten password feature. An email with his/her temporary password is sent.

■ A vendor self-registers to use a company's CA Identity Manager portal. An email notification is sent to the new vendor with confirmation of his profile information.

■ An employee's (CA Identity Manager user) profile details such as their title and manager have been modified by HR through a user modification task in CA Identity Manager. An email notification is sent to the employee as well as the employee's manager.

■ A new hire (new user) or ex-employee is being created or removed and is being provisioned with corresponding accounts. In this case, the provisioning of this user may require manual approval of HR/IT managers and administrators as part of the business workflow process. Email notification serves to inform these approvers of a work-list item that requires their attention.

Deployment

To review instructions on how to configure email notification, see the Configure Email Notification chapter in the CA Identity Manager r8.1 SP1 Installation Guide and the Email Notifications chapter in the CA Identity Manager r8.1 SP1 Operations Guide.

We provide a set of standard JSP email templates that implementers can easily customize. These templates reside in IdentityMinder.ear\custom\emailTemplates.

You can also make use of the CA Identity Manager Notification Rule API to implement custom notification rules to determine who your recipients are. See the Notification Rule API chapter in the CA Identity Manager r8.1 SP1 Developers' Reference for more details.

Email content

Typical email notification content usually includes the name of the administrator performing the task and other data related to the task or the user. All attributes of a managed object


that must be retrieved during an email notification must be present on the relevant task screen (You can make them hidden profile fields). For example, vendors for Company ABC have associated vendor numbers that are stored as part of the user profile screen along with their user ID, first and last names in the user store. Vendor numbers are auto-generated using custom code in a business logic task handler code once a self-registration task is submitted by the vendor.

The implementation team is familiar with the actual steps to retrieve information from the task or user and prepare it for an email. The keys to enabling this functionality are the directory.xml and the event templates.

In the directory.xml, the vendor numbers are represented as follows under the user managed object:

<ImsManagedObjectAttr physicalname=”vendornumber” description=”For vendor

identification” displayname=”Vendor Number” valuetype=”String”

wellknown=”%VENDORNUM%”/>

ABC mandates that vendors who self-register must be sent an email notification with their vendor number and other profile information.

A code snippet from the completed Self Registration event template is as

follows :

template.add(“Your vendor number is: “ + user.getAttribute(“%VENDORNUM%”)

However, this line generates a Mail not sent error unless the vendor number attribute field is explicitly on the self registration task profile screen. This is similar to the information discussed in the Logical Attribute Handler API section in Appendix E.

Task and Event Email Notification

A CA Identity Manager task triggers different events. You may want to configure emails to be sent when a task has been completed or when an event has been completed or is pending. The following examples illustrate the difference between task and event email notifications:

■ You may want an email to be sent to a user when a Help Desk administrator has completed the Reset User Password task. In this case use task notification.

■ You may want an email to be sent to all group members when a new hire is created and is made a member of a group using the Create User task. In this case use event notification and configure it for the AddToGroupEvent.

Note: Task-level email notifications are not available for View-type CA Identity Manager tasks such as View User.

Suppose you have an approval process that involves multiple approvers. In this case, you may want a different email template to be sent based on who the approver is at each stage of the workflow process. For example, approver_1 may receive an email based completely on the out-of-the-box event pending email template. The next approver, approver_2 may


receive an email saying, “Approver_1 has approved this task. Your approval is now required” and may want the email to have an extra attribute of the user exposed on the email. This is currently not possible out-of-the-box because email notification works on the premise of event-level and task-level notifications only.

However as with most things in CA Identity Manager there is a well-designed customization capability that enables an implementation team to accomplish this requirement. A high-level description of a possible solution is described here for the purpose of stimulating discussion with your implementation team. The method for unique emails for different levels of approvers is to add a flag on the user data tab of the WorkPoint activity which indicates whether email notification is enabled or disabled for that activity. When WorkPoint calls back into CA Identity Manager using a script configured on the activity, CA Identity Manager knows whether to send an email for that activity. See Appendix H and the CA Identity Manager Operation Guides for more information.

Application Server Email Services

Before email notifications will work, you must configure your SMTP server. For instructions on how to set up the SMTP server, see the CA Identity Manager Installation Guide for your application server and other appropriate application server product documents for further details.

Next, you need to set up the Admin email address that serves as the sender for the actual emails. To do this edit the email.properties file in the <APPServerHome>/IdentityMinder.ear/config/com/Netegrity/config directory. For example, you may set the admin.email.address in this file as the following:

[email protected]

mailto:[email protected]

Email Notification Configuration

To enable the email, you can either use an EnvironmentSettings.xml file or do it manually. The zip file that accompanies this book contains three EnvironmentSettings.xml files for the three environments. When you import these files to the corresponding environment, email is enabled automatically.

The rest of this section shows you how to do it manually.

mailto:[email protected]


Enabling Email and Setting Template Directory

You first need to enable email in the Identity Manager Management Console under Identity Manager Environments, <Environment Name>, Advanced Settings, E-mail:

From this screen, you can see we selected the default as our Template Directory. More information about the template directory is given later in this appendix.

You also need to decide when to send an email.

Deciding When to Send Email

CA Identity Manager allows you to decide the list of events for Workflow purpose and/or Admin Tasks for other alerting purposes that actually trigger email notifications.

From Identity Manager Environments, <Environment Name>, Advanced Settings, E-mail:

for workflow related selection, and

to search and add the list of tasks from which email notification can be sent. CA Identity Manager email is event based. The selection of an Admin Task means selecting the related events for the task.

Email Templates

Identity Manager comes with several sample email templates to give you a head start. You can find these under the emailTemplates directory in the Identity Manager administrative tools directory.

See the CA Identity Manager Configuration Guide for information on configuring the email template directory to work with your application server. The default physical location for the templates that are being used by CA Identity Manager is:

<APPServerHome>/IdentityMinder.ear/custom/emailTemplates/default

There are four template folders, Approved, Completed, Pending, and Rejected. Each represents the status of an event.

To create your own template, copy and rename one of the default templates or copy the sample below. The name must match the name of the event to which the email applies, and have the extension .tmpl. The following sample sends a notification to a user and the manager letting them know that certification is required.

For our sample environments, when you copy the whole APPServer subdirectory into your corresponding CA Identity Manager application server deployment, the templates will be in place.

Sample CertificationRequiredNotificationEvent.tmpl

A sample template is shown below:



<%

_to = _util.getNotifiers("USER_MANAGER", "ManagerLookup=managerattribute");

_cc = _util.getNotifiers("USER");

_bcc = "" ;

_subject = "Certification Reminder - Certification is required for: " +

eventContextInformation.getPrimaryObjectName();

%>



<html>

<head>

<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">

<style>

body { font-family: sans-serif; font-size: 10pt; }


th { font-family: sans-serif; font-size: 8pt; font-weight: bold; background:

#c0c0c0; }

td { font-family: sans-serif; font-size: 8pt; }

</style>

</head>

<body>

<br>

<table width="70%" border="1" bgcolor="maroon">

<tr>

<td>

<br>

<center><img src="http://your server name/auto/images/logo.gif">

<br>

<br>

<p><font color="white" size="3"><b>This a reminder that the certification status for

<%= _eventContextInformation.getPrimaryObjectName() %> is

<b><%=

_eventContextInformation.getEvent().getUser().getCertificationStatus().getDisplayVal

ue() %></b>.

You are required to complete a Certify User task for

<%= _eventContextInformation.getPrimaryObjectName() %> prior to the end of the

certification process.

The end of certification process non-compliance action will be applied to

<%= _eventContextInformation.getPrimaryObjectName() %> if the Certify User task has

not been completed <b>before</b> the end of the certification process.

</b></font>

</p>

<br>

</td>

</tr>

</table>

</body>

</html>

An email template is a dynamic file that supports both HTML and embedded server-side JavaScript. A template lets you insert variable values into static text, allowing case-specific messages to be generated from a single template.


In the sample above we have created custom html that displays the following email message:

Email Templates Elements

RECIPIENTS

In our sample template we have included calls to the following methods:

■ to. Adds recipients to the message's To field.

■ cc. Adds recipients to the message's CC field.

■ bcc. Adds recipients to the message's BCC field.

■ subject. Specifies the subject of the email.

EMAIL ADDRESS

We are also using the util.getNotifiers method to dynamically populate the To and CC fields with the manager and user email addresses. The default values can be used the method include:


ADMIN

Sends the email to the administrator who initiated the task.

USER

Sends the email to the user in the current context.

USER_MANAGER

Sends the email to the manager of the user in the current context.

Note: To use the above template, a user must have a manager and this attribute must be configured in the Miscellaneous section of the Advanced settings.

OTHER JAVA METHODS

There are several other methods that can be launched by the email template. For more information about these methods, see the Email Notifications section of the CA Identity Manager Operations Guide.


Appendix H: Workflow CA Identity Manager is tightly integrated with WorkPoint Workflow. See the CA Identity Manager Operations Guide for more information.

WorkPoint Workflow

WorkPoint Workflow has gone through some corporate transitions. At one point, it was known as InSession WorkPoint, which is still the name that appears on some of the CA product documentation. Currently, it is known as WorkPoint Workflow.

Enable WorkPoint Workflow

To enable WorkPoint Workflow, you must perform some configuration steps to set up the support environment, to create the workflow database, and to populate the database with possible customized workflow processes before you can enable it. For more details, see the appropriate version (JBoss, WebLogic, WebSphere) of the CA Identity Manager Installation Guide.

For our Employee IME, we enable Workflow through the import of the employee-EnvironmentSettings.xml file.

WorkPoint Workflow is enabled through the Identity Manager Management Console, under Identity Manager Environments, <Environment Name>, Advanced Settings, Workflow (WorkPoint):

ADMIN TASKS AND EVENTS

CA Identity Manager workflow is event based. Even though an Admin task is the smallest unit that can be granted to a user, an Admin task may trigger multiple CA Identity Manager events. For example, when a Create User task is submitted, it triggers the


SetPrimaryObjectEvent and CreateUserEvent. Since an Admin Task can potentially trigger multiple events, it can also trigger multiple workflow processes.

An Admin Task also must be workflow-enabled before the system actually considers sending its events through the workflow engine. To do that, you must check the Enable Workflow box as shown in the Admin Task section in Chapter 3.

TASK-INFLUENCED WORKFLOW

In a CA Identity Manager environment, the default workflow approval processes are mapped to events defined in the CA Identity Manager Management Console. Alternatively, you can specify the mappings on events in a specific task. This approach provides much needed flexibility. Even though two similar Admin tasks can trigger the same event, you can configure the approval process at the Admin task level. Therefore, you can have different workflow processes defined for the different audiences that are involved. The Admin Task level workflow process designation overwrites the default workflow mappings.

When an event mapped to a workflow process is triggered, the workflow process begins. The task that triggered the event is placed in a pending state and is considered under workflow control.

Workflow Process

A CA Identity Manager Admin Task, such as the creation of an account in a target system, like Active Directory, sometimes requires approvals by a Manager and/or System Administrator. The WorkPoint workflow component of CA Identity Manager can be used to implement this manual approval process.

WORKFLOW APPROVAL TASKS

The workflow process activities are associated with a special kind of Admin task referred to as a Workflow Approval task. If you look back to the Admin Task screen in Chapter 3, a Workflow Approval Task uses Approval as its Action on the Profile Tab. Usually, you create a corresponding Approval Task for each Admin Task that requires approval. For example, the out-of-the-box Create User task has a corresponding Approve Create User task.

WORKPOINT DESIGNER

WorkPoint provides a WorkPoint Designer to design and manage WorkPoint workflow processes. For general information about workflow concepts and for information about creating workflow processes, see the WorkPoint HTML documentation provided with the CA Identity Manager administrative tool installation:

<im_admin_tools_dir>\WorkPoint\docs\designer\default.htm

Assuming we have associated a WorkPoint workflow process with the Create User Admin Task when a user submits the Create User task, the workflow associated with this task is started.


Let's further assume that within this workflow, there is an Activity Node, whose Resources tab uses a java class supplied by CA Identity Manager to resolve the Approvers of this Create User task.

TASK_TAG

The java class communicates with the CA Identity Manager application server and passes it the name of the task that requires approval. This name was already predefined by the creator of this workflow process. It can be found on the User Data tab of the Activity Node. The value is taken from the TASK_TAG variable.

The CA Identity Manager application server then examines the task tag name it receives and looks up the Approvers for that task tag. (Recall that when an Identity Manager task is defined, it has both Display name and a Task Tag value). In this case, the task tag name is ApproveCreateUser.

If we examine the Admin task named Approve Create User, we see that the task tag name is indeed ApproveCreateUser

Further, if we look at the Role Use tab, we see that any user that has Admin Role User Approver will be allowed to approve this task.


Therefore, the CA Identity Manager server returns a list of Approvers to WorkPoint by listing all of the users who belong to the User Approver Admin Role.

WORK LIST

Once WorkPoint receives the list, it continues it's processing by placing a Work Item in each of the Approvers' work lists:

PARTICIPANT RESOLVER RESOLUTION

CA Identity Manager allows other ways to specify approvers (also known as participants) for an activity node in a workflow. If you specify one of these other ways, it overrides the default mechanism of the TASK_TAG example we looked at in the previous section. The following options can also be used to as participant resolvers:

■ Custom

■ Role

■ Filter

■ Group

If you specify more than one of these options in the User Data tab of the Activity Node, the order of precedence is listed as: Custom, Role, Filter, Group. Once any of the participants based on this order is located, any remaining resolvers are ignored. Usually, you use one option at a time.

For more details, see CA Identity manager Operations Guide.


CREATING YOUR OWN WORKFLOW APPROVAL TASK

In the CA Identity manager Operations Guide, you can find step-by-step instructions on creating your own approval tasks. The main thing to remember is to assign the task to an Admin Role and make sure the role has members to do the approval.

Approved or Rejected

At the time an approver is looking at the request approval screen, the approver has the opportunity to change the original request based on a screen configured through the Admin Task tab.

When all activities in a workflow process are performed, the event mapped to the workflow process is released from workflow control. When all events triggered by a given task are released from workflow control, the workflow-controlled task is complete.


Appendix I: TEWS Client Programs CA Identity Manager provides a Web Services implementation called Task Execution Web Services (TEWS). External applications send requests and receive responses from the Web Services interface. The requests and responses consist of Simple Object Access Protocol (SOAP) XML messages.

In CA Identity Manager r8.1 SP1, the installation of the CA Identity Manager Administrative Tools component installs three subdirectories, Axis, dotNet, and Xml, under samples\WebService. These samples provide a head start on building our own Web Services Client programs.

In this appendix, we start with the Axis-based Web Services client programs and give you the tools needed to generate the TEWS client library and build your standalone TEWS client program.

We discuss how a third party Web application uses a JSP page with a TEWS call to integrate with CA Identity Manager.

We conclude our TEWS client program discussion with the GNU wget that can be used as a generic Web Services client program and show you other utilities we build around it to help you with your automation and batch jobs.

Generate a Java Web Services Client Library

CA Identity Manager offers a Web Services-based API called TEWS for external applications. After enabling the Web Services interface, Apache Axis can be used to convert the WSDL (obtained from an HTTP request to the CA Identity Manager environment) to Java programs.

Three sets of samples file are included with the zip file provided with this book. The customer\webservices, employee\webservices, and vendor\webservices subdirectories include files that were modified from the CA Identity Manager Administrative Tools samples\Webservice\Axis.

The sample files include an Apache Ant build.xml file that makes the WSDL2Java request and compiles the generated Java classes into a stand-alone JAR file. The stand-alone JAR file serves as the library for multiple client programs to share.

Prerequisites

The prerequisite the third party components for the examples in this book include the following:

■ Java Development Kit 1.4.2, Release 13

http://java.sun.com/products/archive/ http://java.sun.com/products/archive/

■ Apache Ant 1.5

http://ant.apache.org http://ant.apache.org

Since Ant is used as a building utility, it really has no impact to the final binaries. The new version Apache Ant 1.6.5 works fine. This newer version supports subdirectory names with embedded blanks.

■ Apache Axis 1.3

http://ws.apache.org/axis/ http://ws.apache.org/axis/

Identify a development machine. Complete the AXIS installation as directed by the Apache installation information. Copy the activation.jar and mailapi__V1.3.2.jar off the IdentityMinder.ear\library to the Apache Axis AXIS_HOME\lib directory.

■ Java Activation Framework

http://java.sun.com/products/javabeans/glasgow/jaf.html http://java.sun.com/products/javabeans/glasgow/jaf.html

■ Java Mail

http://java.sun.com/products/javamail/ http://java.sun.com/products/javamail/

This machine does not need any CA Identity Manager components installed directly on it.

Configuring Your IMEs

Under each of the three webservices subdirectories, you can find an Apache Ant build script called build.xml. The script includes tasks to clean any previous build artifacts, to prepare for a new build, to download, to convert a WSDL to Java classes, to compile the generated Java classes, and to archive the compiled Java classes into a stand-alone, distributable JAR file. We need to modify it to reflect our particular environment.

From the build.xml file, the following lines need to be modified to match your installations:

…



<property name="wsdl.server" value="<your server name>"/>

<property name="wsdl.environment" value="customer"/>

<property name="axis.dir" value="C:/axis-1_3"/>

…

Specify the value of wsdl.server to be the name of your CA Identity Manager Web server name and port number. Also specify the value of wsdl.environment with the IME name to make sure it matches the environment name you are using. Finally, you must specify the value of axis.dir to be the location where you installed Axis.

http://java.sun.com/products/archive/

http://ant.apache.org/

http://ws.apache.org/axis/

http://java.sun.com/products/javabeans/glasgow/jaf.html

http://java.sun.com/products/javamail/


Building Your TEWS Client Library

Once you have an Apache Ant environment set up correctly, you can run the following command to build your TEWS Client Library:

ant

Here is the Customer IME example. In this case, some utility files are collected and the tews-customer.jar file is created under the dist subdirectory:

C:\gb\customer\webservices>ant

Buildfile: build.xml

generateProxies:

[mkdir] Created dir: C:\gb\customer\webservices\wsdl2java

[axis-wsdl2java] WSDL2Java http://gbcustomer.security.com/idm/TEWS6/customer?wsdl

compile:

[mkdir] Created dir: C:\gb\customer\webservices\build

[javac] Compiling 1590 source files to C:\gb\customer\webservices\build

build:

wsclient:

copyDep:

[copy] Copying 1 file to C:\gb\customer\webservices\dist













dist:

[jar] Building jar: C:\gb\customer\webservices\dist\tews-customer.jar

BUILD SUCCESSFUL

Total time: 2 minutes 4 seconds

C:\gb\customer\webservices>

Rebuilding Your TEWS Client Library

For a production server, your environment is generally stable. There is usually no need to rebuild your TEWS client library.


ADMIN TASK DEPENDENCY

If you modify or add any Admin Tasks that are needed for your TEWS client programs, then you may need to rebuild and redeploy the TEWS client library.

CA IDENTITY MANAGER SERVER DEPENDENCY

The WSDL2Java program that helps build your TEWS client library actually includes your machine name, port number, and IME name in your TEWS client library. This means that the TEWS client library determines which CA Identity Manager to communicate with, not the TEWS client program you actually develop.

This is the reason why we could not have included a pre-built TEWS client library in the zip file that accompanies this book. You must download the Ant and Axis and build your own TEWS client library.

Standalone TEWS Client Program

The basic steps to create a standalone TEWS client program and move it to a production system include the following:

1. Code your client program

2. Compile and debug your client program

3. Move the your client program to a production server

Code Client Program

Follow the procedure described earlier in this appendix to prepare your development environment. The java files in the CA Identity Manager Administrative Tools installation directory, samples/WebService/Axis, provide a good reference to help you develop your own Web Services client program.

You are encouraged to store your java programs under the three webservices subdirectories. If you are setting up your own IME, you can use any one of these subdirectories as a template and create your own subdirectory to store your java programs as it is likely your production IME will be very different from the sample neteauto and any of the three environments introduced in this book.

The SampleUtlis.java, LogHandler.java, client-config.wsdd are the three utility files you do need to retain. You can use some of the examples that come with the sample java programs to see how they work.

We suggest that you get to know and use Eclipse to help develop the CA Identity Manager Web Services client program. More information is given later when we discuss the Eclipse Web Services Explorer.


SAMPLEUTILS.JAVA

SampleUtils.java provides a sample exception handler that shows how the Web Services responses from our CA Identity Manager are handled.

LOGHANDLER.JAVA AND CLIENT-CONFIG.WSDD

client-config.wsdd is a configuration file that changes Axis client program behavior. With the content that is provided from the CA Identity Manager installation, it invokes the logging facility provided by LogHandler.java. During the execution of the client program, the existence of the client-config.wsdd file and its original content causes the client program to write out the XML SOAP messages and responses that are sent to and from the CA Identity Manager server.

ENABLEDISABLEUSERS.JAVA

The Java programs EnableDisableUsers.java under the employee\webservices and customer\webservices directories are written to use SuperAdmin to enable or disable users. It can also be used to check whether your Web Services security has been configured correctly.

Compile and Debug Client Program

If you have stored your own java files under the webservices subdirectory, then running the ant program will compile your Java files and store the corresponding class files under the build subdirectory. The class files are actually added into the tews-ENVName.jar file under the dist subdirectory too.

Use the following command to test run your program:

ant runsample -Dclassname=yourJavaClassName

Move Client Program to Production

After you are satisfied with your programs, move your client program to a production server where you have the supported Java Run Time installed. You need the following to allow it to run on a separate production server:

■ Install the same version of JRE or JDK as your development environment: 1.4.2, Release 13.

■ Designate a subdirectory to copy all the files under the dist subdirectory.

WSCLIENT.BAT

A wsclient.bat is generated by the ant program according to the IME name and stored in the dist subdirectory similar to:


java -cp .;activation.jar;mailapi__V1.3.2.jar;axis-ant.jar;axis-schema.jar;axis.jar;commons-discovery-0.2.jar;commons-logging-1.0.4.jar;jaxrpc.jar;log4j- 1.2.8.jar;saaj.jar;tews-employee.jar;wsdl4j-1.5.1.jar %1

You can run your client program as:

wsclient.bat yourJavaClassName

CLIENT-CONFIG.WSDD

The presence of the client-config.wsdd changes the output behavior of the client program. If you remove this file from the directory where you launch the client program, it will not generate the xml input and output messages.

Third-Party Web Application Integration

Since a JSP (Java Server Page) page can easily invoke Java libraries, we suggest that a third-party Web application use this technology to call the TEWS client library to communicate with the CA Identity Manager server.

Building and Deploying Your TEWS Client Library

Using a JSP for the third party Web application integration is very similar to a standalone TEWS client program. You must still build and deploy the TEWS client library. When you modify or add the Admin Tasks, you still must consider whether you need to rebuild and redeploy it.

EXAMPLE: USING CA IDENTITY MANAGER AS A THIRD-PARTY WEB APPLICATION

Since CA Identity Manager is housed on an application server, the same server can be used for the purpose of housing Third-party Web Applications that use the JSP pages. We suggest that you create a subdirectory named custom under the IdentityMinder.ear/user_console_war/app and then deploy the custom jsp pages there. With this approach, the TEWS client library files mentioned previously need to be deployed under the subdirectory IdentityMinder.ear/user_console_war/WEB-INF/lib. You do need to recycle the application server for this to take effect.

Creating JSP Pages

The self help certification privacy.jsp mentioned in Chapter 8 is a TEWS JSP page. It uses the user csr and password test, and communicates with the TEWS client library that is available for it to certify a customer.


Generic TEWS Command Line Interface

When external applications send requests and receive responses from the CA Identity Manager Web Services interface, the requests and responses consist of Simple Object Access Protocol (SOAP) XML messages.

In this section, we present you examples that use SOAP documents and simple command tools to demonstrate how to use TEWS to interact with your CA Identity Manager servers. The use of command line tools and SOAP documents allows you to construct your own facilities for automation purposes without having to involve a more formal programming effort through any particular Web Services programming language (such as Java or .NET).

For more information on XML and SOAP, see the World Wide Web Consortium website at http://www.w3.org http://www.w3.org.

SOAP XML Document

A TEWS client program sends a SOAP request over HTTP to the CA Identity Manager server. The CA Identity Manager application server reads the request, executes the specified task, and returns a SOAP response. Some requests begin a transaction (such as creating a user) and the response contains a status code with the transaction ID. Other requests return the results of some query, such as a View User Search request returning a list of users.

TEWS SOAP messages consist of SOAP and TEWS XML elements. The SOAP elements consist of an envelope root element and a body child element. The body element holds the TEWS elements making up the request and response.

As an example, the following is a SOAP request that can be used to create an organization for the out-of-the-box NeteAuto example IME:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<TaskContext xmlns="http://tews6/wsdl">

<admin_id>uid=SuperAdmin,ou=People,ou=Employee,ou=NeteAuto,dc=security,dc=com</admin

_id>

</TaskContext>

<CreateOrganization xmlns="http://tews6/wsdl">

<CreateOrganizationSearch>

<CreateNew>true</CreateNew>

<Organization/>

</CreateOrganizationSearch>

<CreateOrganizationProfileTab>

<_PCT_ORG_MEMBERSHIP_PCT_>ou=Employee,ou=NeteAuto,dc=security,dc=com

</_PCT_ORG_MEMBERSHIP_PCT_>

<_PCT_ORG_NAME_PCT_>Information Security</_PCT_ORG_NAME_PCT_>

<_PCT_ORG_DESCR_PCT_>Information Security</_PCT_ORG_DESCR_PCT_>

</CreateOrganizationProfileTab>

http://www.w3.org/


</CreateOrganization>

</soapenv:Body>

</soapenv:Envelope>

The following is another doc that creates an organization for the vendor IME:

<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'

xmlns:xsd='http://www.w3.org/2001/XMLSchema'

xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>

<soapenv:Body>

<TaskContext xmlns='http://tews6/wsdl'>


_id>

</TaskContext>

<CreateVendorOrganization xmlns='http://tews6/wsdl'>

<CreateVendorOrganizationSearch>

<CreateNew>true</CreateNew>

<Organization/>

</CreateVendorOrganizationSearch>

<CreateVendorOrganizationProfileTab>

<_PCT_ORG_MEMBERSHIP_PCT_>ou=Supplier,ou=NeteAuto,dc=security,dc=com

</_PCT_ORG_MEMBERSHIP_PCT_>

<_PCT_ORG_NAME_PCT_>Ford</_PCT_ORG_NAME_PCT_>

<_PCT_ORG_DESCR_PCT_>Ford Company</_PCT_ORG_DESCR_PCT_>

</CreateVendorOrganizationProfileTab>

</CreateVendorOrganization>

</soapenv:Body>

</soapenv:Envelope>

With a good template, the primary work involved to create a SOAP document is to figure out all the elements that constitute a good TEWS document. Fortunately, you only need to do this once with each Admin Task you are attempting and many of them are actually similar.

To help lessen the difficulty, we suggest that you use Eclipse and the Eclipse Web Services Explorer to help determine these elements.

GNU wget

wget is one of the GNU utilities you can download from the following URL:

http://gnuwin32.sourceforge.net/

wget is a generic tool used to retrieve files from HTTP and FTP servers. We use it to submit our Web Services requests to the CA Identity Manager server. On a production server, enable Web Services security to protect the TEWS interface. Submit a prepared SOAP XML file to a security-enabled production server as follows:

wget --output-document=- --header "Cookie: SMCHALLENGE=YES" --http-user=superadmin --http-passwd=test --post-file=request.xml http://<your server name>/idm/TEWS6/neteauto


On a test system without Web Services security, the command can be simplified as:

wget --output-document=- --post-file=request.xml http://<your server name>/idm/TEWS6/neteauto

wget Automation Utilities

To ease the usage of wget, a number of utilities have been provided on the accompanying zip file.

First the zip file has the following structure to help support the three IMEs:

customer

setenv.bat

wsbatch

employee

setenv.bat

wsbatch

vendor

setenv.bat

wsbatch

Prerequisites

We use the GNU utilities wget and gawk, downloadable from the following URL:

http://gnuwin32.sourceforge.net

The three setenv.bat files actually have the set content. They contain the following line:

set PATH=C:\Program Files\GnuWin32\bin;%PATH%

You must set the program path to ensure gawk and wget are accessible.

wsbatch Subdirectory

Under wsbatch, there are the following files

setenv.bat

wsbatch.bat

wscmd.bat

wssearch.bat

wssearch.xsl

xslt.vbs

The challenge with using a tool like wget is the generation of the SOAP requests and the parsing of the SOAP responses. We use GNU awk to generate the SOAP requests and MSXML to transform the search responses to delimited text.


SETENV.BAT

This batch file contains site-specific environment variables. Modify it as necessary.

@echo off

set IME_HOST=gbcustomer.security.com

set IME_PORT=8080

set IME_NAME=customer

set IME_USERNAME=SuperAdmin

set IME_PASSWORD=test

set IME_URL=http://%IME_HOST%:%IME_PORT%/idm/TEWS6/%IME_NAME%

You do need to modify this file to use a different IME_USERNAME depending on the Admin Task you are using.

WSCMD.BAT

This batch file takes two parameters. The first parameter is the SOAP XML file to be sent to the TEWS interface. The second parameter is the standard output file name. You can direct the output to the console using a single dash (-) in its place.

wscmd.bat detects whether the required environment variable has been set. If not, it first calls the setenv.bat at its parent directory which happens to be where we set the program path for the wget program, and then the setenv.bat at the same directory where we set the site-specific environment variables.

wscmd.bat can be run under any subdirectory so long as you can get to it.

WSBATCH.BAT

This batch file is used to drive a batch process when you want to submit multiple TEWS requests. It takes two parameters, the first one is an awk script to be run by gawk to translate and then process the CSV file given by the second parameter. Since the user data store we chose to use was an LDAP one, we use # as the delimiting character in our example files.

wsbatch.bat calls the two environment batch setenv.bat files, runs the gawk script to generate the SOAP requests, and then calls the wscmd.bat to send the SOAP requests to the TEWS interface. It also deletes all existing .xml files in the current directory before it starts. It leaves behind two SOAP files for each record in the CSV file. One of the two files is a SOAP document meant to be sent to the TEWS interface. The other is the response file.

WSSEARCH.BAT, WSSEARCH.XSL, AND XSLT.VBS

These three files are driven by wssearch.bat. wssearch.bat takes two file parameters. The first parameter is an awk script that uses the second file to obtain search filters to create a TEWS SOAP document that consists of a search-type Admin Task.


wssearch.bat uses wscmd.bat to submit a search-type TEWS SOAP request it generates from the awk script to the TEWS interface and saves the response to Search_response.xml. It further uses \cscript to drive an xsl transformation using the xsl style sheet provided in wssearch.xsl. The xsl transformation is designed to transform the Search_response.xml result from the TEWS SOAP request into lines of '#' delimited format.

wget Automation Examples

Our actual examples are organized under each of the IMEs. Since many of them are similar, we only highlight a few of them in this appendix.

Customer IME Certification Processes

The following xml files are stored under customer\cert subdirectory:

begincert.xml

cert.xml

endcert.xml

sendcert.xml

sendfinal.xml

BEGINCERT.XML

The begincert.xml is a SOAP document you can use to schedule a batch job to start the Customer Status Certification Process for the Customer IME discussed in Chapter 8. The following is its content:

<?xml version="1.0" encoding="UTF-8"?>

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelo

pe/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance">

<soapenv:Body>

<TaskContext xmlns="http://tews6/wsdl">

<admin_id>nobody</admin_id>

</TaskContext>

<CustomerBeginCertificationProcess

xmlns="http://tews6/wsdl">

<CustomerBeginCertificationProcessSearch>

<Filter index="0">

<Field>%USER_ID%</Field>

<Op>EQUALS</Op>

<Value>a*</Value>


</Filter>

</CustomerBeginCertificationProcessSearch>

<CustomerBeginCertificationProcessBeginCertificationP

rocessTab/>

</CustomerBeginCertificationProcess>

</soapenv:Body>

</soapenv:Envelope>

It starts the Customer Status Certification Process for all customers with the 'a' as the first character of the user ID. You can run it using:

..\wscmd.bat begincert.xml -

Before you do it, make sure you have the user set to ccm in the setenv.bat file.

ENDCERT.XML AND OTHERS

endcert.xml, sendcert.xml, and sendfinal.xml handle the other three tasks of a certification process. They all need to use ccm as the IME_USERNAME.

CERT.XML

cert.xml certify users. It needs to use csr as the IME_USERNAME.

Employee IME Create Employee

The following files are included in the employee\wsbatch\User subdirectory:

1vrr4.xml

2vrr2.xml

cremp.awk

crempmgr.awk

emp.csv

empmgr.csv

The two xml files are sample outputs from wsbatch.bat that can be used with the wscmd demonstrated in the Customer IME Certification Process section. The cremp.awk and crempmgr.awk are two different versions of Create Employee awk script. The two csv files are example files for the two awk scripts.

To run these, we suggest that you change your current directory to employee\wsbatch\tmp. Make sure the setenv.bat files are configured correctly. You can use hr as the IM_USERNAME and then issue the following command from there:

..\wsbatch.bat ..\User\crempmgr.awk ..\User\empmgr.csv


It first deletes all the .xml under the current directory. It then uses the awk script to convert the csv file into multiple xml files, one for each record in the csv file. Finally, it calls wscmd.bat to process each XML file it generates, and writes the SOAP response to another XML file.

CREMPMGR.AWK

Here is the awk script for the crempmgr.awk. The FS=”#” is how the delimiter is set for the CSV file. The mgr=7, org=6 and so on are how you set up the fields for each record. One other thing to point out is that <_BAR_Manager_SPACE_Long_SPACE_Name_BAR_> is the tag name used for the logical attribute mentioned in Appendix E.

BEGIN { FS="#" ; mgr = 7; org = 6; pwd = 5; full = 4; first = 3; last = 2;

uid = 1;

c = 0;

}

{

c = c + 1;

fname = c $uid ".xml";

print fname;

printf "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'"

> fname ;

printf " xmlns:xsd='http://www.w3.org/2001/XMLSchema'" > fname ;

printf " xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>" > fname ;

print " <soapenv:Body>" > fname ;

print " <TaskContext xmlns='http://tews6/wsdl'>" > fname ;

print "


_id>" > fname ;

print " </TaskContext>" > fname ;

print " <CreateEmployee xmlns='http://tews6/wsdl'>" > fname ;

print " <CreateEmployeeSearch>" > fname ;

print " <CreateNew>true</CreateNew>" > fname ;

print " <Organization/>" > fname ;

print " </CreateEmployeeSearch>" > fname ;

print " <CreateEmployeeProfileTab>" > fname ;

printf " <_PCT_ORG_MEMBERSHIP_PCT_>%s</_PCT_ORG_MEMBERSHIP_PCT_>\n", $org >

fname ;

printf " <_PCT_USER_ID_PCT_>%s</_PCT_USER_ID_PCT_>\n", $uid > fname ;

printf " <_PCT_PASSWORD_PCT_>%s</_PCT_PASSWORD_PCT_>\n", $pwd > fname ;

printf " <_BAR_passwordConfirm_BAR_>%s</_BAR_passwordConfirm_BAR_>\n", $pwd

> fname ;

printf " <_PCT_FIRST_NAME_PCT_>%s</_PCT_FIRST_NAME_PCT_>\n", $first > fname

;

printf " <_PCT_LAST_NAME_PCT_>%s</_PCT_LAST_NAME_PCT_>\n", $last > fname ;

printf " <_PCT_FULL_NAME_PCT_>%s</_PCT_FULL_NAME_PCT_>\n", $full > fname ;

printf "

<_BAR_Manager_SPACE_Long_SPACE_Name_BAR_>%s</_BAR_Manager_SPACE_Long_SPACE_Name_BAR_

>\n", $mgr >fname ;

print " </CreateEmployeeProfileTab>" > fname ;


print " </CreateEmployee>" > fname ;

print " </soapenv:Body>" > fname ;

print "</soapenv:Envelope>" > fname ;

}

Other Examples

The following is a list of other examples included in the zip file:

■ customer\wsbatch\Group

Contains an awk script and a csv file to create groups for the Customer IME.

■ employee\wsbatch\Group

Contains an awk script and a csv file to create groups for the Employee IME.

■ employee\wsbatch\Org

Contains an awk script and a csv file to create the organization for the Employee IME.

■ vendor\wsbatch\Org

Contains an awk script and a csv file to create the organization for the Vendor IME.

Employee IME Search Users

In this example, we send a search request to CA Identity Manager, retrieve the search results, and then apply an XSL transformation to create a delimited export file. We suggest that you run this from the employee\wsbatch\tmp subdirectory to use the awk script and filter files stored under employee\wsbatch\Search as following:

..\wssearch.bat ..\Search\User.awk ..\Search\UserFilters.txt

You also need to set the IME_USERNAME in the setenv.bat to SuperAdmin for this to work. When this works, you will see three files under the tmp subdirectory:

Search_request.xml

Search_response.xml

Search_response.txt

This example shows that you can take the result and apply other logic to process the objects returned from the search.

USER.AWK

Here is the awk script that takes a filter setting file to generate the SOAP request:

BEGIN {


FS = "#";

ADMIN_ID = "uid=SuperAdmin,ou=People,ou=Employee,ou=NeteAuto,dc=security,dc=com";

TEWS_XMLNS = "http://tews6/wsdl";

FILTER_INDEX = 0;

FILTER_FIELD = 1;

FILTER_OP = 2;

FILTER_VALUE = 3;

FILTER_CONJ = 4;

print "<soapenv:Envelope";

print " xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'";

print " xmlns:xsd='http://www.w3.org/2001/XMLSchema'";

print " xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>";

print " <soapenv:Body>";

print " <TaskContext xmlns='" TEWS_XMLNS "'>";

print " <admin_id>" ADMIN_ID "</admin_id>";

print " </TaskContext>";

print " <ViewUserSearch xmlns='" TEWS_XMLNS "'>";

}

{

if ( 3 <= NF ) {

printf " <Filter index='%i'>\n", FILTER_INDEX;

printf " <Field>%s</Field>\n", $FILTER_FIELD;

printf " <Op>%s</Op>\n", $FILTER_OP;

printf " <Value>%s</Value>\n", $FILTER_VALUE;

if ( 4 <= NF )

printf " <Conj>%s</Conj>\n", $FILTER_CONJ;

print " </Filter>";

FILTER_INDEX++;

}

}

END {

print " </ViewUserSearch>";

print " </soapenv:Body>";

print "</soapenv:Envelope>";

}

USERFILTERS.TXT

This filter says that we are searching for users between 'A' and 'H':

%USER_ID%#GREATER_THAN_EQUALS#A

%USER_ID%#LESS_THAN#H#And

XSLT.VBS

This VBScript utility applies an XSL transformation to an XML file:

' Verify the XML and XSL filename arguments were passed...

If 2 > WScript.Arguments.Unnamed.Length Then

WScript.StdErr.WriteLine "xslt.vbs <xml-file> <xsl-file>"

WScript.Quit 0

End If


' Load the XML and XSL files into a DOM...

Dim xmlFile, xslFile

Set xmlFile = LoadDOMDocument(WScript.Arguments.Unnamed.Item(0))

Set xslFile = LoadDOMDocument(WScript.Arguments.Unnamed.Item(1))

' Transform the XML file using the XSL file...

Dim output

output = xmlFile.transformNode(xslFile)

' NOTE: VBScript does not handle writing ASCII characters 0x80-0xff as a string to

StdOut when it is redirected.

' The trick is to extract out each character, get the ASCII code of the

character,

' and then convert the code back into a character...

Dim start

For start = 1 To Len(output)

WScript.StdOut.Write Chr(Asc(Mid(output, start, 1)))

Next

' Instantiate an MSXML DOMDocument object and load the specified file.

' If the load fails, then write an error message and exit with the error code...

Function LoadDOMDocument(fileToLoad)

On Error Resume Next

Set LoadDOMDocument = CreateObject("Msxml2.DOMDocument.4.0") ' Try MSXML 4.0...

If LoadDOMDocument Is Nothing Then _

Set LoadDOMDocument = CreateObject("Msxml2.DOMDocument.3.0") ' Try MSXML 3.0 if

4.0 failed...

If LoadDOMDocument Is Nothing Then

WScript.StdErr.WriteLine "Unable to instantiate MSXML 4.0 or 3.0 : " &

Err.Description

WScript.Quit Err.Number

End If

LoadDOMDocument.async = False

If Not LoadDOMDocument.load(fileToLoad) Then

WScript.StdErr.Write "Unable to load " & LoadDOMDocument.parseError.url & " : "

& _

LoadDOMDocument.parseError.reason

WScript.Quit LoadDOMDocument.parseError.errorCode

End If

End Function

WSSEARCH.XSL

This XSL file transforms the XML response into delimited text records. The response contains ResultItem elements for each user. The transformation extracts the ATTR_VALUE element for each user attribute and the OID:

<?xml version="1.0"?>

<xsl:stylesheet

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:tews="http://tews6/wsdl"

version="1.0">


<xsl:output method="text" encoding="UTF-8" />

<xsl:preserve-space elements="tews:*" />

<xsl:variable name="delim"><xsl:text>#</xsl:text></xsl:variable>

<xsl:variable name="eol"><xsl:text>
</xsl:text></xsl:variable>

<xsl:template match="/">

<xsl:apply-templates select="//tews:ResultItem" />

</xsl:template>

<xsl:template match="tews:ResultItem">

<xsl:apply-templates select="tews:*[not(name()='OID')]" />

<xsl:apply-templates select="tews:OID" />

<xsl:value-of select="$eol" />

</xsl:template>

<xsl:template match="tews:ResultItem/*[not(name(.)='OID')]">

<xsl:apply-templates select="tews:ATTR_VALUE" />

<xsl:value-of select="$delim" />

</xsl:template>

</xsl:stylesheet>

}

Eclipse and Eclipse Web Services Explorer

We recommend that those interested in exploring the possibilities of using the CA Identity Manager TEWS interface consider using Eclipse available from http://www.eclipse.org/ http://www.eclipse.org/ to develop your TEWS client program. Instead of downloading the standard Eclipse package, we suggest that you download the wtp-all-in-one package that is available at the Eclipse Web Tools Platform (WTP) Project Home Page:



We used Release 1.5.3. This all-in-one package also gives you the standard Eclipse SDK development environment.

Eclipse SDK requires the users to install the JRE of their choice. We used JRE version 1.4.2_13. We recommend that you use the supported versions of the JRE that can be found on the CA Identity Manager support matrix that is available on the http://support.netegrity.com http://support.netegrity.com web site.

http://www.eclipse.org/


http://support.netegrity.com/


Once you have your Eclipse SDK installed and Web Services Explorer enabled, you can start Eclipse. Start the Web Services Explorer through the Run\Launch the Web Services Explorer menu item:

Enter the WSDL URL and click on the Go button.


The URL is in the format of http://MachineName/idm/TEWS6/envName?wsdl http://machinename/idm/tews6/envname?wsdl. Then click the Tews6SoapBinding link to open all available TEWS facilities.

http://machinename/idm/tews6/envname?wsdl


Appendix J: Connector Xpress CA Identity Manager has the capability of provisioning accounts into namespaces it does not support out of the box. The provisioning feature is provided via the connectors of IM's eTrust Admin provisioning engine. A connector is the middleman that conducts communication between the provisioning engine and the managed endpoints. CA Identity Manager provides a several connectors that support most of the commonly seen namespaces, such as Microsoft Active Directory connector, AS400 connector, Oracle connector and LDAP connector.

To support the namespaces not supported out of the box, the traditional approach relies on developing custom connectors using the C++ based eTrust Admin SDK. This C++ based SDK provides tools to help minimize the time it takes to develop ODBC based customer connectors. However, such an effort is still considered expensive and sometimes unreliable.

The Connector Xpress toolkit minimizes the need to create a custom connector. As of the release of the eTrust Admin 8.1/SP2 CR5, this tool is capable of relieving you from having to create custom C++ codes to address many ODBC based namespaces.

In this appendix, we provide a quick example of how to use the Connector Xpress to create the KMS example.

We provide the procedure to create it, an example of what it looks like in the eTrust Admin Win32 Manager, the procedure to remove it, and and the procedure to re-create it from a saved XML file.

Sample KMS Files

The KMS subdirectory on the zip file contains the Microsoft SQL scripts you can use to create a sample KMS database. Please see Appendix B for the overall structure of all the sample files that accompany this book.

Use Connector Xpress

Connector Xpress is available for download from the CA support Web Site at http://supportconnect.ca.com http://supportconnect.ca.com. As of this writing, the most recent build is the caim-connector-xpress-windows-CR5-070111.zip. Simply download it, unzip it, and install it using the setup.exe on your development eTrust Admin Server.

To start it, you run the following command from the bin subdirectory:

ConnectorXPress.bat

The online documentation can be found from the Help menu item on this program.

http://supportconnect.ca.com/


Create Connector Xpress Custom Connector

The following steps show how to create the KMS example:

1. To begin creating a custom database connector, click Connector, DB Connector Xpress from the CA Identity Manager Connector Xpress menu and follow the instructions in the wizard.

2. Click on the Connector menu to launch the wizard.

3. Edit the General screen to supply

> Namespace Name: the namespace that will be managed in eTrust Admin. (Note: Additional directories can be added using the Admin GUI after completing the wizard.)

> Version: The version of the XML being used to generate the connector information.

> Description: Optional, a description of the namespace.

> And then click on Next to continue.

4. Edit the DB Connection Details Screen to supply:

> Endpoint Name: Managed Endpoint name to appear on eTrust Admin.

> DSN: the ODBC Data Source Name on the machine where the Superagent resides to connect to the database. If Test is selected, a local ODBC Data Source of this name is used to test a connection to the database.

> Database Vendor: Specifies either MS SQL or an Oracle database.

> Host: the hostname where the target database resides.

> Port: the port number the database listens on.

> Database: the database name (MS SQL) or its SID (Oracle).

> Username: the username that is being used to logon to the target database.


> Password: the password that is being used to logon to the target database.

> URL: the JDBC URL to be used. The URL will be automatically determined as the previous fields are filled in. The field can be edited manually, however, this is only recommended for advanced users.

5. Click Next to continue.

Note: If there are any errors, for example, an invalid database name, you will not leave this screen. You must correct the information before you can move on to the next step.

6. Edit the Map Account Table Screen to supply

> Schema: the schema or table space name.

> Select Account Table: the table that stores account information in the selected schema.

> Admin Attribute: for each column of the selected table, select the target LDAP attribute from the Admin Attribute Column that you want to associate.

> Display Name: optionally, a display name for each column.

Note: Specifying a display name will override the default display names for standard fields that have them. For generic attributes, there is no display name, so you must supply one. For columns you do not want to map, do not select an attribute.



8. Review and Confirm the Map Account Confirm Screen.

Datatype: additional database and schema information to override Connector Xpress' default datatype selection to provide further validation of data. For example, if one of the database's VARCHAR columns is being used to store integers, select INTEGER in this field to have eTrust Admin validate this information proper to inserting the information into the database.

> Default Value: the default value is used when an object (account or group) is created.


10. Optionally, edit the Map Group Table Screen if you have a Group Table in your database. KMS does not have one. The following is informational only. The information here is very similar to the Account Table Screen earlier:

> Schema: the schema or table space name.

> Select Group Table: the table that stores group information in the selected schema.

> Admin Attribute: for each column of the selected table, select the target LDAP attribute from the Admin Attribute Column that you want to associate.

> Display Name: optionally, a display name for each column.

Note: Specifying a display name will override the default display names for standard fields that have them. For generic group attributes, there is no display name, so you must supply one. For columns you do not want to map, do not specify an attribute name.


Since we do not have the group table, we check the “Skip mapping Group table” and click Next to continue.

11. Review and Confirm the Map Group Confirm Screen optionally if you have a Group Table in your database. KMS does not have one. The following is informational only

To edit this screen, review and correct, if necessary, the group mapping types that have been created, optionally, these fields can be completed.

> Datatype: Specifies any additional database and schema information to override Connector Xpress' default datatype selection to provide further validation of data. For example, of one of the database's VARCHAR columns is being used to store integers, select INTEGER in this field to have eTrust Admin validate this information proper to inserting the information into the database.

> Default Value: Specifies that any attribute can be assigned a default value. This default value is used when an object (account or group) is created.


13. Edit the Map Membership Table Screen. KMS does not have one. The following is informational only. This is only possible when there are both an account table and a group table. This is to define the table that contains the account to group relationship.

> Schema: Specifies the schema or table space name.

> Membership Table: Specifies the tables that define the members of each group.

> Admin Attributes: Specifies the associations of the accounts and groups in a separate lookup table that contains the mappings.

14. Click Next.

15. View the Generate Metadata Screen

After completing the account and group mapping steps, review the generated metadata in the XML viewer on the Mapping tab.

16. Click Next.

17. Edit the Register Connection Screen - Deploy connector to Admin, to supply:

> Admin Host: the Admin host machine name

> User Domain: user domain name to be used to logon to eTrust Admin

> Admin Username: the username to be used to logon to eTrust Admin

> Password: the password to be used to logon to eTrust Admin


> Clear Port Number: the clear text port to connect to the eTrust Admin, default 20389

> SSL Port Number: the SSL port to connect to the eTrust Admin, default 20390

> Use SSL: when selected, an SSL connection to eTrust Admin is used, otherwise, a clear text connection to eTrust Admin is used

> Update entries if they already exist: any directory or namespace that already exist are updated when this option is checked

> Explore Endpoint 'kmstest': Sub Tree: all the containers in the sub-tree are included in the directory exploration when this option is checked

> Explore Endpoint 'kmstest': One Level: only the containers are included in the directory exploration when this option is checked.

> Correlate Accounts with Global Users: Use existing Global Users: configured correlation matching algorithm to match each account with a previously created global user is used when this option is checked.

> Correlate Accounts with Global Users: Create Global Users as needed: if the correlation fails, a global user is created for the account.

After entering the connection details, credentials, and explore and correlate information and clicking Next, this window shows the status of namespace, directory, containers, and policy creation, as well as the status of the directory exploration.

SAVE YOUR WORK

It is highly recommended that you select the “Save connector to file” to save the setting you have gone through using the Wizard into a XML file. This file is later used to show how it can be re-created without having to go through the same steps again.

eTrust Admin Win32 Manager Screens

Once KMS is deployed to an eTrust Admin Server, you can see on the following screen what each of the namespace component looks like on the eTrust Admin Win32 Manager.


ACQUIRE A NEW DIRECTORY

A custom connector created using the Connector Xpress is always called an eTDYNDirectory on this screen. It does, however, have a type associated with it. In this case it is the KMS (DYN Directory):

To acquire a new endpoint with the same database type using this method, provide the endpoint name, DSN name that is on the eTrust Admin Server, System Logon id and password. You also need to leave the DBMS Host and Port in the General tab blank as the following, otherwise it will not work.

EXPLORE AND CORRELATE

Explore and Correlate screen looks exactly the same as a standard eTrust Admin namespace.


ACCOUNT PROVISIONING POLICY

The account provisioning policy screen looks like:

Note: Even though it is an “eTDYNPolicy”, it does have a type associated with it. In this case, it is KMS(DYN Policy).

ACCOUNT PROPERTY

By design, the account property page is very similar to the policy page:


Remove Connector Xpress Custom Connector

You can remove a Connector Xpress created connector using the Identity Manager Connector Xpress Wizard when you no longer need to manage the connector in eTrust Admin. Associated policies and directories are also removed. The actual account and group objects in the relation database are not touched during this process.

The steps are:

1. To delete a custom database connector, click Action, Undeploy Connector from the CA Identity Manager Connector Xpress menu and follow the instructions in the wizard.

Edit the Logon to Admin Screen to supply

> Admin Host: the eTrust Admin machine name

> User Domain: eTrust Admin Domain name

> Admin Username/Admin Password: the ID and password

> Admin Clear/SSL Port Number: 20389/20390

The screen looks like:

2. Select the available ones you want to remove as the following screen:

Deploy Using XML File

If you have saved the XML file during the creation of the Connector Xpress Custom Connector on a development machine you can use the Deploy procedure to deploy it on a production server.


The steps are:

1. To deploy a Connector Xpress Custom Connector using an XML file, click on the Action and select Deploy Connector

2. Supply the XML file name at the Load Configuration step like:


4. Review and modify the database Connection Configuration


6. Review the Metadata extracted from the XML file and continue.

7. Supply the eTrust Admin Server information similar to the screen seen in the creation procedure given earlier to deploy it to an eTrust Admin server.


Appendix K: CA Identity Manager Architecture and High Availability The normal use of an identity management system implemented through CA Identity Manager starts with a Web browser to reach the CA IDM Application Server. The identity of the user is established through CA SiteMinder intercepting the request and extracting identity information from its Policy Server. CA SiteMinder Policy Server uses the authentication policies stored in the policy data store and works with the CA SiteMinder Web Agents to authenticate users. The identity of an authenticated user is established. CA SiteMinder also performs basic authorization before the Web browser is redirected to the IDM Application Server.

Based on the identity and the set of Admin roles of which the user is a member, the CA IDM Application Server delivers a personalized screen to the user's Web browser. The evaluation of the policies is done by the CA SiteMinder Policy Server through a special CA Identity Manager extension. On the back end, the CA IDM Application Server uses various databases to house its data and state information. The Task Persistence database helps monitor the status and state of tasks. The Audit database houses the various audit records for Identity Management operations. The Workflow database keeps track of events that require approvals.

When any of the provisioning management aspects of the identity management system is involved, the CA IDM Application Server uses the JIAM interface to communicate with the Admin Provisioning Server. JIAM is a programming layer which exposes many operations that take place in the provisioning server. The Provisioning Server uses a database of its own called the Administrative Directory to help determine the logistics for the various account provisioning activities. For the actual account provisioning activities, the provisioning server communicates with the three mainframe security systems, CA-ACF2, CA-Top Secret, and IBM RACF, directly, while other connectors such as Unix, Active Directory and Oracle use Distributed Connector Servers.

It is worthwhile to point out that the weakest link in terms of the high availability of a CA Identity Manager implementation tends to be the machines where the computer accounts exist as these systems may not have any high availability capability.


The diagram that follows shows high availability possibilities:

As a quick summary, the following lists show how high availability can be achieved and where you can find more information

■ Web Browser to Web Server: this tends to be offered through a hardware load balancer.

■ Web Server to SiteMinder Policy Server: This is implemented using standard SiteMinder and Web HA capabilities, which include health monitors and a list of additional Policy Servers.

■ Web Server to CA IDM Application Server: this depends on the Application Server of your choice. See the chapter, “Migration Identity Manager from Development to Production” of the CA Identity Manager Installation Guide. CA Identity Manager supports certain versions of the JBoss, WebLogic, and WebSphere.

■ CA IDM Application Server to SiteMinder Policy Server: This is implemented using standard SiteMinder client intelligence, similar to the webagent constructs described above.

■ SiteMinder Policy Server to User Data Store, Policy Data Store: these depend on the Application Server and the data store used. This is generally well known as the data


stores tend to have standard HA techniques, whether via clustering, replication or software routers.

■ SiteMinder Policy Server to Admin Provisioning Server as an LDAP User Data Store: this is usually done using the CA Directory (also known as eTrust Directory) dxlink router feature.

■ CA IDM Application Server to Admin Provisioning Server through JIAM interface: this is usually done using the CA Directory dxlink router feature

■ CA IDM Application Server to its databases: this depends on the types of the Application Server and the databases. This is generally well known as the data stores tend to have standard HA techniques, whether through clustering, replication or software routers.

■ Admin Provisioning Server to Administrative Directory: this is usually done using the CA Directory router feature.

■ Admin Provisioning Server to Distributed Connector Server: this is usually done using the CA Directory dxlink router feature.

■ Admin Provisioning Server callback to the CA IDM Application Server: the callback can actually be achieved through the Web server and use the same hardware load balancer.


Appendix L: Patches and Upgrades

Identity Management Infrastructure

CA Identity Manager is a solution that was built by integrating the best of three products, CA IdentityMinder Web Edition, eTrust Admin and CA eTrust SiteMinder. Currently implementation teams must manage the patch and upgrade process to ensure that each component is upgraded in the appropriate sequence as described in the given patch. Every attempt is made to make this easier by avoiding mandatory updates of both components at the same time. In the eTrust Admin infrastructure the underlying CA Directory must be managed during the upgrade process just as CA SiteMinder upgrades may impact CA Identity Manager.

Provisioning Infrastructure

The provisioning infrastructure actually consists of three products, eTrust Admin, eTrust Directory, and the Ingres Corporation's Open Source Ingres.

Ingres is used as a binary store for eTrust Directory. We usually do not need to worry about patching or upgrading this component independently. The patch/upgrade of eTrust Admin and/or eTrust Directory includes the necessary Ingres components as appropriate.

Like Ingres, eTrust Directory is used as a component to support eTrust Admin. For the most part, the patching/upgrading of eTrust Admin addresses the need to upgrade/patch eTrust Directory as well. This means that you do not need to patch or upgrade eTrust Directory independently. If there is ever a need, it will most likely be requested by eTrust Admin support. However, you may still want to look at the following URL to get familiar with the eTrust Directory site as the eTrust Admin patches do not always carry the version/build of the eTrust Directory you need:

http://supportconnect.ca.com/public/etrust/etrust_dir/etrustdir_supp.asp http://supportconnectw.ca.com/public/etrust/etrust_dir/etrustdir_supp.asp

eTrust Directory carries the same “Cumulative Release” approach as CA Identity Manager. Instead of calling it “Cumulative Release”, it is referred as “Current Release” on the eTrust Directory support site. The “build number” is also often used when referring to a “Current Release” of eTrust Directory.

Like CA Identity Manager, eTrust Admin adapts a “Cumulative Release” approach. For example, as of this writing, the latest release is eTrust Admin r8.1 SP2 CR5. eTrust Admin Support provides a monthly release for new CRs. eTrust Admin Support tends to stop releasing new CRs for older Service Pack levels of the product. For example, no CRs for the

http://supportconnectw.ca.com/public/etrust/etrust_dir/etrustdir_supp.asp


eTrust Admin r8.1 SP1 or older are planned. The eTrust Admin Support site is at the following URL:

http://supportconnect.ca.com/public/etrust/etrustadmin-dmo/etrustadmin-dmo_supp.asp http://supportconnectw.ca.com/public/etrust/etrustadmin-dmo/etrustadmin-dmo_supp.asp

General Recommendations

A CR (Cumulative release) is created by taking fixes since the last release or CR and performing integration and regression testing. Having CA QA validate the CR means that customers are protected from side effects of 2 or 3 fixes interfering with each other.

CA Quality Assurance testing is thorough, yet it is still a good idea for IT departments or implementation teams to plan for and execute their own regression tests to ensure that any change applied to production goes through proper change control methodology.

Certainly, if there is a CR that directly addresses the issue you are experiencing, you may want to consider doing it earlier than normally scheduled for your installation. When you add the CR to the environment is up to you. However, it is recommended that all CRs be reviewed and considered for deployment to keep the product(s) at the most current supported level.

http://supportconnectw.ca.com/public/etrust/etrustadmin-dmo/etrustadmin-dmo_supp.asp


Index

A

ACCESSING SELF-SERVICE TASKS • 91 ACCOUNT PROPERTY • 268 Account Provisioning • 160 ACCOUNT PROVISIONING POLICY • 268 Account Self-Service • 145 Account Service Self-Help • 145 ACCOUNT SYNCHRONIZATION • 132 Account-Level Self-Service • 15 ACKNOWLEDGEMENTS • iii ACQUIRE A NEW DIRECTORY • 267 Acquire Managed Endpoints • 113 Admin Role • 42 ADMIN ROLE, ACCESS ROLE,

PROVISIONING ROLE, AND OTHERS • 36

Admin Roles and Access Roles Delegations • 161

Admin Task • 39 ADMIN TASK DEPENDENCY • 244 ADMIN TASK PROFILE TAB • 40 ADMIN TASK SCOPE TAB • 41 Admin Task Screen and Logical Attribute

Handler • 209 ADMIN TASK TAB • 41 ADMIN TASK USES EXTERNAL TAB • 95 ADMIN TASKS AND EVENTS • 235 Admin Task's User Synchronize Option •

182 ADMINISTRATIVE DIRECTORY

MAINTENANCE • 143 Administrator Rules • 60, 61, 62, 63, 64,

65, 90, 139 ADMINISTRATOR RULES • 139 Advertise Your Services • 71 Apache Tools • 185 Application Server Email Services • 229 Applications • 213 APPLY ONCE • 155 Approved or Rejected • 239 Attribute Data Flow • 210 Authentication Directories • 23 Authority • 43 AUTHORIZATIONS BY OPERATOR NATIVE

PRIVILEGES • 115 AUTHORIZATIONS BY PROXY IDS • 115 AUTHORIZATIONS BY THE MANAGING

MACHINES • 115 Avoid AutoComplete • 77

B

Back Up the neteauto User Data Store • 197

Backend Authorities • 47 Backend Authority Services • 45 BASE CA IDENTITY MANAGER SERVER •

191, 193, 195 BEGINCERT.XML • 251 BUILD • 211 Build and Deploy • 211 BUILD YOUR TEWS CLIENT LIBRARY •

195 Building and Deploying Your TEWS Client

Library • 246 Building Your TEWS Client Library • 243

C

CA Identity Manager Architecture and High Availability • 271

CA Identity Manager Development Workstation • 191

CA IDENTITY MANAGER SERVER DEPENDENCY • 244

CA IDENTITY MANAGER TO POLICY SERVER AGENT CONNECTIONS • 182

CA SiteMinder Procedures • 215 CAPABILITY ATTRIBUTES • 129 CERT.XML • 252 CERTIFICATION PROCESS MECHANISMS

• 166 CHANGE CORRELATION CRITERIA AND

RE-CORRELATE • 120 CLIENT-CONFIG.WSDD • 246 Code Client Program • 244 Common Customization Scenarios • 67 Compile and Debug Client Program • 245 Compliance and Reporting • 164 Compliance Policies • 165 COMPLIANCE REPORT SCHEDULE • 183 Compliance Reports • 167 CONCURRENT CERTIFICATION

PROCESSES • 167 Configuration • 99 CONFIGURE THE WORKPOINT

WORKFLOW • 192 Configuring Your IMEs • 242 Connector Xpress • 261 CONNECTOR XPRESS • 140 CONTAINERS • 22 CONTROL THE SELF-REGISTRATION

PROCESS • 91

278 Index

Corporate Directory and Provisioning Directory • 121

Correlation • 116 Correlation Customization • 119 Correlation Rules • 118 Create Connector Xpress Custom

Connector • 262 Create Portable RoleDefinitions XML File •

204 CREATE THE ETRUST ADMIN USER DATA

STORE • 122 Create the neteauto DSA Using eTrust

Directory • 197 Creating an Identity Manager

Environment • 26 Creating JSP Pages • 246 CREATING YOUR OWN WORKFLOW

APPROVAL TASK • 239 CREMPMGR.AWK • 253 Custom loginGB.fcc for Public Directory •

220 Customer Certification and Identity

Policies Roles • 172 Customer Certification and Identity

Policies Services • 170 Customer Delegated Identity

Management Roles • 51 Customer Delegated Identity

Management Services • 49 Customer Directories • 70 Customer Identity Self Services

(Services) • 78 Customer Identity Self-Services (Roles) •

85 Customer IME • 29 Customer IME Certification Processes •

251 Customer IME Machine • 193 Customer IME Objects • 200 Customer Web Application Authorization

Roles • 104 Customer Web Application Authorization

Services • 103

D

Data Model Changes • 156 Deciding When to Send Email • 230 Decrement Procedure • 206 DEFAULT CONTAINER • 74 Delegated Account Management • 14,

111 Delegated Account Provisioning • 126 Delegated Account Services • 133 Delegated Administration • 35 Delegated Identity Management • 14, 33 Delegated Identity Management Services

• 45 DELEGATED SYSTEM MANAGER • 46 Delegation • 44

Delegation System Management Services • 46

DEPLOY • 212 DEPLOY THE PRIVACY.JSP AND OTHERS •

195 Deploy Using XML File • 269 Deployment • 227 Deployment and Performance

Consideration • 67, 92, 108, 151 Deployment and Performance

Considerations • 142, 180 diff Utility and Clean Up • 206 Different Self-Authentication

Requirements • 77 directory.xml • 20 Directory.xml • 203 Disclaimer • 189 DISPLAY THE MENU ITEM • 96 DISTRIBUTED CONNECTOR SERVER •

140

E

Eclipse and Eclipse Web Services Explorer • 257

Eclipse Tools • 185 Email • 227 EMAIL ADDRESS • 233 Email content • 227 Email Notification • 227 Email Notification Configuration • 229 Email Templates • 231 Email Templates Elements • 233 Employee Account Self Service (Roles) •

149 Employee Account Self-Service (Services)

• 148 Employee Delegated Account

Management Roles • 137 Employee Delegated Account

Management Services • 135 Employee Delegated Identity

Management Roles • 59 Employee Delegated Identity

Management Services • 58 Employee Directories • 70 Employee Identity Policies Roles • 174 Employee Identity Policies Services • 173 Employee Identity Self-Services (Roles) •

89 Employee Identity Self-Services

(Services) • 87 Employee IME • 28 Employee IME Create Employee • 252 Employee IME Machine • 191 Employee IME Objects • 199 Employee IME Search Users • 254 Employee Web Application Authorization

Roles • 106


Employee Web Application Authorization Services • 105

ENABLE APPROVAL • 147 Enable TEWS • 215 Enable TEWS JSP Support • 194 Enable TEWS Security • 215 Enable WorkPoint Workflow • 235 ENABLEDISABLEUSERS.JAVA • 245 Enabling Email and Setting Template

Directory • 230 END USER LICENSE AGREEMENT • 73 ENDCERT.XML AND OTHERS • 252 Endpoint Management Delegation • 113 Enhance CA SiteMinder with RBAC Rules

• 98 ENTITLEMENT CERTIFICATION • 183 EnvironmentSettings.xml • 204 ESTABLISH THE CUSTOMER IME • 193 ESTABLISH THE EMPLOYEE IME • 192 ESTABLISH THE VENDOR IME • 195 eTrust Admin Server User Data Store and

Provisioning Directory • 23 eTrust Admin Win32 Manager Screens •

266 EXAMPLE

USING CA IDENTITY MANAGER AS A THIRD-PARTY WEB APPLICATION • 246

EXCEPTIONS AND OTHER OBJECTS • 37 EXPLORE AND CORRELATE • 267 Explore Managed Endpoints • 114 Export Role and Task Settings • 206

F

Forgotten ID • 76

G

General Recommendations • 276 Generate a Java Web Services Client

Library • 241 Generic TEWS Command Line Interface •

247 GenRoleXML.bat: • 207 Global User and Account

Synchronizations • 130 Global User Object and Account

Correlation • 116 Global User Objects • 116 GNU Tools • 186 GNU wget • 248 GRANT-BY-APPROVAL • 45 GRANT-BY-DEFAULT • 44 GRANT-BY-REQUEST • 45 GROUPS • 200

H

Help Desk Assisted Services • 47 HELP DESK AUTHENTICATION • 48

I

IDENTITIES • 199, 200, 201 Identity Account Synchronization Events

• 131 Identity and Global User Attribute

Mappings • 124 Identity Directory and Privacy • 69 Identity Group Membership Management

• 162 Identity Management Infrastructure •

275 Identity Manager Directory Level Security

• 27 Identity Manager Environment • 19 Identity Manager Environments • 25 Identity Objects Authorities • 47 Identity Policies • 153 Identity Policies and Automation • 15,

153 Identity Policies Evaluation

Considerations • 174 Identity Policy • 154 Identity Policy Actions • 154 Identity Policy and Authority

Considerations • 163 Identity Policy Automation Applications •

160 Identity Policy Evaluation • 159 Identity Policy Rules • 156 Identity Policy Set • 154 Identity Populations • 25 Identity Populations, Management, and

Authority • 43 Identity Self Service • 69 Identity Self-Service • 14 Identity/Account Status Propagation •

133 IME XML Files • 203 IME XML Files and Tools • 203 IMPORT USERS INTO A NEW USER

STORE • 141 IMPROVE DIRECTORY SEARCH

PERFORMANCE • 181 Inbound Synchronization • 124 INCREASE THE NUMBER OF POLICY

SERVER USER DIRECTORY CONNECTIONS • 183

Increment Procedure • 205 Initial Roll-out and Ongoing Operations •

67, 92, 107, 141, 150 Initial Roll-out of Identity Policies • 181 Initial Roll-out versus Ongoing Operations

for Compliance Reporting • 178

280 Index

Initial Roll-out versus Ongoing Operations User Entitlement Certification • 177

INSTRUCTIONAL PAGE AND URL • 94 Introduction • 13

J

JMS TUNING • 182

L

LDAP User Data Stores • 21 LEGAL NOTICE • ii Load NeteAutoDB.ldif • 198 LOGHANDLER.JAVA AND CLIENT-

CONFIG.WSDD • 245 Logical Attribute • 209 Logical Attribute API • 210 Logical Attribute Handler • 209, 210 loginGB.fcc • 222

M

MANAGED ENDPOINT SUPPLIED ATTRIBUTES • 129

ManagerDNAdapter Example • 210 Map Web Applications to the Users • 94 Member Directories • 71 Member Rules • 51, 52, 53, 55, 56, 57,

58, 60, 61, 62, 63, 64, 65, 85, 86, 87, 89, 90, 138, 139, 172, 173

MEMBER, ADMINISTRATOR, AND OWNER • 36

Move Client Program to Production • 245 Multiple IMEs and User Data Stores • 25 Multiple Independent Policy Servers •

101 MULTI-TENANCY ENVIRONMENT

DELEGATION • 46

N

Namespace and Managed Endpoint Management • 112

NeteAuto Public Directory • 81 NeteAutoDB.ldif Content • 198 New Identity Policies Roll-out

Consideration • 175 NOTIFY THE APPROVERS • 148

O

OBJECTS RELATIONSHIP AND ACCOUNT PROVISIONING • 129

Ongoing Operations for Identity Policies • 176

Operation and Maintenance • 68, 143, 151

ORGANIZATIONS • 199 Other Examples • 254 OTHER JAVA METHODS • 234 Outbound Synchronization • 125

P

PARTICIPANT RESOLVER RESOLUTION • 238

Password Management • 33 Password Policies • 34 Password Policies Planning Considerations

• 34 PASSWORD PROPAGATION • 134 Password Synchronization and

Propagation • 134 Password Synchronization/Propagation

Consideration • 146 Patches and Upgrades • 142, 275 PERSONALIZED CONTENT • 96 Personalized Web Application Delivery •

93 Personalizing Web Application

Presentation • 96 Physical Attribute • 209 PORTABILITY • 97 Prerequisites • 205, 241, 249 Presenting Web Applications to the Users

• 94 Privilege Package • 146 Privilege Package Display and Self

Request • 146 Privileges over Managed Endpoints • 115 Profile Self Service • 71 PROTECT THE FORGOTTEN PASSWORD

AND FORGOTTEN USER ID TASKS • 91 Provisioning Administration Delegation •

160 Provisioning Directory and Corporate

User • 122 Provisioning Engine and Identity

Management • 121 Provisioning Engineering • 132 Provisioning Infrastructure • 275 Provisioning Policies • 128 PROVISIONING ROLE ADMINISTRATOR

RULE • 127 PROVISIONING ROLE OWNER RULE • 127 PROVISIONING ROLES AND

ADMINISTRATIVE DIRECTORY • 127 Provisioning Roles and Authorities • 126 PROVISIONING SERVER • 192 PUBLIC ACCESSIBLE WSDL REALM • 216 Public Directories • 71 PUBLICLY ACCESSIBLE ENTRY POINT •

75 PUBLICLY ACCESSIBLE ENTRY POINTS •

73


Publicly Accessible Entry Points & Windows Login • 75

R

RDB User Data Stores • 22 Real World Implementation

Considerations • 66, 90, 107, 139, 150, 174

Rebuilding Your TEWS Client Library • 243

RECIPIENTS • 233 Re-Explore and Authority • 114 Re-Explore and Correlate • 120 Register an LAH • 212 REGISTERING AN LAH MANUALLY • 212 Remove Connector Xpress Custom

Connector • 269 Remove Managed Endpoints • 114 Remove or Disable Unused Public Tasks •

77 RENAME THE [DEFAULT USER] AND

CREATE A NEW ONE • 121 Reports for Return on Investment (ROI) •

179 Request Account Privileges of Interest •

146 Request and Approval • 44 Request Approval • 147 REQUIRED ATTRIBUTES • 129 Resolve Correlation Difficulties • 119 RESTRICTING ACCESS TO THE SELF

MANAGER ROLE • 90 Return On Investment • 108, 141, 150 Return-On-Investment and Time-To-

Value • 15 ROI FOR USING ENTITLEMENT

CERTIFICATION AND COMPLIANCE REPORTS • 179

ROI FOR USING IDENTITY POLICIES • 179

ROLE ANONYMOUS • 85 CIM CUSTOMER CERTIFICATION

MANAGER: • 173 CIM CUSTOMER SERVICE

REPRESENTATIVE • 51 CIM CUSTOMER SYSTEM MANAGER •

51 CUSTOMER • 86 CUSTOMER SERVICE REPRESENTATIVE

• 60 CUSTOMER SYSTEM MANAGER • 61 EIM EMPLOYEE • 89 EIM EMPLOYEE SELF SERVICE • 90 EIM HELP DESK • 62, 137 EIM HUMAN RESOURCE

REPRESENTATIVE • 62 EIM PROVISIONING ROLE

ADMINISTRATOR • 138

EIM PROVISIONING ROLE OWNER • 138

EIM SUPERVISOR • 63, 137 EIM SUPERVISOR DELEGATION • 64,

137 EMPLOYEE SYSTEM MANAGER • 65 MEMBER • 86 PROVISIONING SYNCHRONIZATION

MANAGER • 139 SELF CERTIFICATION • 172 SYSTEM MANAGER • 52, 57, 65 VENDOR ORGANIZATION MANAGER,

VENDOR VISIT REGISTRAR, VENDOR RECEPTIONIST, VENDOR SYSTEM MANAGER • 61

VIM VENDOR ORGANIZATION MANAGER • 54

VIM VENDOR RECEPTIONIST • 56 VIM VENDOR SYSTEM MANAGER • 57 VIM VENDOR VISIT REGISTRAR • 55

Role Based Policy • 100 ROLE ENGINEERING • 36 Role-Based Access Control • 35 RoleDefinitions.xml • 204 ROLL-OUT SCHEDULE • 92 RULE STRING • 128 RULES AND DELEGATION ACTIONS • 37

S

Sample Account Self-Services • 148 Sample

CertificationRequiredNotificationEvent.tmpl • 231

SAMPLE COMPLIANCE REPORTS • 168 Sample Delegated Account Management

Services • 135 Sample Delegated Identity Management

Services • 49 Sample Files and IMEs Build • 189 Sample Files Organization • 189 Sample Identity Manager Environments •

26 Sample Identity Policies and Certification

Services • 170 Sample Identity Self-Services • 77 Sample IME Building Procedures • 191 Sample KMS Files • 261 Sample NeteAuto Directory Information

Tree • 27 Sample User Data Store • 197 Sample Web Application Authorization

Services • 103 SAMPLEUTILS.JAVA • 245 SAVE YOUR WORK • 266 SCOPE CONFLICTS AND PRIMARY ADMIN

ROLES • 43 SCOPE RULES • 38 Secure Management Console Using the

Built-In CA SiteMinder • 24

282 Index

Secure TEWS • 216 Secured Communication Channels • 66,

140, 150 Secured Secure Self Services • 90 Self Authentication • 74 Self Authentication Questions and

Answers • 76 SELF CERTIFICATION • 167 Self Service and Authority • 71 Self Subscribing Groups • 97 Self-Registration • 72 Self-Registration Design Considerations •

72 SERVICE

ACCOUNT MANAGEMENT RELATED SYSTEM MANAGEMENT • 137

ACCOUNT PRIVILEGES PACKAGE GRANTING IDENTITY POLICY SET • 174

ACCOUNT PROVISIONING • 136 ACCOUNT PROVISIONING

ENGINEERING • 136 CUSTOMER DIRECTORY AND PROFILE

UPDATE • 50 CUSTOMER FORGOTTEN PASSWORD •

83 CUSTOMER FORGOTTEN USER ID • 85 CUSTOMER PORTAL • 105 CUSTOMER SELF-REGISTRATION • 78 CUSTOMER SERVICE ASSISTED

CUSTOMER STATUS CERTIFICATION • 171

CUSTOMER SERVICE ASSISTED ENABLE/DISABLE • 50

CUSTOMER SERVICE ASSISTED PASSWORD RESET • 50

CUSTOMER SERVICE ASSISTED SPECIAL INTEREST GROUP MEMBERSHIP • 50

CUSTOMER SPECIAL INTEREST GROUP • 104

CUSTOMER SPECIAL INTEREST GROUP MANAGEMENT • 50, 104

CUSTOMER STATUS CERTIFICATION • 171

CUSTOMER STATUS CERTIFICATION MANAGEMENT • 172

CUSTOMER STATUS CERTIFICATION OWNER IDENTITY POLICIES • 171

EMPLOYEE ACCOUNT PRIVILEGES PACKAGE MANAGEMENT • 149

EMPLOYEE ACCOUNT PRIVILEGES PACKAGE REQUEST • 149

EMPLOYEE ACCOUNT PRIVILEGES PACKAGE REQUEST APPROVAL • 149

EMPLOYEE ACCOUNT SERVICES SELF-HELP • 148

EMPLOYEE AND ORGANIZATION • 59 EMPLOYEE DIRECTORY • 88 EMPLOYEE IDENTITY MANAGEMENT

SYSTEM MANAGEMENT • 59

EMPLOYEE PROFILE SELF-SERVICE • 88

EMPLOYEE SELF AUTHENTICATION • 89

EMPLOYEE SELF-SERVICE NOTIFICATION • 87

HELP DESK ASSISTED ACCOUNT SERVICE • 136

HELP DESK ASSISTED SERVICES • 59 NETEAUTO MEMBER DIRECTORY • 82 NETEAUTO PUBLIC DIRECTORY • 81 SPECIAL INTEREST GROUP SELF-

SERVICE • 85 SUPERVISOR ASSISTED ACCOUNT

SERVICE • 136 SUPERVISOR ASSISTED SERVICES •

59 SUPERVISOR DELEGATION ASSISTED

ACCOUNT SERVICE • 136 SUPERVISOR DELEGATION ASSISTED

SERVICES • 59 SUPERVISOR FUNCTION DELEGATION

• 59 SUPERVISOR VIEW OF EMPLOYEE

DIRECTORY • 59 VENDOR IME COMPLIANCE IDENTITY

POLICY SET • 174 VENDOR ORGANIZATION

MANAGEMENT • 53 VENDOR PORTAL • 105 VENDOR RECEPTION • 54 VENDOR VISIT REGISTRATION • 53

SETENV.BAT • 250 SHOWPARM.JSP • 97 Single Policy Server • 101 Single Sign-on • 101 SITEMINDER PROTECTED TEWS REALM •

218 SOAP XML Document • 247 SPECIAL GLOBAL USER OBJECT • 121 Standalone TEWS Client Program • 244 STRONG SYNCHRONIZATION VERSUS

WEAK SYNCHRONIZATION • 131 Suggested Paths for Reviewing This Book

• 16 SUN Java Tools • 186 Supervisor Assisted Services • 48 Supervisor Delegation Assisted Services •

48 Support Non-Standard Namespaces • 139 System Generated Passwords versus

User Supplied Passwords • 76 System Identities • 198 SYSTEM PERFORMANCE • 92

T

Task and Event Email Notification • 228 Task Based Response • 100 TASK_TAG • 237


TASK-INFLUENCED WORKFLOW • 236 TEWS CA SiteMinder Policies • 216 TEWS Client Programs • 241 The Additional Synchronize User Event •

182 The Correlation-Matching Algorithm • 119 The Six Categories of Identity

Management Services • 13 Third Party Tools • 185 Third-Party Web Application Integration •

246 Triggering Identity Policies • 157

U

Uncorrelated (Orphaned) Accounts • 120 Update Global User and Authority • 117 USAGE BEST PRACTICES • 39 Use Connector Xpress • 261 User Data Store and Global User Objects

Synchronization • 123 User Data Store Management • 19 User Entitlement Certification • 166 User ID Identification • 75 User Interface Customization • 66, 140 User Profile Provisioning Automation •

162 USER SYNCHRONIZATION • 131 USER.AWK • 254 USERFILTERS.TXT • 255 USING ENVIRONMENTSETTINGS.XML •

212 USING IDENTITY POLICY FOR BUSINESS

LOGIC IMPLEMENTATION • 176 USING IDENTITY POLICY FOR DATA

TRANSFORMATION • 176 Utilities • 197

V

Vendor Delegated Identity Management Roles • 54

Vendor Delegated Identity Management Services • 53

Vendor Directories • 70 Vendor IME • 30 Vendor IME Machine • 195 Vendor IME Objects • 201

W

Web Application Authorization • 14, 93 wget Automation Examples • 251 wget Automation Utilities • 249 WHERE TO STORE USER INFORMATION •

141 WHO TO APPROVE • 148

WINDOWS LOGIN TECHNOLOGY (GINA) • 75

WORK LIST • 238 Workflow • 235 WORKFLOW APPROVAL TASKS • 236 Workflow Process • 236 WORKPOINT DESIGNER • 236 WorkPoint Workflow • 235 wsbatch Subdirectory • 249 WSBATCH.BAT • 250 WSCLIENT.BAT • 245 WSCMD.BAT • 250 WSSEARCH.BAT, WSSEARCH.XSL, AND

XSLT.VBS • 250 WSSEARCH.XSL • 256

X

XSLT.VBS • 255

ca identity manager green book enu

Documents