appendix h - pa created and administered by oa in cwopa active directory using ibm’s security...

Enterprise Application Security Solution (ESEC)

Appendix H - of 68

Appendix H Draft System Design Document


Appendix H - of 68

Table of Contents 1 Introduction ......................................................................................................................... 4

1.1 Business Problem Statement .............................................................................................. 4 1.2 Project Documentation Reference ....................................................................................... 4

1.2.1 Project Charter .......................................................................................................... 4 1.2.2 Requirements ............................................................................................................ 4 1.2.3 High-Level Use Cases ................................................................................................. 5

1.3 Purpose ........................................................................................................................... 5 1.4 Assumptions & constraints and important facts ..................................................................... 5

2 Use case analysis.................................................................................................................. 6 2.1 Actors ............................................................................................................................. 6 2.2 Use Cases ........................................................................................................................ 7

3 Solution Architecture .......................................................................................................... 11 3.1 Conceptual Logical Reference Architecture ......................................................................... 11 3.2 Infrastructure Architecture ............................................................................................... 15

3.2.1 Logical .................................................................................................................... 15 3.2.2 Physical .................................................................................................................. 15

4 Solution Design .................................................................................................................. 16 4.1 User Stores .................................................................................................................... 16

4.1.1 Internal Users .......................................................................................................... 16 4.1.2 External Users ......................................................................................................... 17

4.1.2.1 Organizations .......................................................................................................................................................... 17 4.1.2.2 Individual Users ...................................................................................................................................................... 17

4.1.3 Directory Structure & Schema .................................................................................... 17 4.1.3.1 Directory Structure ................................................................................................................................................. 17 4.1.3.2 Organization Attributes .......................................................................................................................................... 17 4.1.3.3 Group Attributes ..................................................................................................................................................... 18 4.1.3.4 User Attributes........................................................................................................................................................ 20

4.2 Initial Setup and Configuration ......................................................................................... 22 4.2.1 CA SiteMinder and CA IndentityMinder Integration ...................................................... 22 4.2.2 Access Management ................................................................................................. 23

4.2.2.1 Directory Mapping: ................................................................................................................................................ 23 4.2.2.2 External Administrative User Store ........................................................................................................................ 23 4.2.2.3 Installation and Registration of Admin UI ............................................................................................................. 24 4.2.2.4 Protect the SiteMinder Admin UI ........................................................................................................................... 24 4.2.2.5 Create Central Access Admin User ........................................................................................................................ 24

4.2.3 Identity Management ................................................................................................ 25 4.2.3.1 User Directories ...................................................................................................................................................... 25 4.2.3.2 Branding the User Console ..................................................................................................................................... 26 4.2.3.3 Protecting the IdentityMinder consoles .................................................................................................................. 26 4.2.3.4 User Credential Policies ......................................................................................................................................... 27 4.2.3.5 Group Configuration............................................................................................................................................... 28 4.2.3.6 Email Notifications ................................................................................................................................................. 28 4.2.3.7 Workflow Enablement ............................................................................................................................................ 29 4.2.3.8 Create Central Identity Admin User ....................................................................................................................... 29

4.3 ESEC Library .................................................................................................................. 30 4.3.1 ESEC Links UI Component ......................................................................................... 30


Appendix H - of 68

4.3.2 ESEC Authorization Helper ......................................................................................... 30 4.4 Use Case Realization ....................................................................................................... 31

4.4.1 Identity Management ................................................................................................ 31 4.4.1.1 Central Identity Administration .............................................................................................................................. 31 4.4.1.2 Delegated Identity Administration ......................................................................................................................... 31 4.4.1.3 Self Service Identity Administration ...................................................................................................................... 31 4.4.1.4 Workflows .............................................................................................................................................................. 33 4.4.1.5 Email Notifications ................................................................................................................................................. 33

4.4.2 Access Management ................................................................................................. 33 4.4.2.1 Login ...................................................................................................................................................................... 33 4.4.2.2 Authentication ........................................................................................................................................................ 33 4.4.2.3 Authorization .......................................................................................................................................................... 38 4.4.2.4 Session Management .............................................................................................................................................. 39 4.4.2.5 Logout .................................................................................................................................................................... 41 4.4.2.6 Access Policy Administration................................................................................................................................. 43

4.5 ESEC Configuration Migration ........................................................................................... 45 4.5.1 Identity Management ................................................................................................ 45 4.5.2 Access management ................................................................................................. 46

4.5.2.1 Migration of Access Policies across environments ................................................................................................ 46 4.6 Audit Logging ................................................................................................................. 47

4.6.1 Identity Management ................................................................................................ 47 4.6.2 Access Management ................................................................................................. 47

4.6.2.1 Web Services .......................................................................................................................................................... 49 4.6.2.2 Web Applications ................................................................................................................................................... 49

4.6.3 Log Clean Up ........................................................................................................... 49 4.7 Reporting ....................................................................................................................... 49

4.7.1 Identity Management Reports .................................................................................... 50 4.7.2 Access Management Reports ..................................................................................... 52

4.8 Monitoring ..................................................................................................................... 53 4.8.1 Access Management ................................................................................................. 53

5 Reference Application Implementation............................................................................... 55 5.1 Reference Web Applications ............................................................................................. 55 5.2 Reference WebServices ................................................................................................... 55

6 Glossary ............................................................................................................................. 56

7 Requirements Traceability .................................................................................................. 58


Appendix H - of 68

1 Introduction

1.1 Business Problem Statement PennDOT hosts a large number of applications to support its diverse and mission critical business functions. The end users of these applications are PennDOT staff, government and non-government external organizations, registered individual Users, and, sometimes, the general public (not registered users). PennDOT’s business and customer communities are constantly demanding greater accessibility to enterprise applications, services and data. Providing greater accessibility puts a greater demand on application security. A comprehensive centralized application security model is required to promote business efficiency by providing consistent access to information while protecting confidentiality and data integrity. PennDOT does not have a single model to address its application security requirements. In the Highway Administration Deputate, many applications use a custom developed Highway Administration User (HA User) security model, also known as ECMS Security Solution. Some applications in the Driver and Vehicle Services (DVS) Deputate and the new mobile applications use CA SiteMinder but the solution has gaps in the area of user provisioning, delegated user administration, and self service capabilities. Another custom security solution, RBSS, has been developed for .NET applications. In addition, there are applications that use one-off security solutions. Attempts were made to incorporate some best practices in these solutions. However, at best, there is significant duplication of effort in developing and maintaining multiple solutions. At worst, many of the solutions are incomplete and do not meet PennDOT and OA/OIT security standards. Therefore, it is necessary to move towards a single application security solution that all applications can consistently leverage to build applications more securely and efficiently. Therefore, an Enterprise Application Security Solution (ESEC) project has been initiated to implement a centralized single application security solution that all PennDOT applications can consistently leverage to build applications more securely and efficiently.

1.2 Project Documentation Reference

1.2.1 Project Charter Stage Gate 1 Charter

Stage Gate 2 Charter

1.2.2 Requirements Requirements

http://www.portal.state.pa.us/portal/server.pt/gateway/PTARGS_32_0_232_0_-1_47/http;/collaboration.state.pa.us;11930/collab/do/document/overview?projID=579645&documentID=790350




Appendix H - of 68

1.2.3 High-Level Use Cases Use Cases

1.3 Purpose The purpose of this document is to provide

• Solution architecture and detailed design for realizing various use case requirements • the rationale for the choices made among various architectural and design options. • links to the appropriate location in the CA product documentation for each section of this document.

1.4 Assumptions & constraints and important facts



Appendix H - of 68

2 Use case analysis

2.1 Actors

Actor Description

CWOPA User An internal Commonwealth Users. Includes all internal PennDOT users also.

Created and administered by OA in CWOPA active directory using IBM’s Security Identity Manager. Includes all state employees and contractors working for common wealth. Uses existing OA policies and procedures for self-service identity management functions like change profile, forgot password etc.

Have access to PennDOT systems/applications/services based on their role privileges.

Identity System Admin An internal PennDOT user.

Perform installation, configuration and maintenance of the ESEC Identity Management solution systems. Setup and assign global groups and roles.

Central Identity Admin An Internal PennDOT user.

Create and manage external users. Setup and assign external organization groups and application level groups

< Application> Identity Admin

An Internal PennDOT user.

Assigns/approves users’ access to their application/service by managing their application specific group membership and role assignment.

Access System Admin An internal PennDOT user.

Perform installation, configuration and maintenance of the ESEC Access Management solution systems. Setup and assign global groups and roles.

Central Access Admin An internal PennDOT user.

Manages all system objects and domain objects in all policy domains. Creates and assigns the application objects & workspaces for delegated <Application> policy admins.


Appendix H - of 68

Actor Description

< Application> Access Policy Admin

An internal PennDOT user

Define the resources, roles, and policies that are associated with their application/service.

Manages objects and domain objects in their application specific policy domains. Configures the access policy rules for their application/service.

<External Organization> Identity Admin

A user in an external organization (government or non-government) who has been given delegated identity administration role to create and manage user for their organization subjected to their role/organization privileges.

External User An external user (either individual user or an external organization user) who is registered in PennDOT user store to access PennDOT systems/applications/services based on their role privileges. Uses ESEC solution for self-service identity management functions like change profile, forgot password etc.

General Public (Anonymous User)

An external user who is NOT registered in ESEC user stores.

Internal Webservice client

External Webservice client

2.2 Use Cases *Limited to their organization @ Admin Roles only $ Only for groups/roles for which user is an Administrator # Only for their Application & Only for roles for which the user is an Owner % Restricted based on their authorization roles ^ Only Public pages


Appendix H - of 68

Use case

Iden

tity

Syst

em A

dmin

Cent

ral I

dent

ity A

dmin

< Ap

plic

atio

n> Id

entit

y Ad

min

Ce

ntra

l Acc

ess A

dmin

Acce

ss S

yste

m A

dmin

< Ap

plic

atio

n> A

cces

s Po

licy

Adm

in

<Ext

erna

l Org

aniza

tion>

Id

entit

y Ad

min

Iden

tity

Adm

in

Exte

rnal

Use

r

CWO

PA U

ser

Gene

ral P

ublic

(A

nony

mou

s Use

r)

Inte

rnal

web

serv

ice

clie

nt

Exte

rnal

web

serv

ice

clie

nt

Create User X X*

Search Users X X X X X X*

View User X X X X X X*

Modify User (except groups/roles but including passwords)

X

X*

Delete User X X*

Suspend User X X*

Reactivate User X X*

Create Group X X#

Modify Group X X#

Delete Group X X#

Manage Group Membership X$ X$ X$*

Create Role X@ X@ X#

Modify Role X@& X@& X#&

Delete Role X@& X@& X#&

Manage Role Assignments X@$ X@$ X$

X@

$

X$*


Appendix H - of 68

Use case

Iden

tity

Syst

em A

dmin

Cent

ral I

dent

ity A

dmin

< Ap

plic

atio

n> Id

entit

y Ad

min

Ce

ntra

l Acc

ess A

dmin

Acce

ss S

yste

m A

dmin

< Ap

plic

atio

n> A

cces

s Po

licy

Adm

in

<Ext

erna

l Org

aniza

tion>

Id

entit

y Ad

min

Iden

tity

Adm

in

Exte

rnal

Use

r

CWO

PA U

ser

Gene

ral P

ublic

(A

nony

mou

s Use

r)

Inte

rnal

web

serv

ice

clie

nt

Exte

rnal

web

serv

ice

clie

nt

Register External Organization

X

External Organization Self Registration

X

Individual User Self Registration

X

Forgot Password X X

Forgot UserID X X

Change Profile X X

Select Access to PennDOT applications/services

X X X

Request Access to PennDOT applications/services

X X X

Manage Access management System (SPS, DataPower, and Policy Server)

X

Manage Application Objects and Scoped workspaces

X

Manage application/service Access Policies

X

X#

Access an internet web application

X% X% X% X^


Appendix H - of 68

Use case

Iden

tity

Syst

em A

dmin

Cent

ral I

dent

ity A

dmin

< Ap

plic

atio

n> Id

entit

y Ad

min

Ce

ntra

l Acc

ess A

dmin

Acce

ss S

yste

m A

dmin

< Ap

plic

atio

n> A

cces

s Po

licy

Adm

in

<Ext

erna

l Org

aniza

tion>

Id

entit

y Ad

min

Iden

tity

Adm

in

Exte

rnal

Use

r

CWO

PA U

ser

Gene

ral P

ublic

(A

nony

mou

s Use

r)

Inte

rnal

web

serv

ice

clie

nt

Exte

rnal

web

serv

ice

clie

nt

Access an intranet web application

X% X% X%

Access an internet webservice X%

Access an intranet webservice X%

View identity management related Report

X X X X

X

View access management related report

X X X X

X

Impersonate as another user X

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/238840.html



Appendix H - of 68

3 Solution Architecture

3.1 Conceptual Logical Reference Architecture


Appendix H - of 68


Appendix H - of 68

3.2 Infrastructure Architecture

3.2.1 Logical

3.2.2 Physical


Appendix H - of 68

4 Solution Design

4.1 User Stores

4.1.1 Internal Users

The user profile and credentials for the PennDOT employees and contractors is currently maintained in CWOPA user directory along with other commonwealth internal users. ESEC solution will use the same CWOPA directory for authenticating the internal users. Internal users profile administration is not in the scope of ESEC. It will be managed by existing OA/OIT processes/procedures. Since agencies are not allowed to modify the CWOPA directory it will be used as a read-only user store. Internal users’ authorization data like group membership, role assignment, and additional attributes (if any required) will be maintained by ESEC in the agency scoped user store. Internal users will be authenticated in CWOPA user store and authorized in agency scoped user store.

Commonwealth Scope. Managed by existing OA processes/procedures using IBM’s Security Identity

Manager tool.

Active Directory for CWOPA users’ userid/password for authentication

Agency scope (shared by DPW, DL&I and PennDOT). Managed by ESEC solution

Active Directory for external users’ id/password for authentication and groups and roles for

authorization for external organization as well as internal CWOPA users

CWOPA (pa.lcl)

MANAGED_PROD (managed.apps.iam.lcl)

Agency scope (shared by DPW, DL&I and PennDOT). Managed by ESEC solution

Active Directory for external individual users’ id/password for authentication and groups and roles for authorization of

external individual users

SR_PROD (?????)


Appendix H - of 68

4.1.2 External Users For PennDOT external (organization & individual) users’, the credentials, profile, group membership, and role assignment data is maintained in agency scoped user store and managed by ESEC Solution’s admin UI. PennDOT external (organization & individual) users will be authenticated and authorized in agency scoped user store.

4.1.2.1 Organizations Any organization external to PennDOT (either government or private) which needs access to PennDOT applications & services and need multiple user accounts represent their entity or work for their entity. Example: Engineering Consultants and Contractor Business Partners who executes the PennDOT design contracts, Local Municipalities who process engineering agreements, Small Business Enterprises who apply for SBE certification, Advertisement Companies who apply for sign permits etc.

4.1.2.2 Individual Users Any external individual user (either citizen or legal resident) who needs a single user account to access PennDOT applications and services. Example: A users who apply for HOP, BOL, OAD sign permits

4.1.3 Directory Structure & Schema

4.1.3.1 Directory Structure

4.1.3.2 Organization Attributes

Attribute Description

Organization ID

Organization Name Data Type: Text, Len: 150

Organization Employer ID Number(FEIN)


Appendix H - of 68


Corporate Address, Phone, Fax

Legal Address

Mailing Address

Etc.

The following well-known attributes apply only to environments that support organizations: We need to map these to AD attributes %ORG_DESCR%

Indicates which attribute contains description of an organization. %ORG_MEMBERSHIP%

(Required) Indicates which attribute contains the DN of the parent organization of an organization.

%ORG_MEMBERSHIP_NAME%

Indicates which attribute contains the user-friendly name of the parent organization of an organization. %ORG_NAME%

(Required) Indicates which attribute contains the name of the organization.

An auxiliary class will be created in ldap (orgAddress) and this auxiliary class will be addeded to both the organzational class and to the organizational user class. The workflow of creating an organizational user could then obtain the organization's address object and add it to the user object.

where is the initial delegated admin stored and associated with the organization?

Ans: Initial delegated admin will be created in their respective OU.

4.1.3.3 Group Attributes


Group Name

Group Description

Administrator_ID


Appendix H - of 68


The following items are the list of group well-known attributes: %GROUP_ADMIN_GROUP%

Indicates which attribute stores a list of groups that are administrators of the group. For example, when group 1 is an administrator of group A, group 1 is stored in the %GROUP_ADMIN_GROUP% attribute. Note: If you do not specify a %GROUP_ADMIN_GROUP% attribute, CA IdentityMinder stores administrator groups in the %GROUP_ADMIN% attribute. Note: To add a group as an administrator of another group, see the Administration Guide.

%GROUP_ADMIN%

Indicates which attribute contains the DNs of administrators of a group. The physical attribute that mapped to %GROUP_ADMIN% must be multivalued.

%GROUP_DESC% Indicates which attribute contains description of a group.

%GROUP_MEMBERSHIP%

(Required) Indicates which attribute contains a list of the member of a group. The physical attribute that mapped to %GROUP_MEMBERSHIP% must be multivalued. The %GROUP_MEMBERSHIP% well-known attribute is not required for Provisioning user directories.

%GROUP_NAME%

(Required) Indicates which attribute stores a group name.

%ORG_MEMBERSHIP% (Required) Indicates which attribute contains the DN of the organization to which the group belongs. CA IdentityMinder uses this well-known attribute to determine structure of the directory. This attribute is not required when the user directory does not include organizations.

%ORG_MEMBERSHIP_NAME%

Indicates which attribute contains the user-friendly name of the organization in which the group exists. This attribute is not valid for user directories that do not include organizations.

%SELF_SUBSCRIBING%

Indicates which attribute determines whether users can subscribe to a group. %NESTED_GROUP_MEMBERSHIP%

Indicates which attribute stores a list of groups that are members of the group. For example, when group 1 is a member of group A, group 1 is stored in the %NESTED_GROUP_MEMBERSHIP% attribute. If you do not specify a %NESTED_GROUP_MEMBERSHIP% attribute, CA IdentityMinder stores nested groups in the %GROUP_MEMBERSHIP% attribute. To include groups as members of other groups, configure support for nested groups as described in Configuring Dynamic and Nested Groups for instructions.

%DYNAMIC_GROUP_MEMBERSHIP%

Indicates which attribute stores the LDAP query that generates a dynamic group.

Groups - default object class is “group”. --We will subclass group (perhaps naming it penndot_group) for the addition of Roles - default object class …Role-occupant. --Steve to confirm along with role attribute oid/class for addition to group object and user object. ? - attribute name from below case or that we will create for group class to store Check to see from below if an appropriate attribute exists to store role in group object or create new

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/267372.html




Appendix H - of 68

attribute “group_role”.

4.1.3.4 User Attributes


User_ID

First Name

Middle Name

Last Name

Phone

Address

Email

A list of user well-known attributes and the items to which they map follows: We need to map these to AD attributes and determine if we need to extend these to add address and phone information??? (via InetOrgPerson and the additional of orgAddress auxiliary class.) %ADMIN_OF%

Maps to the list of groups for which the user is an administrator. This well-known attribute can improve search performance at sites with many groups. Assume that the %ADMIN_OF% well-known attribute is specified. The CA IdentityMinder looks for those groups that a user can manage in the %ADMIN_OF% attribute, instead of checking every group in the user store.

%ADMIN_ROLE_CONSTRAINT%

Maps to the list of admin roles of an administrator. The physical attribute that mapped to %ADMIN_ROLE_CONSTRAINT% must be multivalued to accommodate multiple roles. We recommend indexing the LDAP attribute that is mapped to %ADMIN_ROLE_CONSTRAINT%.

%CERTIFICATION_STATUS%

Maps to the certification status of a user. This attribute is required to use the user certification feature. Note: For more information about user certification, see the Administration Guide.

%DELEGATORS%

Maps to a list of users who have delegated work items to the current user. This attribute is required to use delegation. The physical attribute that mapped to %DELEGATORS% must be multivalued and capable of holding strings. Important! Editing this field directly using CA IdentityMinder tasks or an external tool can cause significant security implications.

%EMAIL% Maps to an email address of a user. Required to use the email notification feature.

%ENABLED_STATE%

(Required) Maps to the status of a user. Note: This attribute must match the Disabled Flag user directory attribute in the SiteMinder user directory connection.


Appendix H - of 68

%FIRST_NAME%

Maps to the first name of a user. %FULL_NAME%

Maps to the first and last names of a user. %IDENTITY_POLICY%

Specifies the list of identity policies that have been applied to a user account and a list of unique Policy Xpress policy IDs that have performed add or remove actions on the user object. CA IdentityMinder uses this attribute to determine whether applying an identity policy to a user is required or not. Assume that the policy has the Apply Once setting enabled and the policy is listed in the %IDENTITY_POLICY% attribute. CA IdentityMinder does not apply the changes in the policy to the user. Note: For more information about identity policies, see the Administration Guide.

%LAST_CERTIFIED_DATE%

Maps to the date when the roles are certified to a user. Required to use the user certification feature. Note: For more information about user certification, see the Administration Guide.

%LAST_NAME%

Maps to the last name of a user. %MEMBER_OF%

Maps to the list of groups of which the user is a member. The physical attribute that mapped to %MEMBER_OF% must be multivalued to accommodate multiple groups. Using this attribute improves response time when searching groups of a user. You can use this attribute with Active Directory or any directory schema that maintains group membership of a user on the user object.

%ORG_MEMBERSHIP% (Required) Maps to the DN of the organization to which the user belongs. CA IdentityMinder uses this well-known attribute to determine structure of a directory. This attribute is not required when the user directory does not include organizations.

%ORG_MEMBERSHIP_NAME% (Required) Maps to the user-friendly name of the organization in which the profile of the user exists. This attribute is not required when the user directory does not include organizations.

%PASSWORD%

Maps to the password of a user. Note: This attribute must match the Password Attribute in the SiteMinder user directory connection.

%PASSWORD_DATA%

(Required for password policy support) Specifies the attribute that tracks password policy information.

%PASSWORD_HINT% (Required) Maps to a user-specified question and answer pair. The question and answer pair is used when users forget their passwords. To support multiple question and answer pairs, make sure that the %PASSWORD_HINT% attribute is multivalued. Note: If you are using Password Services feature of SiteMinder to manage passwords, the Password Hint attribute must match the Challenge/Response attribute in the SiteMinder user directory.

%USER_ID%

(Required) Maps to the ID of a user.



Appendix H - of 68

4.2 Initial Setup and Configuration

4.2.1 CA SiteMinder and CA IndentityMinder Integration As documented in CA SiteMinder Integration and SiteMinder Application Roles integrate the CA SiteMinder

and CA IndentityMinder products to achieve the following synergy.

• SiteMinder protects (by providing role based access control) IndentityMinder’s User Console and Management console

• SiteMinder uses the IdentityMinder’s access roles to author access policies to protect applications as

well as SiteMinder Admin UI.

• IndentityMinder administers the SiteMinder administartors.

The integration includes the disabling the IdentityMinder’s native authentication.

Further when CA IdentityMinder integrates with CA SiteMinder, CA SiteMinder can add the following functionality to a CA IdentityMinder environment:

Advanced Authentication

CA IdentityMinder includes native authentication for CA IdentityMinder Environments by default. CA IdentityMinder administrators enter a valid username and password to log in to a CA IdentityMinder

Environment. CA IdentityMinder authenticates the name and password against the user store that CA

IdentityMinder manages.

When CA IdentityMinder integrates with CA SiteMinder, CA IdentityMinder uses CA SiteMinder basic

authentication to protect the Environment. When you create a CA IdentityMinder Environment, a

policy domain and an authentication scheme are created in CA SiteMinder to protect that Environment.

When CA IdentityMinder integrates with CA SiteMinder, you can also use SiteMinder authentication to

protect the Management Console.

Access Roles and Tasks

Access roles enable CA IdentityMinder administrators to assign privileges in applications that CA

SiteMinder protects. Access roles represent a single action that a user can perform in a business

application, such as generating a purchase order in a finance application.

Directory Mapping

An administrator can possibly need to manage users whose profiles exist in a different user store from

the one that is used for authenticating the administrator. When logging in to the CA IdentityMinder


https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/346994.html#o351642





Appendix H - of 68

Environment, the administrator is authenticated using one directory and a different directory to

authorize the administrator to manage users.

When CA IdentityMinder integrates with CA SiteMinder, you can configure a CA IdentityMinder

Environment to use different directories for authentication and authorization.

Skins for Different Sets of Users

A skin changes the look of the User Console. When CA IdentityMinder integrates with CA SiteMinder,

you can enable different sets of users to see different skins. To accomplish this change, you use a

SiteMinder response to associate a skin with a set of users. The response is paired with a rule in a

policy, which is associated with a set of users. When the rule fires, it triggers the response to pass

information about the skin to CA IdentityMinder, to build the User Console.

4.2.2 Access Management

4.2.2.1 Directory Mapping: SiteMinder can authenticate users against one directory and authorize users against another directory. This

feature is called directory mapping. It is especially useful when authentication information is stored in a

central directory, but authorization information is distributed in separate user directories that are associated with particular network applications.

Using the SiteMinder’s Directory Mapping and Identity Mappings (Introduced in CA SiteMinder 12.51, Identity Mappings provide greater flexibility than the legacy directory mapping methods. Identity Mappings let you configure multiple target user directories and use custom search criteria) features configure the SiteMinder to connect to CWOPA as well as agency scoped directories.

For internal users CWOPA is the authentication directory and agency scoped directory is authorization directory.

For external users agency scoped directory serves as both authentication and authorization directory

4.2.2.2 External Administrative User Store By default, the Administrative UI uses the policy store as its source for CA SiteMinder administrator credentials. You can configure the Administrative UI to use an external administrator user store, for example, a corporate directory.

Using the External Administrative User Store concept configure the CWOPA user directory as the external

administrative user store so that internal users having CWOPA accounts can be given administrative access to

the SiteMinder Admin UI.





Appendix H - of 68

4.2.2.3 Installation and Registration of Admin UI The CA SiteMinder Administrative UI (Administrative UI) is a web–based administration console that is installed independent of the Policy Server. The Administrative UI is intended for managing all tasks that are related to access control, reporting, and policy analysis

The Administrative UI requires an application server to run. As such, two installation options are available:

Stand–alone installation—This option creates the required application server infrastructure through a

prerequisite installer. The prerequisite installer installs an embedded application server (JBoss) and the

required JDK. Verify that the Administrative UI host system meets the minimum system requirements

before starting the installation.

The prerequisite installer launches the Administrative UI installer after a successful installation. The Administrative UI installer uses the embedded application server infrastructure to complete the

installation.

Existing application server installation—This option lets you install the Administrative UI to an existing

application server infrastructure. The Administrative UI installer prompts you for application server-specific information and the location of the required JDK. Verify that the Administrative UI host system

meets all system and third–party component requirements before starting the installation.

Using the Existing application server installation install the SM Admin UI on the existing WAS server on shared infrastructure and register it with policy server.

4.2.2.4 Protect the SiteMinder Admin UI Make the SiteMinder Admin Web UI accessible over internet. We would leverage the WAS environment to deploy the SM Admin WEB UI (against the default JBoss) since it’s one less component to manage, has a support team and infrastructure already being maintained for backup, upgrades, etc

Using the Protect the Admin UI with SiteMinder feature, configure access control to protect the SiteMinder’s Administrative Web Interface access to allow only to SiteMinder Administarorts.

4.2.2.5 Create Central Access Admin User When you configure the policy store, a default superuser account is created. This account has the maximum

system privileges, which you use for the following operations:

Registering the Administrative UI with a Policy Server. Creating any other type of Policy Server object, including other administrator accounts. Using any of the Policy Server tools. Trusted Host administration. Managing the Policy Management API.




Appendix H - of 68

The default superuser account has the following credentials:

User Name siteminder Password The password that you specified when configuring the policy store.

This is the user represents the ‘Access System Admin’ in ESEC actors

As explained in Create SiteMinder UI Administrator documentation Access System Admin creates the Central Access Admin from one of the PennDOT users from CWOPA directory.

4.2.3 Identity Management This diagram needs to be replaced with the our penndot implementation diagram once it is ready

4.2.3.1 User Directories As explained in the documentation, instead of creating a separate IdentityMinder environment for CWOPA and Agency directories, we will let the IdentityMinder directly manage the Providioning Directory and use provisioning Server to indirectly manage the authorization data and extended attributes for CWOPA users in Agency directory. This approach allow us to

• Centrally manage users who can be assigned various enterprise resources from one location • Implement common security and business rules across enterprise resources. This may include the

following: o Role-based access control o Delegated administration o Tasks and screens that are customized based on the type of corporate identities they manage o Identity policies for rule-based identity management o Customization and extensibility




Appendix H - of 68

4.2.3.2 Branding the User Console Using the Skins feature and customizing the jsps, change the look and feel of the user console by applying ESEC, PennDOT logo, and styles. We will maintain consistent look & feel for all user roles.

Screen mockups for various functionalities to be added here. Sample screen for the home page is shown below.

4.2.3.3 Protecting the IdentityMinder consoles CA Identity Manager includes the following consoles, which should be protected:

User Console

Enables CA Identity Manager administrators to perform tasks in an Identity Manager environment.

Management Console

Enables CA Identity Manager administrators to create and configure an Identity Manager directory,

Provisioning Directory, and an Identity Manager environment.

Make both Consoles to be made accessible over internet to support delegated and self-service administration.

As explained in CA SiteMinder and CA IndentityMinder Integration section of this document integrate with SiteMinder and protect both the User Console and Management Console Enable the enhancement to protect CA IdentityMinder from Cross-Site Request forgery attacks.




Appendix H - of 68

4.2.3.4 User Credential Policies Using the appropriate combination of Policy Express, Password Polies, and Validation Rules features the OA/OIT’s policies for USERID and PASSWORD will be implemented.

We would need to identify which of the following policies/features we will be using to meet the ESEC requirements.

Policy Xpress Overview

Policy Xpress allows you to create complex business logic (policies) in CA IdentityMinder without the need to develop custom code. However, the concepts involved in creating Policy Xpress policies are complex and require careful thought and planning. An administrator using CA IdentityMinder portal screens can configure a policy within Policy Xpress to implement even the most sophisticated business logic required. As business policies change, an administrator can modify the policies using configuration screens within CA IdentityMinder without requiring a developer to make underlying code changes, or more importantly—with proper change management procedures—without restarting the CA IdentityMinder services

Password Policies Overview

A password policy is a set of rules and restrictions. These rules specify password creation and expiration. When you configure a password policy in a CA IdentityMinder environment, the policy applies to the user store associated with the environment. If a user directory is associated with multiple environments, a password policy defined in one environment can apply in other environments.

In a password policy, you can configure the following settings:

• Apply passwords to a specific set of users

• Password expiration—Define events, such as a number of days elapsing or a number of failed login attempts, that cause a password to expire. 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 which 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 match or do not match that format. You can also specify multiple regular expressions.

• 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 IdentityMinder takes, such as making passwords lower case, before processing a password. You can also specify the priority of a password policy when multiple password policies apply.

Validation Rules Introduction

Values are assigned to data store attributes through task screen fields or programmatically. Attribute validation rules help ensure that the values users type in task screen fields or that are supplied programmatically meet certain requirements, as in the following examples:

• User directory requirements, such as enforcing a data type, or verifying that an entry such as a date is formatted in a particular way.

• Data integrity. Does an entry make sense in the context of other information about the task screen or according to site-specific business rules?

A validation rule can be directly associated with a task screen field, or be indirectly associated with the field by being associated with a managed object attribute that is configured for the field.

All validation rules directly or indirectly associated with a task screen’s fields must be satisfied before CA IdentityMinder can begin processing the task. When a supplied value is invalid, a message associated with the violated rule is displayed, and the user can then correct the entry and resubmit the task.


https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/CreateaPasswordPolicy.html



Appendix H - of 68

4.2.3.5 Group Configuration

4.2.3.5.1 Dynamic & Nested Groups

Dynamic Groups enables you to define group membership by specifying an LDAP filter query in the User

Console dynamically. With dynamic groups, administrators do not have to search for and add group members

individually.

Nested Groups enables you to add groups as members of other groups.

As documented in Configure Dynamic and Nested Groups configure the support for both dynamic and nested.

<GroupTypes type=ALL>

4.2.3.5.2 Self-Subscribing Groups

You can enable self-service users to join groups by configuring support for self-subscribing groups in the

directory configuration file.

When a user self-registers, CA IdentityMinder looks for groups in specified organizations and then, displays the

self-subscribing groups to the user

Enable the support for self-subscribing groups as documented in Configure Self-Subscribing Groups to include the self-subscribing gropus from all organizations.

<SelfSubscribingGroups type=ALL_type org=org_dn>

4.2.3.6 Email Notifications CA IdentityMinder provides the following methods for configuring email notifications:

Email Notification Policies

Email notification policies enable business administrators to create, view, modify, and delete email

notifications by using tasks in the User Console. No coding is required to create email notifications.

Email templates

In this method, email notifications are generated from email templates. CA IdentityMinder provides

default email templates that can used as installed, or that can be customized by system administrators.

ESEC will use the Email Notification Policies (which are Policy Express Policies) to configure emails since it

off-loads the System Administrators and provide felxibility the business administrators to implement the email

requirements for the business processes without any need for customization and deployment of email

tempaltes.




Appendix H - of 68

As explained in the Configure SMTP Settings on WebSphere configure the SMPT settings.

4.2.3.7 Workflow Enablement ESEC will be using Template Method to configure the workflow processes against the WorkPoint Method. WorkPoint method needs the use of Management Console, WorkPoint designer and additional configuration of the workpoint administrative tools. template method allows you to configure workflow process templates in the User Console, without having to open WorkPoint Designer . For greater flexibility and ease of use, CA recommends that you use the template method whenever possible.

Further advantages of Template Method are

• Multi-stage process templates can address most workflow needs without requiring customization within WorkPoint Designer.

• Templates support both task-level and event-level workflow control.

• The same workflow process template can be configured for use with many different tasks while the process design itself remains unchanged.

• Participant resolvers can be specified easily in the User Console.

• Work item delegation can be performed in the User Console.

As documented in How to Enable Workflow enable the workflow in the CA IndentityMinder.

Enable the support for the delegation of the work-items with also enabling the support for Time-Based Work Item

Delegation

Enable the Bulk Operations support so that users can bulk approve, reject, release, and reserve work items that they own or work items from the delegators.

4.2.3.8 Create Central Identity Admin User System Administrator who installs and configures the CA IdentityMinder represents the ‘Identity System Admin’ in the ESEC actors.

Identity System Admin

creates the Central Identity Admin Role.

defines the Central Identity Admin Role.

selects all the available admin tasks to this role

define the administrator polices for this role such that Identity System Admin is the role administrator.


https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/HowToEnableWorkflow.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/HowToEnableDelegation.html




https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/BeginAdminRoleCreation.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DefinetheAdminRoleProfile.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/SelectAdminTasksfortheRole.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DefineAdminPoliciesforanAdminRole.html


Appendix H - of 68

define member policies for this role such that Identity System Administrators can manage the role assignments (by enabling the checkbox labeled “Administrators can add and remove members of this role.")

define the owner rules for this admin role such that Identity System Admin is the role owner.

4.3 ESEC Library ESEC library will be created with relevant common components to provide all the consuming application (based on the technology platform) the following features. This is to avoid duplication, promote reuse and centrally manage the common functionality. This will be in the form of a Jar file for Java applications and an assembly (dll) file for .NET applications. Domino???

4.3.1 ESEC Links UI Component This UI component will render the login form and links back to IndentityMinder screens based on the runtime input parameter values from the applications. This will be custom tag for Java applications and user control for .Net applications. Domino???

The input parameters are environment, isUserLoggedin, CSS styles, landingPageUrl etc.

4.3.2 ESEC Authorization Helper This backend component will take the HttpRequest object as an input and reads all the user profile attributes, groups and roles etc. and populates in a ESECUser object and return back to calling application.

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DefineMemberPoliciesforanAdminRole.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DefineOwnerRulesforanAdminRole.html


Appendix H - of 68

4.4 Use Case Realization

4.4.1 Identity Management

4.4.1.1 Central Identity Administration Create User

Modify User (profile, credentials, groups and roles)

Register an External Organization (includes creating an admin user in that Organization)

Approve/Reject External Organization registration

Modify an External Organization

Create External Org Groups and Application Groups/Roles

4.4.1.2 Delegated Identity Administration

4.4.1.2.1 External Organization Level

Create User for their organization

Modify User in their organization (profile, credentials, groups and roles)

4.4.1.2.2 Application Level

Create Groups/Roles for their application

Modify User (groups and roles of their application)

Approve/reject Access request to their application

4.4.1.3 Self Service Identity Administration CA Indetity Minder offers a ‘Self Manager’ Role which by default assigned to all users to perform self-service tasks like rest password etc. We can configure the Self Manager’ role such that Users in the commonwealth scope user stores will not have self-service features. Self-service admin features will only be available to users in PennDOT scope user stores. [Restrict Access to the Self Manager Role

By 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 as described in Define Member Policies for an Admin Role.]

4.4.1.3.1 Select Access (self-authorization)

A custom task and screen to be developed to display all applications/groups/roles 9which doesn’t need any autorizations) so that user can subscribe for them.


Appendix H - of 68

4.4.1.3.2 External Organization Self Registration

A custom task and screen to be developed to collect organization registration details and run it through a custom workflow to get it registered as a new Organization object in AD. An admin user account need to be created. Email notification to be implemented

4.4.1.3.3 Individual User Self Registration Configure the Self-Registration Task

Set Up a Default Organization for Self-Registered Users

Add Verification Questions and Answers

4.4.1.3.4 Don’t Delete this empty sub-section until Requirement Traceability Matrix is updated.

4.4.1.3.5 Forgot USER ID & Password Configure the Forgotten Password Reset and Forgotten User ID Tasks

The Forgotten Password Reset Task

The Forgotten User ID Task

Custom Forgotten Password Reset and Forgotten User ID Tasks

Collect Question and Answer Pairs for User Verification

Set Up the Forgotten Password Reset or User ID Task

Design Identification Screens

Design Verification Screens

Display Multiple Verification Questions At One Time

Display One Verification Question at a Time

Verify a User Attribute

Lock the Forgotten Password Reset or Forgotten User ID Task

Configure a Failed Attempt Limit

Configure a Successful Attempt Limit

Determine How Users Reset Passwords

Determine How Users Retrieve a Forgotten User ID

4.4.1.3.6 Change Profile A custom self service task and page need tobe developed to display the user profile (name, address, pho, email, userid, password etc.) and allow to modify

4.4.1.3.7 Request Access Custom task and Page will be developed to capture users request and run it through the custom workflow with concerned Application Admin as approvers to assign their application access to the user.

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ConfiguretheSelf-RegistrationTask.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/SetUpaDefaultOrganizationforSelf-RegisteredUsers.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/AddVerificationQuestionsandAnswers.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ConfiguretheForgottenPasswordResetandForgottenUserIDTasks.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/TheForgottenPasswordResetTask.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/TheForgottenUserIDTask.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/CustomForgottenPasswordResetandForgottenUserIDTasks.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/CollectQuestionandAnswerPairsforUserVerification.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/SetUptheForgottenPasswordResetorUserIDTask.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DesignIdentificationScreens.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DesignVerificationScreens.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DisplayMultipleVerificationQuestionsAtOneTime.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DisplayOneVerificationQuestionataTime.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/VerifyaUserAttribute.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/LocktheForgottenPasswordResetorForgottenUserIDTask.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ConfigureaFailedAttemptLimit.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ConfigureaSuccessfulAttemptLimit.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DetermineHowUsersResetPasswords.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/DetermineHowUsersRetrieveaForgottenUserID.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/toc.htm



Appendix H - of 68

4.4.1.4 Workflows

4.4.1.4.1 External Organization Registration Approval Work Flow A custom workflow

4.4.1.4.2 Request Access Approval Work flow A custom workflow

4.4.1.5 Email Notifications

Event Recipients

User is created User

User self registered User

User Profile, autorization id modified User

External Organization is created Admin User in that organization

External Organization is self registered and approved Admin User in that organization

Etc.

4.4.2 Access Management

4.4.2.1 Login

4.4.2.1.1 Centralized Login Page Use ESEC library

4.4.2.1.2 Application specific Login Page Use .fcc files

4.4.2.2 Authentication

4.4.2.2.1 Web Services

1.1. The IBM’s DataPower XI52 appliance installed in DMZ as part of the Gate Keeper project will be used to intercept the web services requests.


Appendix H - of 68

1.2. All the relevant necessary DataPower’s identity extraction methods (e.g. Http Authentication Header, Password-carrying UsernameToken Element from WS-Security Header, etc.) will be used in configuring AAA policies to address SSO requests, and web services requests.

1.3. All the appropriate DataPower’s authentication methods will be configured as an agent to the SiteMinder authentication.

1.4. CA SiteMinder will be used for authenticating the credentials passed to it by the DataPower agent.

Steve M: Should mention the SPS Proxy here and further detail the flow.

Murty N: I don’t think we need SPS here.

What are the pros & cons of using Direct LDAP call vs. using SM Policy server for authentication and authorization?

From a single-sign on perspective, this could save the user from an additional authentication. From SiteMinder perspective, allows for a policy to be enforced, auditing being consistent, and authorization to be determined by SiteMinder, and consistency with access to the LDAP layer maintained by SiteMinder as stated below. User directories are only accessed from internal network. Only SM Policy Server has access to User Directories. Single centralized process service for authentication and authorization for entire enterprise instead of different processes/systems doing the same thing.

4.4.2.2.1.1 Intranet

4.4.2.2.1.2 Internet

4.4.2.2.2 Web Applications Authentication and a Centralized Login Server

Overview of Authentication Scheme Processing

When a user attempts to access a protected network resource, the Policy Server uses the authentication scheme associated with the resource’s realm to to determine how to identify the user. The authentication scheme specifies the credentials that the user must supply for authentication, as well as the method used by the Policy Server to validate the user’s identity.



Appendix H - of 68

You can use the Policy Server User Interface to configure authentication schemes and assign the schemes to realms. The following diagram illustrates how an authentication scheme is called when a user attempts to access a protected resource.

In the example above, the user requests the protected resource sales.html from the /Sales/ realm. This realm requires Basic authentication. The Policy Server informs the Web Agent that the resource is protected and requests Basic credentials from the user via the Web Agent, which prompts the user for a user name and password.

4.4.2.2.2.1 Intranet

4.4.2.2.2.1.1 Windows Integrated Security How a Windows User Security Context Is Obtained

In a Windows network, a security context defines a user’s identity and authentication information. Web applications such as Microsoft Exchange Server or SQL Server need a user’s security context to provide native security in the form of Microsoft’s access control lists (ACLs) or other access control tools.

Note: In a Windows security context, the user store must be Active Directory (AD).

The SiteMinder Web Agent can provide a Windows user security context for accessing Web resources on IIS Web servers (Windows 2000 platforms). By establishing a user’s security context, the server can use this identity to enforce access control mechanisms.

By providing a Windows user security context, SiteMinder offers the following benefits:

Two levels of security

You can protect Web resources using SiteMinder’s many capabilities with the additional benefit of working with Microsoft’s own security tools to protect applications.

The Agent can collect user credentials over SSL connections, then allow subsequent requests over non-SSL connections. SiteMinder combines this mechanism for credential collection with the Windows security context when permitting access to Web resources.

SiteMinder can implement single sign-on using forms-based authentication, and pass on a user’s identity to back-office applications.

Microsoft does not provide general-purpose forms credential collection.

----------- How SiteMinder Is Configured to Provide a Windows User Security Context

Your IIS Web server environment must meet the following requirements to use the Windows security context feature:


Appendix H - of 68

All IIS servers have to be trusted in the domain in which the user is authenticating. You can establish trust relationships among servers that provide distributed services for groups of users. To set up trust relationships, see Microsoft server documentation.

Users must have the privileges to log on locally to the Web server. If there are multiple servers, users need the right to log on locally to all servers.

To enable a user to log on locally, configure this feature through the IIS Administrative Tools. See Microsoft documentation for instructions.

If you are using a specific domain account and not the system account when starting the World Wide Web Publishing Service, you must set the user’s account privileges to act as part of the operating system for the domain account running the service. This feature is configured through the Administrative Tools. See Microsoft documentation for detailed instructions.

4.4.2.2.2.2 Internet

4.4.2.2.3 Account Locking after five (5) consecutive failed log-on attempts

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/index.htm?toc.htm?2194471.html#o346024

Configure Password Expiration

You configure password expiration settings to define events, that when triggered, the Policy Server disables the user account and optionally redirects the user to a new Web page. Examples of such events include multiple failed login attempts and account inactivity.

Note: Expiration settings are optional. If you do not want to enable an expiration setting, leave the respective fields blank.

To configure password expiration

1. Click the Expiration tab.

Password expiration settings open.

Note: Click Help for descriptions of settings and controls, including their respective requirements and limits.

2. Specify user login tracking settings by selecting the Track successful logins, Track failed logins, and Authenticate on Login Tracking Failure check boxes in the Expiration group box.

Note: You must select the Track successful logins check box if you want to disable accounts based on account inactivity. You must select the Track failed logins check box if you want to disable accounts based on failed login attempts.

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/index.htm?toc.htm?2194471.html#o346024


Appendix H - of 68

3. Specify the settings that determine how often a password must be changed in the Password expires if not changed group box.

4. Specify the settings that determine how many incorrect password attempts are permitted in the Incorrect Password group box.

5. Specify the settings that determine how long a password can remain inactive in Password expires from inactivity group box.

Note: If you do not need to configure passwords to expire from inactivity, we recommended that you do not set this option for performance reasons.

6. Click Submit to save the password policy or click another tab to continue working with the password policy.

Unlock Procedure: ???

4.4.2.2.4 Prompting to change the password for expired/temporary passwords

4.4.2.2.5 Impersonation

We need to use Directory Mapping to include both CWOPA and Agency Directories for SM authentication and authorization. We have an Impersonation requirement also. SM supports Impersonation featutre but the documentation says Impersonation is not supported by directory mapping. So what are our options?

Steve M: True, directory mapping is a common dn mapped across two or more directories, and typical of authentication residing in directory A and authorization information in directory B. I’m working on the how of impersonation here yet.

4.4.2.2.6 Single Sign On SiteMinder provides single sign-on functionality across single and multiple cookie domains.

[Single Domain 1. The user authenticates once. 2. The Web Agent caches the successful authentication, and then issues a single sign-on cookie to the user’s

browser. 3. The single sign-on cookie provides the session information, so that users can access the following types of

resources without reauthenticating: a. Protected resources in other realms with an equal or lower protection level b. Another web server within this cookie domain

i. Users who try to access resources with a higher protection level must re-authenticate before they are granted access.

Multiple Domains 1. A user requests a protected resource in a domain within the single sign-on environment, and is challenged

for credentials. 2. When the user is authenticated, the following cookies are set in the user's browser:

a. the local cookie for the domain where the user has authenticated b. the cookie set by the cookie provider.

3. The user can navigate between the domains in the single sign-on environment without being rechallenged until either of the following events occur:

a. The user's session times out b. They end the session (usually by closing their browser) ]

Single Sign-on in Security Context

SiteMinder will provide single-sign-on across all supported web servers while preserving the security context required for seamless Microsoft security context.

However, this requires that any realm that may cause the user to be authenticated (and establish the SiteMinder session) be configured as “Persistent”. If the user authenticates in a realm that is not persistent, the user will be challenged again when SiteMinder needs to persist the security context.



Appendix H - of 68

4.4.2.2.7 Anonymous Login [Anonymous Authentication Schemes

The Anonymous authentication scheme allows SiteMinder to provide access privileges to users who are not yet identified in your network. Assigning an Anonymous authentication scheme to a realm does not provide access control, but it does allow SiteMinder to personalize content for the user.

When a user accesses a resource in a realm that uses the Anonymous scheme, the Policy Server assigns a Global Unique Identifier (GUID). This GUID is stored on the user’s browser and provides a method for identifying the anonymous user.

When you create an Anonymous authentication scheme, you must specify a guest distinguished name (DN). You can bind policies to this guest DN that provide personalized content.

Note: Personalized content in a realm protected by an Anonymous scheme is based on the guest DN, not the GUID of the user. Anonymous users view content according to policies that include the guest DN. Identified users have a distinct DN, so an identified user who accesses the same resource (protected by an anonymous scheme) views the content of the resource based on their unique DN rather than the guest DN.

Note: If you want to track users for a realm with an Anonymous authentication scheme, the realm must be a protected realm.]

4.4.2.3 Authorization

How to Define the Security Policy for a Web Application in an Application Object Verify Your Administrative Rights Create the Application Object and Define the General Properties of Your Security Policy Designate the Application Resources Create Roles That Identify the Users That Can Access the Protected Resources (Optional) Configure Responses to Customize the Web Application (Optional) Configure Response Groups to Customize the Web Application Configure a Policy to Associate Resources with User Roles

(Optional) Configure Advanced Application Options (Optional) Configure Custom Attributes to Add Metadata About the Application Configure Confidence Levels in Applications Configure CA DataMinder Content Classifications in Applications Configure Advanced Policy Components for Applications

Use Cases for Defining Application Security Policies Using Application Objects

Application Security Policy to Protect a Web Portal Identify the Web Portal and Select the User Directory Create the Web Portal Resources Create the Web Portal Roles Create the Web Portal Policy Application Security Policies Based on Roles Identify the Application that Needs Protecting Designate the Application Resources























https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/toc.htm





Appendix H - of 68

Create an Employee Role Create a Manager Role Use a Response to Supply Data to the Application Establish a Policy Based on Roles Include Metadata that Describes the Application Application Security Policies with User Mapping and Named Expressions Establish Mappings for the Two User Directories Define Named Expressions to Check the Credit Limit Protect the Online Shopping Application Designate the Resource Requiring Protection Configure the Customer Role Customize the Application with a Response Configure the Security Policy for the Shopping Application Provide Metadata to Describe the Application

4.4.2.4 Session Management By managing sessions, you control how long an authenticated and authorized user can access the resource.

You can control sessions by:

Steve M: Application timeouts can be established to override SM policy server default timeouts, but your organization needs to determine if that is acceptable. A low risk Application A may lean towards a longer timeout that a high risk Application B. I’ve typically seen organizations go to setting an enterprise standard of time out allowed and enforce it at the Policy Server timeout level.

Specifying the amount of time a user can remain idle, without interacting with the resource.

Idle timeouts protect against unauthorized use of the resource by limiting the amount of time the

session remains active if it is not being used. The idle timeout is particularly useful in cases where users leave their computer without logging out of their session. When the idle timeout limit is reached, the

session automatically ends.

Specifying the maximum amount of time a user can access a resource before they must re-authenticate.

Maximum timeouts protect against unauthorized use of a resource by forcing an authenticated user to

re-authenticate after a specified time. This safeguard ensures that if an authenticated user leaves the

computer without logging out and someone else uses the open session, the session will end after a

specified amount of time, and the user must re-authenticate to continue using the resource.

Revoking a user’s access to a resource at any time.

In addition to managing how long a session can remain active, you can also end a session immediately

if you suspect the integrity of a resource has been compromised. Once a user session has been

















Appendix H - of 68

revoked, the user is disabled in the user directory until you have re-enabled the user with the Policy

Server User Interface.

For more information about managing sessions, see the SiteMinder Policy Server Management Guide.

Enabling persistent sessions.

You can also implement persistent sessions to provide Windows security context functionality and

support for Federated Web Services.

Session Tickets SiteMinder implements session management using session tickets. A session ticket contains basic information

about a user and that user’s authentication information; it is used to identify the user’s session across all sites

in a single sign-on SiteMinder environment. Session tickets are encrypted and can only be read/validated by the Policy Server. SiteMinder Web Agents use session tickets to identify users and provide session information

to the Policy Server.

The session ticket is handled differently depending upon whether the session is persistent or non-persistent.

Note: Non-persistent and persistent cookies are unrelated to the user’s SiteMinder session being non-persistent or persistent.

Non–persistent session

The Web Agent places the session ticket in a cookie. The cookie contains the user session data; no

user-specific data is kept in the cookie itself. The Web Agent is responsible for validating the cookie

and enforcing session timeouts.

Persistent Session

The Web Agent places the session ticket in a session server database and, if possible, in an optional

cookie on the client.

The session ticket data is used as an index into the Web Agent’s cache, which contains the user session data. If

a cookie is written, no user-specific data is kept in the cookie itself. The Web Agent is responsible for validating

the session and enforcing the session timeouts.

How Sessions Across Multiple Cookie Domains Are Maintained SiteMinder supports single sign-on across multiple cookie domains in environments with heterogeneous Web

server platforms. If a user visits companyA.com and then goes to companyB.com, his or her session

information stays with them. To maintain session information across multiple cookie domains, the Web


Appendix H - of 68

Agents must be configured for single sign-on. With single sign-on configured, the cookie that contains session

information can be made available to all Agents and servers in the single sign-on environment.

The ability to pass session and identification information across multiple cookie domains enables a user to

authenticate at a site in one cookie domain and then navigate to a site in another cookie domain without

being re-challenged for information.

Single sign-on is accomplished using a cookie provider. The cookie provider is an extension of the Web Agents

in the single sign-on environment.

To achieve cross-domain logout for resources in separate cookie domains, you can enable persistent sessions

for the realms in separate cookie domains. When a user logs out in one domain, the Policy Server sends a

logout event terminating the user session.

Note: Single sign-on across multiple cookie domains does not require that the same user directory be used

across the single sign-on environment. However, user directory connections configured in the Policy Server User Interface must share the same directory object name in each cookie domain.

4.4.2.5 Logout https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/1862531.html?zoom_highlight=multiple

How to Configure Full Logoff for Single Sign-on

In a single sign-on environment, the session cookies are removed only from the local cookie domain and the

cookie provider domain associated with the Web Agent. For single sign-on across multiple cookie domains, the full log-off feature of CA SiteMinder does not automatically log a user off across all the cookie domains that

the user has visited.

To configure log-offs across multiple cookie domains, use the following process:

1. Create one centralized log-off page that contains separate frames (or iframes) for the other cookie domains in your

SSO environment. These frames can be a small size, such as 1x1 pixels.

2. For each frame of the centralized log-off page in Step one, add a hyperlink to the Logoff Uri of the associated

cookie domain. For example, if you have two other cookie domains, example.org and example.net, you would do the

following steps:

Add a hyperlink to the Logoff Uri of example.org to one frame.

Add a hyperlink to the Logoff Uri of example.net to the other frame.

3. Configure the LogoffUri of the cookie provider domain to point to the centralized log-off page. When the web

server loads this log off page, the frames in the centralized log-off page call the logoff pages from the other cookie domains.

The user is logged off from all the cookie domains at once.

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/1862531.html?zoom_highlight=multiple

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/1862531.html?zoom_highlight=multiple


Appendix H - of 68

The following illustration shows an example of using a centralized log-off page:

Note: You can also place the hyperlinks inside <iframe> tags instead of <frame> tags.

Configure Comprehensive Log Out using FCC Forms

If you use FCC forms to authenticate your users, you can configure a comprehensive log out with your FCC

form. This method provides an alternative to the LogoffUri parameter.

Follow these steps:

1. Open the .fcc file that you are using to authenticate your users with a text editor. FCC files are located in the

following directory:

2. web_agent_home/samples/forms

web_agent_home

Indicates the directory where the CA SiteMinder Agent is installed.


Appendix H - of 68

Default (Windows 32-bit installations of CA SiteMinder Web Agents only): C:\Program

Files\CA\webagent

Default (Windows 64-bit installations [CA SiteMinder Web Agents for IIS only]): C:\Program

Files\CA\webagent\win64

Default (Windows 32-bit applications operating on 64-bit systems [Wow64 with CA SiteMinder Web

Agents for IIS only]): C:\Program Files (x86)\webagent\win32

Default (UNIX/Linux installations): /opt/ca/webagent

3. Add the following text to the top of your FCC page (before the <_html> tag):

4. @smlogout=true

5. @target=http://server_name.example.com/directory/your_logout_pag

e.html

Note: your_logout_page indicates a custom html page you create to inform users that they have

logged out.

Comprehensive logout using FCC forms is configured.

4.4.2.6 Access Policy Administration

4.4.2.6.1 Central Access Policy Administration

• We can use SiteMinder’s out of the box Policy Management Console. [The Policy Server can be configured using the Policy Server User Interface (UI). The Administration service of the Policy Server is what allows the UI to record configuration information in the Policy Store Administrator Concepts

Everyone who has access to Policy Server objects and tools is considered an administrator. Depending on their role in your organization, Policy Server administrators have access to different network resources and Policy Server features, and are responsible for different tasks.

When you install the Policy Server, the installation sets up a default administrator account automatically. This account has maximum privileges, and with it you can create additional administrator accounts for those who need to add or make changes to Policy Server objects.

The following diagram illustrates the types of administrator privileges associated with certain job responsibilities.


Appendix H - of 68

In the previous figure, certain administrative responsibilities overlap. For example, the Policy Manager and the Sales Manager may both make changes to the Sales policy domain and the objects (rules, policies, responses, etc.) contained in the policy domain. The Super User may access all objects, manage users, and view all reports. You can create administrators and assign privileges to the administrators to match the administrative roles that exist in your organization.]

4.4.2.6.2 Delegated Access Policy Administration

• Policy Server User Interface is a web based. So we can use the same for delegated administration. Administrator Scope and Tasks

The Scope specified for an administrator determines the range of Policy Server objects they can create, edit, and delete:

System Administrator

A system administrator can manage all system objects and domain objects in all policy domains

Domain Administrator

A domain administrator can only manage objects in one or more specified policy domains.

An administrator’s scope also determines the range of tasks that they can be configured to perform on those tasks.]

Advantages of Securing Your Resources Using Application Objects

Application objects provide an access management model that lets you protect business applications without an in-depth knowledge of CA SiteMinder-specific concepts and components. This model is also known as Enterprise Policy Management (EPM).

Application objects present policy configuration in the context of securing an application. To protect an application, you create an Application object and are only required to provide data for configuration settings that do not have defaults. Modifying other settings is optional.


Appendix H - of 68

Application objects therefore make policy configuration more straightforward. You can manipulate additional CA SiteMinder settings that allow you to define more fine-grained protection of an application; however, such manipulation is not required.

Application objects offer the following benefits:

Application-centric approach

The focus on applications relates closely to the view of access management by most businesses.

Consistent security enforcement model

The security enforcement model for application objects is no different than implemented by the more domain-centric model. However, the domain-specific components are hidden from configuration.

Simplified security

Securing resources is simplified—you name the application, the application resources that need protecting, and the application roles that are permitted access. You are not required to examine or modify every aspect of a component to establish a security policy.

Enhanced delegation

A CA SiteMinder administrator can grant access to an application without expert knowledge of CA SiteMinder. This ability enables a senior security administrator to delegate access management responsibilities to other administrators.

4.5 ESEC Configuration Migration

4.5.1 Identity Management To migrate Admin roles and task definitions

To export Admin role and task definitions

To import Admin role and task definitions

To verify the role and task import

To migrate CA IdentityMinder skins

Update CA IdentityMinder in a Production Environment

To migrate a CA IdentityMinder environment

To export a CA IdentityMinder environment

To import a CA IdentityMinder environment

To verify the CA IdentityMinder environment migration

Migrate the iam_im.ear for WebSphere

Migrate Workflow Process Definitions

Export process definitions

Import process definitions



















Appendix H - of 68

4.5.2 Access management

4.5.2.1 Migration of Access Policies across environments Policy server tools XPSExport and XPSImport will be used for migrating the data from one environment to

another (e.g. DEV, TEST, PROD).

The XML-based export format uses the following fundamental schemas:

XPSDeployment.xsd

Describes the top-level schema, which includes the other schemas. It defines the root element and

sub-elements. An XML file conforming to this schema can contain an instance of Data Dictionary,

Policy, and Security Data.

XPSDataDictionary.xsd

Describes meta-data information about object types and their properties.

XPSPolicyData.xsd

Describes the meta-data information about objects stored in the policy store, such as domains,

policies, rules, applications, and the relationships between them.

XPSSecurityData.xsd

Describes meta-data used for representing policy store administrators and their access rights.

XPSGeneric.xsd

Contains definitions of the generic data types used in the other schema files.

This format supports not only exporting and importing policy data in its entirety, but also exporting and importing a subset of the policy data. A granular export presupposes knowledge of how the data will be

imported. On export, you can specify the entire policy data, or a portion of the data using an object identifier

and optionally one of these three export types:

Add—specifies that only additions can be done during import.

Replace—specifies an overwrite of existing policy data during import.

Overlay—specifies that updates to policy data are done during import.

Note: The XPSExport and XPSImport tools encrypt sensitive data based on the FIPS mode the Policy Server is operating in. There are no additional parameters in these tools to set for data encryption




Appendix H - of 68

4.6 Audit Logging

4.6.1 Identity Management To audit a CA IdentityMinder environment, configure CA IdentityMinder to log audit data. Audit data provides

a historical record of operations that occur in a CA IdentityMinder environment. Some examples of audit data

include the following points:

System activity for a specified period of a time.

User login and logout events while accessing a particular environment.

The tasks that a specific user performs

A list of objects that were modified during a specific period of a time.

The user assigned roles

The operations which are performed for a particular user account.

Audit data is generated for CA IdentityMinder events. An event is an operation that is generated by a CA

IdentityMinder task. For example, the Create User task may include an AssignAccessRoleEvent event.

How to Configure Auditing

Configure Audit Settings

Audit Settings File

Audit Element

AuditLevel Values

AuditEvent Element

AuditProfile Element

AuditProfileAttribute Element

EventState Element

How to Enable Auditing For a Task

How to Configure CA IdentityMinder to Audit User Login and Logout Events

4.6.2 Access Management The purpose of audit logs is to track information about all user activity, including:

All successful authentications All failed authentications All successful authorization attempts All failed authorization attempts All administrative login attempts












https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/audit_user_login_logout_events.html





Appendix H - of 68

All administrative actions, such as changes to administrator passwords, the creation of policy store objects, and changes to policy store objects

Policy Server can write the audit events to either a text file (default) or to a relational database configured as an audit store using 5.x or 6.x schema. The relational database can be a standalone or the policy store itself. It is recommended to store the audit logs in database to make it accessible to the Report server and other security reasons. But logging audit events directly in a database have the potential add to latency. This latency occurs because of the additional traffic between the Policy Server and the database. As the amount of transactions increase, this database latency can affect the performance of the Policy Server. When the database slows down, the Policy Server also slows down.

Hence it is designed to write the logs to a text file for performance reasons and using the smauditimport to read the text file and load the audit database to make it accessible to Report server.

By default, the Policy Server logs less audit data to a text file than to a database. You can log more audit data to a text file than the default and bring the amount of data in line with a database by manually adding the ‘"Enable Enhance Tracing” registry key and set its value to one.

Steve M Comments: Yes the logging to text file can be faster than database, as long as the text file is rotated often (not introducing lag through a large file that takes incrementaly longer to write). The trade-off here is expectations on how up to date the audit database is and any issues that might cause for users/administrators relying on the audit database, and reporting from it. The interval of smauditimport (is it being run once a 24 hour period ? ) would need to be understood by the users.

Configuring Policy Server Logging Policy Server Logging Overview

Configure the Policy Server Logs Record Administrator Changes to Policy Store Objects How to Process Old Log Files Automatically How to Include CA SiteMinder Administrative Audit Events in Reports Mirror ODBC Audit Log Content in Text-based Audit Logs on Windows Mirror ODBC Audit Log Content in Text-based Audit Logs on Solaris

Report Logging Problems to the System Log Configure Certificate Data Store Logging

How to Record Events to the Syslog













https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/record_events_to_syslog.html




Appendix H - of 68

Open the Console Set the Syslog Options Stop Your Policy Server Start Your Policy Server How to Enable Assertion Attribute Logging on Windows Operating Environments Open the Windows Registry Editor Change the Value of the Registry Key Stop Your Policy Server Start Your Policy Server How to Enable Assertion Attribute Logging on UNIX or Linux Operating Environments Open the sm.registry File with a Text Editor Change the Value of the Line in the Registry File Stop Your Policy Server Start Your Policy Server

4.6.2.1 Web Services DataPower logging???

4.6.2.2 Web Applications

4.6.3 Log Clean Up The auditing database may eventually accumulate records that are no longer necessary. To cleanup these

records, execute the following database procedure in the db\auditing directory:

garbageCollectAuditing125 environment-name MM/DD/YYYY

environment-name

Defines the name of the CA IdentityMinder environment

MM/DD/YYYY

Defines the date before which the auditing records must be removed.

4.7 Reporting ESEC will be utilizing the PennDOT’s existing BusinessObjects server in place of CA Report Server. (its one less component to install, manage, upgrade over time etc)

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/record_events_to_syslog.html#o2086560




https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/enable_assertion_attribute_logging_w.html

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/enable_assertion_attribute_logging_w.html#o2086595




https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/enable_assertion_attribute_logging_ul.html

https://support.ca.com/cadocs/0/CA%20SiteMinder%2012%2051-ENU/Bookshelf_Files/HTML/idocs/enable_assertion_attribute_logging_ul.html#o2088329








Appendix H - of 68

4.7.1 Identity Management Reports The Report Process

The following graphic details the process required to run and view reports:

Snapshot Reports—Include data from the Snapshot Database, which contains information from the CA IdentityMinder object store and the CA IdentityMinder user store. An example of a Snapshot Report is the

User Profile report. You define the data that is added to the Snapshot Database using Snapshot Definitions

that specify the information to include.

Non-Snapshot Reports—Include data from other data sources, such as the Audit Database. For example, CA

IdentityMinder includes default audit reports. (These reports have the prefix "Audit - " in their name in the

User Console). By default, CA IdentityMinder only includes Audit reports, but you can create your own custom

reports that include data from any data source, such as the Workflow or Task Persistence databases.

Custom Reports

Each report within CA IdentityMinder requires initial configuration before you can run it. The configuration

steps depend on the type of report that you want to run.


Appendix H - of 68

For Snapshot Reports, do the following:

Configure the Report Server Connection

Create a Snapshot Database Connection

Create a Snapshot Definition

Example: Creating a Snapshot Definition for a User Entitlement Data

The Snapshot Parameter XML File

Create a Custom Snapshot Parameter XML File

Manage Snapshots

Capture Snapshot Data

Recurrence Tab

Associate a Snapshot Definition with a Report Task

Associate a Connection with a Report Task

Request a Report

Report Scheduler

Manage Report Recurrence Schedules

View the Report

For Non-Snapshot Reports, do the following:

Configure the Report Server Connection

Create a Connection for the Report

Associate a Connection with a Report Task

Request a Report

Report Scheduler

Manage Report Recurrence Schedules

View the Report

Set Reporting Options

Custom Reports

Create a Report in Crystal Reports

Create the Report Parameter XML File

SQL

Java Beans

String Literals

Hidden Parameters

Example Report Parameter XML File

Upload the Report and Report Parameter XML File

Create the Report Task

Profile Tab for Report Task

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/HowtoGenerateReports.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ReportServerConnection.html


https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/CreateSnapshotDefinition.html


https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ConfigureExportCommandFile.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ExportCommandFile.html



https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/TaskRecurrence_2.html



https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/RunReports.html





https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ReportServerConnection_1.html



https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/RunReports_1.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/ReportsScheduler.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/851609_1.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/567477_1.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/SetReportingOptions.html









https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/CreateAdminTasks_Reports.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/Profile_ReportAdminTask.html








Appendix H - of 68

Search Tab for Report Task

Create New Search Screen for Report Task

Tabs Tab for Report Tasks

Once the initial configuration for your report is complete, you can then request a report within CA

IdentityMinder. You can run a report immediately, or you can schedule a report to run at a later time. You can

also create a recurring schedule for your report within CA IdentityMinder.

Lastly, you can view the report within the User Console, or you can export the report to various formats.

CA IdentityMinder installs default reports that you can customize to suit your needs. The default reports are located in the following directory:

MSSQL

C:\Program Files\CA\Identity Manager\IAM Suite\Identity Manager\tools\imrexport\ReportDefinitions\IM Standard Reports\Ms-SQL Reports

4.7.2 Access Management Reports The following diagram details a sample CA SiteMinder environment and lists the order in which each

component is installed or configured:

The following list explains each of the illustrated steps:

1. Install the Report Server—Installing the Report Sever is the first step in the process. You

configure a report database during the installation.

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/SearchParameters_Reports.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/NewSearchScreen_Reports.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/TabsTab_Reports.html

https://support.ca.com/cadocs/0/CA%20IdentityMinder%20r12%206-ENU/Bookshelf_Files/HTML/idocs/SampleReports.html




Appendix H - of 68

2. Install the CA SiteMinder report templates—Installing the CA SiteMinder report templates is

the second step in the process. The CA SiteMinder Report Server Configuration Wizard configures the

Report Server to use a set of CA SiteMinder policy analysis and auditing report templates.

3. Register the Report Server—Registering the Report Server is the third step in the process.

Registration requires that you configure a connection between:

The Report Server and a Policy Server

The Report Server and the Administrative UI

4. Configure a CA SiteMinder audit database—Configuring a CA SiteMinder audit database is the

fourth step in the process. A separate CA SiteMinder audit database, which is registered with the

Administrative UI, is required to run audit-based reports.

SiteMinder Reports Report Descriptions Schedule a CA SiteMinder Report View CA SiteMinder Reports Delete CA SiteMinder Reports

4.8 Monitoring

4.8.1 Access Management SiteMinder OneView Monitor identifies performance bottlenecks and provides information about resource usage in a CA SiteMinder deployment. It also displays alerts when certain events, such as component failure, occur.

The following graphic illustrates how the OneView Monitor is integrated in a CA SiteMinder deployment.











Appendix H - of 68


Appendix H - of 68

5 Reference Application Implementation

5.1 Reference Web Applications Reference web applications with minimum necessary requirements to test all the services of the ESEC solution (administration, authentication, SSO, authorization, audit logging, and reporting) are to be developed in Java, .NET, Domino technologies and deployed internet as well as intranet. Details TBD.

5.2 Reference WebServices Reference web services (both SOAP and REST) with minimum necessary requirements to test the ESEC services are to be developed and deployed internet as well as intranet. Details TBD.


Appendix H - of 68

6 Glossary Term Definition/Meaning

User Identity Store A repository (normally in the form of database) contains User information like name, account credentials, and their group and role associations.

Access Policy Store A repository (normally in the form of database) contains information related to the application resource groups and the policies/rules defined to gain access to those application resources and services.

User Identity Administration

Business transactions related to User Identity like, create/modify/suspend/lock/delete user accounts, change/reset password, manage group membership, role assignments.

Access Policy Administration

Activities related to configuring the application resources, and defining authorization rules like what roles and groups etc. can have access to a specific application resource/ group of resources.

Central Administration Administration (user and/or policy) done by a single group or groups globally.

Delegated Administration

Administration (user and/or policy) done by small groups of specially-privileged individuals within the user community with permission to manage data for their own organization/application.

Self-Service Administration

Administration transactions done by the individuals on their own profile like (self-registration, change/reset password, update profile etc.)

Work-Flow Work-flow is configuring a business process in a sequence of steps, action and events and assigning the responsibilities (based on RACI matrix) for each step/action/event so that the process is completed with proper approvals and communication. (RACI: R-Responsible, A- Accountable, C- Consulted, I-Informed)

Authentication Authentication is confirming the identity of user/entity making sure they are same as they are claiming.

Authorization Authorization refers to the means of determining the level of privilege or permission the user has and the resulting functionality the user can access within the application or service.

SOA Service Oriented Architecture (SOA) is a paradigm for building solutions with integrated reusable, stand-alone, modular IT assets (often referred as a service) each of which can be accessed separately and can be easily made part of another solution.

ESEC PennDOT Enterprise Application Security Solution.

SSO Single Sign-On (SSO) - Authenticating the user only once for multiple applications or services.

PGC Project Governance Committee PEMT Project Execution Management Team PET Project Execution Team CA SPS Group Role External Organization


Appendix H - of 68

External Individual user

CWOPA Users General Public PAP PEP PDP PIP


Appendix H - of 68

7 Requirements Traceability Detailed Requirements This section provides the requirements in detail under various functional areas. User Identity Store

Requirement Priority Design Section Reference

1.1 ESEC scope should include the following user communities • ESEC User

o Anonymous User o Registered User

Commonwealth internal employees & contractors • PennDOT Internal • Other State Agencies

PennDOT External Users • External Org Entity Users • Individual Users

External Organization: Any organization external to PennDOT (either government or private) which needs access to PennDOT applications & services and need multiple user accounts represent their entity or work for their entity. Example: Engineering Consultants and Contractor Business Partners who executes the PennDOT design contracts, Local Municipalities who process engineering agreements, Small Business Enterprises who apply for SBE certification, Advertisement Companies who apply for sign permits etc. Individual User: Any external individual user (either citizen or legal resident) who needs a single user account to access PennDOT applications and services. Example: A users who apply for HOP, BOL, OAD sign permits

Critical 4.1

1.2 ESEC should be able to authenticate employees and contractors from existing commonwealth’s CWOPA user store. MUSER and USERS stores are not in scope.

Critical 4.1 4.2.1.1

1.3 ESEC should be able to manage PennDOT External Users (both Individual Users & External Org Entity Users) profile and credentials in a PennDOT scope User Store.

Critical 4.1

1.4 ESEC should be able to add CWOPA users and PennDOT External Users to Groups and assign roles to all of them.

Critical 4.2.3.1

1.5 ESEC should have an ability to add new extended/custom attributes to all Registered Users as and when required.

Medium 4.2.3.1

1.6 ESEC should support existing application specific user stores. Optional 4.1 4.2.1.1 Will be implemened during legacy solution migration phase.


Appendix H - of 68


1.7 ESEC should meet the following OA/OIT guide lines for the user credentials in PennDOT user store.

RFD-SEC007A User IDs:

• Must be a maximum of ten characters. • Are unique. No two users can have the same user ID. • Are permanent. They may be disabled and retired, but they

are not to be reused. • Often take the form of the user’s first initial plus last name,

subject to the above restrictions. Variations are allowed, as required, to generate a unique user ID.

Passwords:

• Must be a minimum of eight characters. • Must be composed of at least three of the following types of

characters: o Uppercase letters (A, B, C, …) o Lowercase letters (a, b, c, …) o Numbers (0, 1, 2, 3, …, 9) o Special characters (#, other punctuation marks).

• May neither contain the user ID, nor any part of the user’s full name.

• May not reuse any of the last ten previously used passwords.

• Will expire after sixty days, requiring the creation of a new password.

• May not be changed more than once every fifteen (15) days.

User IDs are locked after five (5) consecutive failed log-on attempts and require administrator-level access to unlock them. In addition, once a user is logged in, the system will be locked after fifteen (15) minutes of inactivity, requiring the user to re-enter the password to regain access to the system. Agencies may apply more stringent requirements as dictated by their environment and their applications.

Note: Having a time out for the login at enterprise level (with SSO) may impact some applications (if they need longer timeout). Need to verify with Vendors how this can be addressed. What is the best practice in this case?

This policy does not prevent the use of default passwords--typically used for new user ID assignment or password reset situations--which are then immediately changed when the user next logs into the system. Service accounts are also permitted; however, their use should be strictly limited and their passwords changed on a regular basis.

Critical 4.2.3.4


Appendix H - of 68


1.8 ESEC should support nested groups For example:

ESEC will have the following global groups (P:\BBSS\ESEC\UML Model\content\_0.nX.tYL.yNE.eG.m.s.aPRC0493Q-content.html ) • CWOPA User

o PennDOT Internal User • PennDOT External User

o External Org Entity User o Individual User

ESEC will have a PennDOT<Application> User group for each application in ESEC scope.

e.g. ECMS System, BMS System, e-Permitting System etc., ESEC will have application specific sub groups under each PennDOT<Application> User group.

e.g. Did not have any current example. Planned for giving flexibility in future.

ESEC will have various < External Org Type> Groups under External Org group.

e.g. Bonding Agency, Bridge Consultant, Construction Contractor, Municipality etc.

ESEC will have a < External Org > User group for each External Organization. All these < External Org > User groups will be added to one or more < External Org Type> Groups.

e.g.

External Org

External Org Type Bonding Agency

Bridge Consultant

e-Permitting

ACME Utility Company

x x

AECOM Technical Services

x

Michael Baker

x x

Critical 4.2.3.5.1


Appendix H - of 68


1.9 ESEC should support hierarchical roles. For example:

ESEC will have the following global roles (P:\BBSS\ESEC\UML Model\content\_0.nX.tYL.yNE.eG.m.s.aPRC0493Q-content.html )

• ESEC System Admin • PennDOT Central User Identity Admin • PennDOT Central Access Policy Admin

ESEC will have a PennDOT <Application> Identity Admin role for each application in ESEC scope.

e.g. ECMS User Admin, e-Permitting User Admin ESEC will have a PennDOT <Application>Access Policy Admin role for each application in ESEC scope.

e.g. ECMS Access Policy Admin, e-Permitting Access Policy Admin

ESEC will have a < External Org > Identity Admin role for each external organization

e.g. ACME Utility Company-Admin, Michael Baker-Admin etc.,

Critical Default

1.10 ESEC should support a user to be a member of multiple groups Critical Default 1.11 ESEC should support a user can have multiple roles Critical Default 1.12 ESEC should enforce the following rule

• When a group is added to another parent group -only the child group’s membership will be added to the parent group but -the child group’s roles (if any) will NOT be available to the parent group members. -The parent group’s roles will be automatically assigned to child group’s members.

Critical 4.1.3.3

Access Policy Store


2.1 ESEC should provide ability to extend/modify the schema as and when required.

Medium Default. But Not recommended with AD

2.2 ESEC should have ability to have distinct policy store data for multiple environments, including development, pre-production and production

Medium Default.

2.3 ESEC should support both global polices as well as application level authorization policies

Critical 4.4.2.5

2.4 Deleted 2.5 ESEC should have ability to migrate selected policy store data from one

environment to another High 4.5.2


Appendix H - of 68

Administration

User Identity Administration Central Administration


3.1.1.1 ESEC should allow centralized user administration available thru secured internet web user interface. (IE Browser)

Critical 4.2.3.3

3.1.1.2 PennDOT internal users with PennDOT Central Identity Admin role should be able to create groups and the corresponding administrative roles For Example:

Various < External Org Type> Groups For each < External Org Type> Group…

Various < External Org Type Specific> Roles For each application…

PennDOT <Application> Group PennDOT <Application> Identity Admin Role PennDOT <Application>Access Policy Admin Role

For each external organization… < External Org > Group < External Org > Identity Admin Role

Critical 4.4.1.1

3.1.1.3 Ability to separate the group management (i.e. create/modify/delete group) and group membership management (i.e. add/remove users and groups) tasks into two different roles. For Example:

Group Lifecycle Admin Role

Membership Admin role

PennDOT Internal User, External Org User, Individual User

ESEC System Admin

PennDOT Central Identity Admin

PennDOT<Application> User

PennDOT Central Identity Admin

PennDOT <Application> Identity Admin

< External Org > User PennDOT Central Identity Admin

< External Org > Identity Admin

High Default.


Appendix H - of 68


3.1.1.4 PennDOT internal users with PennDOT Central Identity Admin role should be able to perform the following tasks for the PennDOT External User accounts (both External Org as well as Individual Users)

• Create • Modify Profile • Delete • Suspend/Lock/ Deactivate • Reactivate • Reset/Change password

Critical 4.4.1.1



3.1.2.1 ESEC should allow delegated user administration ( at the following two levels) available through secured internet web user interface. (IE Browser)

• External Org Level • Application Level

Critical 4.4.1.2

3.1.2.2 ESEC should support the following administrative tasks at External Org level. External Org User account Management.

For example. < External Org > Users with < External Org > Identity Admin role should be able to perform the following tasks for the < External Org > Users only for their organization.

• Create • Modify Profile • Delete • Suspend/Lock/Deactivate • Reactivate • Reset/Change password

Role assignment (only for user in their org) management for only the < External Org Type specific> roles that are related the < External Org Type> Groups for which their organization is a member.

For Example Let us say the ACME Utility Company is assigned with Bonding Agency and Consultant Type Groups. Bonding Agency Type has Bond Approver Role Consultant Type has Principal, Financial Officer Roles. Then the ACME Utility Company Admin can assign their company users with one or more of the Bond Approver, Principal, and Financial Officer roles.

Application Group Membership management and Role assignment (only for user in their org) management for which they are given permission by the Application Admins.

Critical 4.4.1.2.1


Appendix H - of 68


3.1.2.3 ESEC should support the following administrative tasks at Application level. Application specific Group & Group membership (for any ESEC User) management. Assign (Delegate) the Application Specific Groups’ Group Membership role to Selected External Org Admins. Application specific Role & Role assignment (for any ESEC User) management Assign (Delegate) the Application Specific Roles’ Role Assignment Role to Selected External Org Admins. Approving the following requests (for any ESEC User) for their application.

Request for application access Request for group membership Request a role assignment

Critical 4.4.1.2.2

Self-Service Administration


3.1.3.1 ESEC should allow self-service user administration available through secured internet web user interface (common to all applications/services in the ESEC scope). Browser compatibility (IE)

Critical 4.4.1.3

3.1.3.2 PennDOT External users (both External Org Entity Users and Individual Users) should be able to perform the following tasks.

• Self register in PennDOT user store.(This is not allowed for External Org Entity Users)

• Modify self profile • Reset Forgotten password

High 4.4.1.3.3 4.4.1.3.6 4.4.1.3.5

3.1.3.3 All registered users should be allowed to perform the following tasks • access to applications/services, • add self to groups • assign roles to self for which NO authorization/approval is needed.

High 4.4.1.3.1

3.1.3.4 All ESEC users (CWOPA, External Org Entity Users, and Individual Users) should be able to make the following requests where authorization/approval is needed.

• Sign-up for applications/services • Membership for a Group • Assignment of a Role

High 4.4.1.3.7

3.1.3.5 ESEC should support External Organizations to register their organization themselves (through as approval work-flow)

Medium 4.4.1.3.2

Access Policy Administration

Central Administration Requirement Priority Design Section

Reference 3.2.1.1 ESEC should allow central access policy administration available thru

secured internet web user interface. (IE) Critical 4.2.2.4


Appendix H - of 68


3.2.1.2 PennDOT internal users with PennDOT Central Access Admin role should be able to perform central/common configuration, access policy administration which are global (like the User Administration application) and not specific to any one PennDOT application.

High 4.4.2.5 4.4.2.5.1


Requirement Priority 3.2.2.1 ESEC should allow application specific access policy administration

available thru secured internet web user interface. (IE) High 4.2.2.4

3.2.2.2 PennDOT internal users with PennDOT <Application>Access Admin role

should be able perform configuration, access policy administration specific to their application/service resources.

Critical 4.4.2.5.2

3.2.2.3 Deleted

Work-Flow


3.3.1 ESEC should provide an ability to configure work-flows for various processes For example:

• Group management (To create/modify/delete the group ) • Group membership management ( To add a user/group to the

Group and/or remove a user/group from the group) • Role assignment ( To assign the Role to a user/group) • Access Policy Configuration • Request a Group membership (for self or for someone else) • Request a Role assignment (for self or for someone else) • Request change profile (for self) • Reset/change password (for self)

Critical 4.2.3.7 4.4.1.4

3.3.2 ESEC should notify (e.g. email) all concerned who are involved in the work-flow whenever an event occurs in the work-flow that needs their attention.

High 4.2.3.6 4.4.1.5

3.3.3 ESEC should notify all the concerned users whenever some selected admin task is performed on their profile.

High 4.2.3.6 4.4.1.5

Auditing/Logging


3.4.1 All the administrative transactions/activity should be logged with who/what/when/how details in an audit log from which reports can be run.

For example: User password changed User is added to or removed from a group Role is assigned to or removed from a user etc.,

Critical 4.6.1


Appendix H - of 68


3.4.2 All access attempts to various application resources/services should be logged with who/what/when details.

For example: Successful authentication events Failed authentication events Successful authorization events Failed authorization events

Critical 4.6.2

3.4.3 Audit Log data should follow some retention policy and should be archived at specified interval and purged at specified interval.

Critical 4.6.3

Authentication


4.1 ESEC should provide support for user authentication for all the following type applications/services (Java, .Net, Domino on both windows, Unix(Mac OSX), and zLinux OSs) against Users Stores referred in 1.1 requirement

• Web applications o Intranet o Internet (including mobile web applications)

• Web Services (both SOAP and REST)

Critical 4.4.2.1.1 4.4.2.1.2

4.2 ESEC should allow the applications to have their own login page with application specific branding and styles.

Medium 4.4.2.1.2

4.3 ESEC should have an ability to redirect the user to an application specific Login Page when user credentials are not present in the request for that application’s resource.

Medium 4.4.2.1.2

4.4 4.5 ESEC should provide the following Single Sign-On capabilities

• Ability to support single sign-on (SSO) whereby a user is logged in once and can be authenticated for all applications under the ESEC scope without being challenged for credentials each and every time.

• Windows Integrated Security. For intranet applications if user has logged in to network using their CWOPA id then they should be authenticated without being challenged for credentials.

Critical 4.4.2.2.6 4.4.2.2.2.1.1.

4.6 SSO across the web apps Optional 4.4.2.2.6 4.7 ESEC should provide privileged admins the capability to impersonate as

other users Medium 4.4.2.2.5

Authorization


5.1 All applications under ESEC scope should be able to determine the roles assigned to the logged in user and all the groups the user belongs.

Critical 4.4.2.3

5.2 Ability to configure access policies to group of resources as well as specific resources.

Critical 4.4.2.6


Appendix H - of 68


5.3 Deleted 5.4 Deleted

SOA


6.1 The solution should support the consuming applications from technology platforms like, Java, .Net, and Domino

High 4.3 5

6.2 ESEC should provide an option (in the form of a webservice) to develop customized client interfaces for the following.

• Authentication • Authorization (course grained only ) • Administration (user and/or policy)

Medium Solution supports. Not implemented in release one.

Reporting


7.1 ESEC should provide ability to generate and view various reports (either out of the box or through customization) against User Store and Policy Store and Audit Log data via secured internet web user interface. For example: General Reports

List of currently logged-in users List of sub groups and member users in a Group List of Roles assigned to a user/group List of groups along with administrator(s) information List of currently inactive users/locked accounts

Administration Audit Reports User Profile changes History

For a user during a time period By an administrator during a time period

Group Administration Event History (changes to groups and group membership)

For a group during a time period By a administrator during a time period

Role Administration Even History (changes to roles and role assignments0

For a role during a time period By a administrator during a time period

Access Policy Administration (changes to access policies) For a resource/service during a time period. By a administrator during a time period

Access/Intrusion related Event Reports

Access Event History

Medium 4.7


Appendix H - of 68


By accessor during a time period (what resources/services they accessed and when) By resource/service during a time period ( accessed by whom and when)

Failed Authentication/authorization event History (by accessor and by resource/service) Most active accessor ( who frequent log-in) Most frequently accessed resource/service Most inactive users ( who have not logged in since specified time period)

Others


8.1 The ability for consuming applications to leverage the solution to varying degrees, for example: authentication only, authentication & single sign-on, coarse-grained authorization or all the way down to fine-grained authorization.

Medium Default.

8.2 Anonymous users (general public (not registered users)) should have access to designated resources.

Medium 4.4.2.2.7

8.3 Administrative and audit log transactions could be made effective in real time to the extent possible.

Medium 4.6

appendix h - pa created and administered by oa in cwopa active directory using ibm’s security...

Documents