01SDK20271 03 ImplementSecurity

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 46

CA Service Desk Manager :

Administration 200

Implement Security
Module Objectives

After completing this module, you will be able to:


 Describe role-based security
 Identify the predefined roles installed with CA Service Desk
 Define the levels of CA Service Desk security
 Create access types
 Create contacts and groups
 Create data partitions

Module 3: Implement Security 2 of 72


Describe Role-based Security

 Access types and roles are the primary components you


use to control CA Service Desk security.
 The diagram shows an overview of how roles interrelate
with other system objects to provide role-based
security.
Role
• Data Partition
Tab
• Grant Level
• Function
Tab
Access
Access Type • Form Group
Tab
• Authentication
• Access Level
• WSP Role
• Data Partition
• Grant Level Tab
• Function
Access
• Form Group

Module 3: Implement Security 3 of 72


CA Service Desk User Authentication

 In most cases, the operating system authenticates user


access.
 If CA Service Desk is part of a Microsoft Active Directory
domain, Active Directory performs user authentication.
 Every user must be defined as a contact.
 ca_contact table
 Userid attribute of the contact must match the login id for
authentication
 Every contact should be associated with an access type,
which among other things, determines the authentication
method used for the contact
 Authorization defines what a user can do in CA Service
Desk.
 Roles define the capability and functionality for a user.

Module 3: Implement Security 4 of 72


Roles

 Roles are the primary system objects that control


CA Service Desk security and user interface navigation.
 Each role record defines a focused view of the system by
exposing only the functionality necessary for users to
perform the tasks typically assigned to their roles.
 A user’s default role determines the system view that is
presented on login.
 Users with multiple role assignments can switch from one role
to another to see different views of the system without
having to log out and log back in again.

Module 3: Implement Security 5 of 72


Predefined Roles and ITIL

 The 18 predefined roles are designed to align with ITIL


v3 best practices.
 This reduces the amount of site-specific customization
required to bring your IT organization into ITIL
compliance.
 For non-ITIL installations, not all predefined roles are
available.
 The default installation for CA Service Desk is ITIL.
However, a non-ITIL installation is available.

Module 3: Implement Security 6 of 72


0/4

Predefined Roles

End User Roles

Analyst Roles

Manager Roles

Administrator Roles

Module 3: Implement Security 7 of 72


1/4

End User Roles


Role Name Description

Customer Performs basic self-service tasks from


outside your organization
Employee (ITIL and non-ITIL) Performs basic
self-service tasks from inside your
organization

Module 3: Implement Security 8 of 72


2/4

Analyst Roles
Role Name Description

Customer Service Supports users external to your


Representative organization, most often customers
Knowledge Analyst Performs tasks within the knowledge
management life cycle process
Level 1 Analyst (ITIL and non-ITIL) Provides first-line
support within your organization
Level 2 Analyst Provides second-line support within your
organization, which requires more
advanced subject matter expertise
Vendor Analyst Supports a limited segment of your IT
environment from outside your
organization, such as vendor-specific
hardware

Module 3: Implement Security 9 of 72


3/4

Manager Roles
Role Name Description
Change Order (ITIL and non-ITIL) Manages the change order
Manager process, but typically not the analysts who work
on change order tickets
Customer Service Manages Customer Service Representatives and
Manager the external support process

Incident Manager (ITIL only) Manages the incident process, but


typically not the analysts who work on incident
tickets
Knowledge Manager Supervises Knowledge Analysts, knowledge
document reassignments and escalations, and
day-to-day knowledge administration
Problem Manager (ITIL only) Manages the problem process, but
typically not the analysts who work on problem
tickets
Service Desk (ITIL and non-ITIL) Handles escalations and
Manager supervises Level 1 Analysts; may also manage
overall service desk operations
Module 3: Implement Security 10 of 72
4/4

Administrator Roles
Role Name Description
Administrator Performs administrative tasks throughout your CA
Service Desk and Knowledge Tools implementation
Typically installs, configures, and integrates the
products
Knowledge Configures and monitors knowledge management
Management settings
Administrator
Service Desk (ITIL and non-ITIL) Performs administrative tasks on
Administrator data and processes, such as creating and updating
categories, contacts, service types, root causes, and
so on
System Performs administrative tasks related to your CA
Administrator Service Desk implementation, configuration and
adaptation, such as setting options, configuring
integrations, and modifying web forms
Tenant Performs multi-tenancy administrative tasks specific
Administrator to a particular tenant or supporting organization

Module 3: Implement Security 11 of 72


0/4

Components of Roles

Function Access

User Interface

Knowledge Access

Record-level Filters

Module 3: Implement Security 12 of 72


1/4

Function Access

 High-level CA Service Desk functional areas


 No access, View or Modify access
 Broad areas:
 Requests, Change Orders, Issues
 Inventory, Reference
 Notify
 Admin
 Security

Module 3: Implement Security 13 of 72


2/4

User Interface

 The Role determines:


 Basic web interface: Analyst, Employee
 Tabs
 Go Resources
 Menus
 Help Files
 Form Groups

Module 3: Implement Security 14 of 72


3/4

Knowledge Access

 The Role determines whether the user can:


 Create, edit, delete knowledge documents
 Create, edit, delete knowledge categories
 Modify or bypass the approval process
 Search for unpublished documents

Module 3: Implement Security 15 of 72


4/4

Record-level Filters

 The Role determines which records in select tables that


the user can create, view, update or delete
 Data Partition

Module 3: Implement Security 16 of 72


Define the Levels of CA Service Desk Security

 You can assign roles:


 To an access type
 Directly to a user’s contact record

Module 3: Implement Security 17 of 72


Role Records
 Each role record must be configured with these
components:
 One form group
 One user interface type
 Function access settings
 One or more tabs
 One help set
 One of these optional components can also contribute
to the definition of each role:
 One menu tree
 One scoreboard
 One menu bar
 One tool bar
 One data partition
 Knowledge Management access
 One or more report web forms

Module 3: Implement Security 18 of 72


Function Access

 You can set function access levels for eight CA Service


Desk components.
 The first four components are:
 Requests
 Change Orders
 Issues
 Inventory

Module 3: Implement Security 19 of 72


Function Access Continued

 You can set function access levels for eight CA Service


Desk components.
 The next four components are:
 Reference Data
 Notify
 Admin
 Security

Module 3: Implement Security 20 of 72


Function Access Continued

 Function access settings vary according to role.

Administrators View and modify virtually anything in the


system

Customers Least access in the predefined roles


 Create and edit issues
 View assets and reference data
 No access to request, incident, problem
and change order tickets
 No access to notification, administration,
and security features

Module 3: Implement Security 21 of 72


Create Access Types

 Each user’s access type controls the following aspects of


system behavior:
 How CA Service Desk performs web authentication when
the user logs in
 The user’s access level
 Whether the user can modify web forms or the database
schema using WSP
 Which roles are available to the user

Module 3: Implement Security 22 of 72


0/9

Role Access Types

Administration

Customer

Employee

IT Staff

Knowledge Management

Process Management

Service Desk Management

Service Desk Staff

Vendor Staff
Module 3: Implement Security 23 of 72
1/9

Administration Access Type


 Provides the highest level of security access to all key administration roles
 Used during implementation as well as ongoing administration
 Linked roles:
 Administrator (default)
 Employee
 Level 1 Analyst
 Level 2 Analyst
 Knowledge Analyst
 Knowledge Manager
 Service Desk Administrator
 System Administrator
 Tenant Administrator

Module 3: Implement Security 24 of 72


2/9

Customer Access Type

 Provides highly restricted access to external customers


who use the self-service view
 Linked roles:
 Customer

Module 3: Implement Security 25 of 72


3/9

Employee Access Type

 Provides highly restricted access to internal employees


who use the self-service view
 Linked roles:
 Employee

Module 3: Implement Security 26 of 72


4/9

IT Staff Access Type


 Provides analyst-oriented access to users who work within your IT organization but are not actual members of the support team
 Linked roles:
 Employee
 Level 2 Analyst (default)

Module 3: Implement Security 27 of 72


5/9

Knowledge Management Access Type


 Provides administrative access tailored to users who administer Knowledge Tools features
 Linked roles:
 Employee
 Knowledge Analyst
 Knowledge Management Administrator (default)
 Knowledge Manager
 Level 2 Analyst
 Tenant Administrator

Module 3: Implement Security 28 of 72


6/9

Process Management Access Type


 Provides access tailored to users who perform key process management roles
 Linked roles:
 Change Order Manager
 Employee
 Incident Manager (default)
 Level 2 Analyst
 Problem Manager
 Service Desk Manager

Module 3: Implement Security 29 of 72


7/9

Service Desk Management Access Type


 Provides access tailored to users who manage IT support or external customer support functions
 Typically, these are frontline support supervisors.
 Linked roles:
 Customer Service Manager
 Employee
 Level 1 Analyst
 Level 2 Analyst
 Service Desk Manager (default)

Module 3: Implement Security 30 of 72


8/9

Service Desk Staff Access Type


 Provides access tailored to users who perform frontline support tasks
 Linked roles:
 Customer Service Representative
 Employee
 Level 1 Analyst (default)
 Level 2 Analyst

Module 3: Implement Security 31 of 72


9/9

Vendor Staff Access Type


 Provides highly restricted access to external vendors, who work only on items directly related to their product (for example, a particular make of hardware)
 Linked roles:
 Vendor Analyst

Module 3: Implement Security 32 of 72


Lab Exercise

 In the following lab exercise, you will:


 Create a role and an access type
See lab 3-1 Create a Role and an Access Type.
 Test access types
See lab 3-2 Test the Access Type.

Module 3: Implement Security 33 of 72


Create Contacts and Groups

 An important part of establishing a working service desk


is defining the users who will access it.
 In CA Service Desk, users are known as contacts.

Module 3: Implement Security 34 of 72


Contact Definitions

 Everyone who uses CA Service Desk must be defined


as a contact.
 A user’s contact record defines the user information that
the system needs.
 The next screen shows the basic content of each user
information field in the contact record.
 These are the fields in a user’s contact record:
 Basic Identification
 Login
 Security
 Service Type
 Automatic Assignment
 How to Send Users Notification Messages
 Groups to Which a User Belongs

Module 3: Implement Security 35 of 72


Contact Definitions Continued

 Fields in a user’s contact information include:


Information Field Defines
Basic Identification The name of the user and the
contact type
Login The system login ID for the user
In some cases, a PIN field to
use as a password at login
Security The access type that is assigned
in a contact record or a default
access type

Module 3: Implement Security 36 of 72


Contact Definitions Continued

 Fields in a user’s contact information include:


Information Field Defines
Service Type The level of service a user
receives
Automatic Assignment Information such as work shift
and availability

Module 3: Implement Security 37 of 72


Contact Definitions Continued

 Fields in a user’s contact information include:


Information Field Defines
How to Send Users Notification information for a
Notification Messages contact, including email
addresses, telephone numbers,
and the notification method and
relevant work shifts
Groups to Which a Membership of groups that
User Belongs represent specific areas of
responsibility within a service
desk

Module 3: Implement Security 38 of 72


Groups

 A group is a collection of contacts that share a


common area of responsibility.
 Level 1 Support Group
 Desktop Support Group
 Groups are implemented using the predefined group
contact type, so groups are just a special kind of
contact.
 A group has the same basic information as a contact.
 Groups are one of the keys to automatically assigning
requests.

Module 3: Implement Security 39 of 72


Lab Exercise

 In the following lab exercise, you will:


 Create a contact and a group and add a contact to a
group
See lab 3-3 Create a Contact and a Group and Add a
Contact to a Group.

Module 3: Implement Security 40 of 72


Create Data Partitions

 Data partitions implement Record-Level security in CA


Service Desk.
 Restrict access to some records in DBI tables based on
the values in certain fields of those records.

Analysts assigned to
CA Service Desk partition B see only the
incidents in partition B of
Scoreboard CA Service Desk. The
same is true for other
partitions.

A B

Module 3: Implement Security 41 of 72


Data Partition Components

 Controlled tables
 30 CA Service Desk tables available for data partitions
 Determine what table or object is being filtered
 Examples include the tables Call_Req, ca_contact
 Data partition type
 Six types of data partitions, explained in the following
pages
 Data partition constraint test
 SQL-like WHERE clause
 Defines the filer
 Uses object layer attribute information
 Defines what records are allowed under the data partition

Module 3: Implement Security 42 of 72


Data Partition Types

 The six constraint types are:


Constraint Pass the Test Fail the Test
Type
View The records can be seen. The records cannot be
seen.
Pre-Update The record can be opened in The record cannot be
edit mode. opened in edit mode.

Update Changes to the record can be Changes to the record


successfully saved. cannot be saved.
Create The record can be created. The record cannot be
created.
Delete The record can be deleted. The record cannot be
deleted.
Defaults The values populate the The values do not
fields. populate the fields.

Module 3: Implement Security 43 of 72


Constraint Types
 Constraint types are not permissions.
 Think of constraint types as a boundary around records.
If users who are subject to the data partition pass the
test, they can do what the constraint type specifies in
that boundary.
 To achieve the level of security you need, you often
need more than one constraint for the same table with a
different constraint type.
 Contacts can be assigned to only one data partition at a
time, so constraints must be in that one data partition.

View
The user cannot see Constraint The user can see
anything here. Type incidents and make
The user can see changes to them.
incidents but cannot
make changes to
Pre-Update Constraint Type
them.

Module 3: Implement Security 44 of 72


Constraint Tests
 Because CA Service Desk security is handled at the
object layer, the syntax of the constraint test uses
object attribute values.
 To constrain users from Organization A so they can see
only other contacts from Organization A, specify:
organization.name = ‘A’

 The Object Manager will convert this object-level query


into a DBI-level SQL WHERE clause that mentions the
table and field names:
Ca_contact.organization_uuid = ca_organization.id AND
ca._organization.org_name = ‘A’ OUTER_JOIN ca_contact.id = usp_contact.id

 This SQL query will then be assigned to a Database


Agent to query the MDB.

Module 3: Implement Security 45 of 72


Constraint Tests Continued

 You can make a query more useful by widening ‫ يتسع‬its


application. For example, instead of constraining
someone from Organization A, the query could become:
People can see other contacts only from the same Organization

 To specify the person who is subject to this Data


Partition, use @root:
organization = @root.organization

 This query works regardless of the particular


organization involved.

Module 3: Implement Security 46 of 72

You might also like