Click here to load reader
Upload
phamphuc
View
219
Download
2
Embed Size (px)
Citation preview
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
CSMA Security Guidelines
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 Security Guidelines
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 Security Guidelines
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 Security Guidelines
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:
Continued on next page
CSMA Security Guidelines
CSMA OLTP Responsibilities, continued
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.
CSMA Security Guidelines
CSMA OLTP Responsibilities, continued
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.
CSMA Security Guidelines
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.
Continued on next page
CSMA Security Guidelines
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.
CSMA Security Guidelines
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:
CSMA Security Guidelines
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.
Continued on next page
CSMA Security Guidelines
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.
Continued on next page
page 11 of 15
CSMA Security Guidelines
Value Ranges Assigned to CSMA Responsibilities, continued
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
page 12 of 15
CSMA Security Guidelines
Value Ranges Assigned to CSMA Responsibilities, continued
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.
CSMA Security Guidelines
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.
Continued on next page
CSMA Security Guidelines
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].
CSMA Security Guidelines
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 )
CSMA Security Guidelines
page 15 of 15
Oracle Responsibility Naming Conventions Examples
GLHRVD^GL^CADM^55632^BIE
HRVD^GL^CADM^S5563^BIE
BUDHRVD^BUD^CADM^55630^IE-S
HRVD^BUD^CADM^M5630^IE-S
ARHRVD^AR^CADM^M5563^R^INV
HRVD^AR^CADM^M5563^R^COL
HDWHDW^CADM^O55632^BIE^PS
HDW^CADM^OM5563,F414510^BIE^PSH
HDW^CADM^OS5563,R65231^IE-S^SH
HCOM/WVR CADM^610^55672
CSMA HRVD^CSMA^CADM^VPF^Req
HDW-CSMA
HDW-CSMA^HMS^ALL^OFASR^C