CSMA Security Guidelines - Harvard University · Web viewSince CSMA uses Oracle forms,...

CSMA Security Guidelines

Table of Contents

This document contains the following topics:

Topic See PageOverview 2CSMA Users 3CSMA OLTP Responsibilities 4HDW Responsibilities for CSMA Users 7Value Ranges Assigned to CSMA Responsibilities 9Making Changes to CSMA Security 12Appendix A: Oracle Responsibility Naming Conventions 14


Overview

page 2 of 15

Introduction Since CSMA uses Oracle forms, reports, menus, and functions, CSMA security is based on the same Oracle responsibility structures used by the other Harvard Oracle financial applications (General Ledger, Accounts Payable and Receivable and Cash Management) and by Harvard’s custom data warehouse (HDW).

How CSMAsecurity works

CSMA security controls user access to the application in the following ways:

Users are limited to certain CSMA application screens, forms, and actions by role (approver, requestor, or system administrator).

Users are limited to certain actions based on their role. For example, only users from Financial Accounting and Repoting (FAR) are able to submit requests to add, modify designated attributes, disable, or re-enable activity values in the Construction in Progress (CIP) range.

Within their role, users may be limited to certain segment types (ORG, FUND, ACTIVITY, SUBACTIVITY, or ROOT). Within these segment types, users may be limited by range of values to which they have been granted access.

Reports run out of the OLTP system are limited according to the segment types and range of values permitted by the user’s role.

Additional security measures

Additional security controls user access to custom CSMA reports in the HDW as follows:

Security is enforced only on selected reports that reference CSMA request attributes other than the value, description, and current CSMA status. Security in these reports is limited according to the segment types and range of values permitted by the user’s reporting responsibility.

HDW reports (developed or enhanced for CSMA) that do not reference CSMA request information, or that reference only the value, description, or current CMSA status, have been made available to any user with an active HDW reporting responsibility.


CSMA Users

page 3 of 15

User IDs and passwords

Unlike the current CoA Maintenance Web Request system, CoA authorized requestors and approvers will access the CSMA forms and functions using the same user ID (their Harvard ID number) and password that they use to access the Oracle Applications.

CSMA will appear as a responsibility (or responsibilities, depending on the user) that the user can select from a list on their Oracle personal homepage.

E-mail addresses In order for CSMA users to receive e-mail copies of notifications1, each user must

have a valid e-mail address associated with their employee record in the Oracle employee table.

Client Services will make sure an e-mail address is entered when a CSMA user is set up. Users should notify Client Services immediately (via e-mail to [email protected]) if their e-mail address changes to ensure uninterrupted receipt of CSMA messages.

1 Only designated notifications generate an e-mail copy; please refer to the CSMA User Guide for details on which ones do so.


CSMA OLTP Responsibilities

page 4 of 15

Introduction Harvard custom CSMA responsibilities will control the CSMA forms, functions, and reports that may be accessed by a CSMA user, as well as the segment types and ranges of values from which they may submit requests.

Oracle responsibility naming convention

Please refer to the Oracle Responsibilities Naming Convention matrix on pages 14-15 of this document for an overview of all Oracle naming conventions.

Example of Oracle naming convention

The names for Harvard’s custom Oracle General Ledger Responsibilities are constructed as follows:

Continued on next page


CSMA OLTP Responsibilities, continued

page 5 of 15

CSMAresponsibility naming convention

CSMA responsibility names will be constructed along similar lines, with two major differences:

1. Because CSMA responsibilities control access to ORG, OBJECT2, FUND, ACTIVITY, and ROOT segment values (SUBACTIVITY access is derived from the parent value), the fourth section above (in our example, M4531) will reflect any segment or range limitations over and above the standard OBJECT segment restriction.

2. Since object code restrictions are standard for all CSMA tub users, the fifth segment will be used as an indication of the menu assigned to the responsibility. All tub authorized requestors will be assigned a standard requestor menu, which includes the ability to initiate requests. Approvers will be assigned a menu that does not allow access to the request submission functions.

Example of CSMA OLTPnaming convention

CSMA OLTP naming conventions for tub authorized requestors will appear as follows:




page 6 of 15

2 Only Client Services will have access to submit OBJECT code requests at CSMA go-live; therefore, all tub AR responsibilities will be set up to exclude this segment.



page 7 of 15

Responsibility profiles

To control user access and to direct requests to the background engines that route notifications, each CSMA responsibility will be assigned a profile “attribute.” These attributes will specifically designate certain responsibilities for allowed actions as follows:

1. FAR – Only users from Financial Accounting and Reporting will be assigned this profile, which will grant them sole access to add, update designated attributes, and disable values in the CIP activity ranges.

2. OSR – Only the GMAS feed will be assigned this profile, which will grant them sole access to add, update, and disable transactional child values in the sponsored fund, activity, and subactivity ranges.

Responsibility profile considerations

All tub authorized requestor responsibilities will be assigned the profile setting “AR” and CSMA approvers will be assigned their own code as appropriate to distinguish them from the others.

Please note: While the profile setting will prevent tub Authorized Requestors from initiating chart requests for values in the ranges noted, it will not prevent users with other profile settings from viewing or reporting on requests submitted by the OFAA or OSR-profiled responsibilities, as long as the values fall within the ranges of values allowed by their AR responsibility.


HDW Responsibilities for CSMA Users

page 8 of 15

Introduction Harvard custom HDW responsibilities for CSMA users will control the reports that may be accessed and executed by a CSMA user, as well as the segment types and ranges of values on which they may report.

HDW naming convention

Naming convention for HDW CSMAusers

The names for Harvard’s custom Oracle Data Warehouse (HDW) responsibilities are constructed as follows:

HDW responsibility names for CSMA users will be constructed along similar lines with two major differences:

1. The string “HDW-CSMA” identifies all responsibilities that contain CSMA- specific reports.

2. Because HDW CSMA responsibilities secure access to org, object3, fund,activity, and root segment values (subactivity access is derived from the parent value), the third section above will reflect any segment or range limitations over and above the standard object segment restriction.

3. Since object code restrictions are standard for all CSMA tub users, the fourth section has been appropriated to indicate the segments that may be reported on using the responsibility.



HDW Responsibilities for CSMA Users

page 9 of 15

3 Only Client Services will be allowed to submit object code requests at CSMA go-live; therefore, all tub AR responsibilities will be set up to exclude this segment.


HDW Responsibilities for CSMA Users, continued

page 10 of 15

Example of HDW CSMAnaming convention

The HDW CSMA naming convention for tub authorized requestors will appear as follows:


Value Ranges Assigned to CSMA Responsibilities

page 11 of 15

Introduction CSMA uses the same flexfield security rule (FSR) functionality employed by Harvard’s other Oracle financial applications to secure the CoA segments and ranges of segment values that may be submitted or reported upon by CSMA users.

CSMA flexfield security rules

Each CSMA responsibility will be assigned five flexfield security rules, one for each CSMA-independent segment type (org, object, fund, activity, and root). All tub authorized requestor responsibilities will be assigned an OBJECT FSR that excludes all values in the object segment ranges. The other segment restrictions will be determined by the range of values to be allowed by an individual CSMA Tub Authorized Requestor responsibility.

Assigned ranges across responsibilities

In order to accommodate CSMA back-end processes that forward notifications to tub ARs when a request is initiated by an approver (RSO or OFAA) against a value in that tub AR’s range, each CSMA FSR assigned to a CSMA Tub Authorized Requestor responsibility must represent a unique range of values that has not been assigned to any other CSMA AR responsibility.



Value Ranges Assigned to CSMA Responsibilities, continued

page 10 of 15

Tub Authorized Requestor responsibilities example

Suppose a tub has the following two authorized requestors:

User A : can only request faculty root values for that tub

User B: can request a value from any tub-owned segment or range including faculty root values.

The CSMA Tub Authorized Requestor responsibilities for that tub would be set up as follows:

Responsibility Segment FSRs Assigned Segment Ranges Allowed by FSR

HRVD^CSMA^TUB^FacRoot^Req

ORG OBJECT FUND ACTIVITY ROOT

None None None NoneOnly faculty roots

HRVD^CSMA^TUB^AllNoFacRoot^Req

ORG OBJECT FUND ACTIVITY ROOT

Tub org range NoneTub fund ranges Tub activity rangesBldg roots and parents

User A would only be assigned one CSMA responsibility:

HRVD^CSMA^TUB^FacRoot^Req

User B, on the other hand, would be assigned two responsibilities:

HRVD^CSMA^TUB^FacRoot^Req andHRVD^CSMA^TUB^AllNoFacRoot^Req

And User B would need to select the appropriate responsibility depending on the value for which they were going to submit a request.


of 15



Parent ranges Appropriate ranges of parent values, derived from the child ranges, will be assigned to CSMA responsibilities via the segment FSRs. As with the child values, parent ranges must be uniquely identified with a single CSMA Tub Authorized Requestor responsibility.

In addition to the standard financial parent ranges (super, mega, giga, tera)4, each tub has been assigned a range of allocation parents5. While relatively few tubs have received approval from General Accounting to create and run the Oracle standard mass allocations that would use allocation parents, ranges of these values for each segment except tub, object, and subactivity have been assigned to each tub in anticipation of that need.

FSR naming convention

CSMA-associated flexfield security rules will adhere to the following naming convention:

4 The mega, giga, and tera ranges will only be set up for the org segment. Financial parents for the fund, activity, and root segments only go as high as the super-parent level.

5 Harvard has designated a small subset of parent values for use with certain mass allocation functions in the General Ledger. These parent values, which begin with the letter “A,” are not used, as in the financial parent structure, as part of a hierarchical roll-up: instead, they are used to identify and group individual values that participate in specific mass allocations. The “child” values reporting to the Allocation parents

of 15



do not necessarily form part of a contiguous range of values, and in fact may have very little in common with each other, other than the fact that they participate in the same mass allocation.


Making Changes to CSMA Security

page 13 of 15

Introduction The primary tub authorized requestor may submit changes to Users, Responsibilities, and Ranges of Values, as follows.

Making user changes

For existing Oracle users: To add or delete a CSMA responsibility for an existing Oracle user, the primary Tub Authorized Requestor should email a completed Authorized Requestor Request form to [email protected].

For new Oracle users: To add a new Authorized Requestor who does not yet have an Oracle user ID, please email the completed Authorized Requestor Request form as above and note on it the date on which the User Security form that established the employee as an Oracle user was sent to Client Services ([email protected]).

Changing user responsibilities

Because CSMA responsibilities are based on the organization of tub Authorized Requestors and the ranges of tub values assigned to them, most changes to CSMA responsibilities will imply changes to these structures. Therefore, the best way to communicate these changes is via the Authorized Requestor Request form. Client Services will evaluate the changes you have proposed on that form and will contact you to confirm the CSMA security changes that will be necessary to implement your request.


mailto:[email protected]



Making Changes to CSMA Security, continued

page 14 of 15

Changing ranges of values

Moving tub ranges between CSMA responsibilities:As above, changing ranges assigned to your tub’s CSMA responsibilities implies changes to the structure and range assignments for your Authorized Requestors. These changes should be communicated to Client Services via the Authorized Requestor Request form.

Adding new ranges:Ranges of org, fund, activity, and root values were assigned to each tub during the implementation of the Oracle financial systems. These ranges are reflected in more system areas than just CSMA FSRs and validation tables. They are stored in cross- validation rules, parent hierarchies, transactional and reporting security, and elsewhere throughout the Oracle systems. Therefore, changes to these range assignments must be evaluated for impact to these various areas on a case-by-case basis.

Because of the individual nature of these changes, Client Services has not developed a formal request process for adding new ranges; rather, the primary Tub Authorized Requestor should initiate discussions by forwarding details on the proposed new range (including the segment, beginning and ending values for the range, and a brief description of the reason for the request) to Client Services at [email protected].



Appendix A: Oracle Responsibility Naming Conventions

page 14 of 15

Oracle Responsibility Naming Conventions

Application

Custom

Application

Tub Segment(s) or CSMA Range(s)

Obj Code or CSMA

Segment

Other

GL HRVD GL Tub Name Org(s) or Parent Org Value

Obj Code

BUD HRVD BUD Tub Name Org(s) or Parent Org Value

Obj Code

AR HRVD AR Tub Name Org(s) or Parent Org Value

Obj Code Role (INV or COL)

HDW HDW Tub NameSegment

Identifier(s) (Org, Fund, Act,

Root)+

Obj Code Access Flag(s)

HCOM / WVR

Tub Name^Number

ORG(s) or Parent Org Value

CSMA HRVD CSMA Tub Name CSMA Range(s) Role (Req or Appr)

HDW-CSMA

HDW-CSMA Tub Name CSMA Range(s)CSMA

Segment Identifier(s) (Org, Fund, Act, SAct,

Access Flag ( C )


page 15 of 15

Oracle Responsibility Naming Conventions Examples

GLHRVD^GL^CADM^55632^BIE

HRVD^GL^CADM^S5563^BIE

BUDHRVD^BUD^CADM^55630ÎE-S

HRVD^BUD^CADM^M5630ÎE-S

ARHRVDÂR^CADM^M5563^RÎNV

HRVDÂR^CADM^M5563^R^COL

HDWHDW^CADMÔ55632^BIE^PS

HDW^CADMÔM5563,F414510^BIE^PSH

HDW^CADMÔS5563,R65231ÎE-S^SH

HCOM/WVR CADM^610^55672

CSMA HRVD^CSMA^CADM^VPF^Req

HDW-CSMA

HDW-CSMA^HMSÂLLÔFASR^C

CSMA Security Guidelines - Harvard University · Web viewSince CSMA uses Oracle forms,...

Documents

Transcript of CSMA Security Guidelines - Harvard University · Web viewSince CSMA uses Oracle forms,...