E5 Security Implementation Guide
Transcript of E5 Security Implementation Guide
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 1/30
CONFIDENTIAL
141 Portland Street Cambridge, MA 02139 617.452.0400 www.sct.com
Exeter Student Suite 5.0
Security Implementation Guide
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 2/30
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 3/30
CONFIDENTIAL
141 Portland Street Cambridge, MA 02139 617.452.0400 www.sct.com
COPYRIGHT
Copyright © 2001-2002 Systems & Computer Technology Corporation (“SCT”). All rights reserved.
Information in this document is subject to change without notice and does not represent a commitment on
the part of Systems & Computer Technology Corporation (“SCT”). The software and database described in
this document are furnished under the agreement of non-disclosure. No part of this guide may be
reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying,
recording, or information storage and retrieval systems, for any purpose other than the purchaser’s personal
use, without the express and written permission of Systems & Computer Technology Corporation (“SCT”).
TRADEMARKS
Exeter Student Suite®, Exeter Student Marketing System®, Exeter Student Service System®, Exeter
Student Housing System®, Exeter Career Management System®, Exeter Alumni Contact System®, Exeter Student Aid System®, Exeter Student Billing System™, Exeter Student Web System™, and Exeter Course
Bidding System™ are trademarks or registered trademarks of Systems & Computer Technology
Corporation (“SCT”) in the U.S.A.
Microsoft and Windows are registered trademarks of Microsoft Corporation.
ORACLE, SQL*Forms, SQL*Loader, SQL*Report, and SQL*Report Writer are registered trademarks of
Oracle Corporation.
Oracle Applications, ORACLE8, Oracle Application Object Library, PL/SQL are trademarks of Oracle
Corporation.
Other brands and their products are trademarks or registered trademarks of their respective holders and
should be noted as such.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 4/30
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 5/30
Contents i
© 2001-2002 SCT ** CONFIDENTIAL **
Contents
INTRODUCTION............................................................................................................................. 1
EXETER STUDENT SUITE SECURITY MODEL ........................................................................... 2
Key Terms and Concepts......................................................................................................................... 2
Terms...................................................................................................................................................... 2
What Does the Security Framework Do? ............................................................................................... 3
How Does the Security Framework Function?....................................................................................... 4
What are the Basic Considerations to Security Configuration?........ ........... .......... ........... ........... .......... . 5
User Access to Product Features............................................................................................................. 6
Data Domains and Zones......................................................................................................................... 9
Data Domains ......................................................................................................................................... 9
Zones.................................................................................................................................................... 12
Interaction of Data Permissions and Screen Permissions..................................................................... 13
Using Zones and Data Domains........................................................................................................... 13
IMPLEMENTATION SCENARIOS................................................................................................ 15
SUMMARY.................................................................................................................................... 23
INDEX............................................................................................................................................ 24
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 6/30
ii Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
Table of Figures
Figure 1: Exeter Student Suite Security Model .............................................................................................. 4 Figure 2: Permission Interaction Table......................................................................................................... 13 Figure 3: Your University’s Organizational Diagram.................................................................................. 15
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 7/30
Introduction 1
© 2001-2002 SCT ** CONFIDENTIAL **
IntroductionThis document provides a description of the design, purpose, and usage of the security
model offered by Exeter Student Suite. Information regarding data domains and zones
will enable you to better configure installations of Exeter Student Suite.
In addition, client business practices and requirements have been collected from various
sources and included in this guide as implementation models. Each scenario presents the
most suitable method for meeting specific client requirements.
For further Exeter Student Suite configuration details, refer to the Implementer’s Guide
that is available with each application. These guides include additional information
regarding the implementation of security features.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 8/30
2 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
Exeter Student Suite Security Model
Key Terms and Concepts
This section includes basic information that will enable you to understand the key termsand concepts that drive Exeter Student Suite’s security model.
Terms
Application/Module: A basic unit of the suite corresponding to a broad functional area.
· CMN – Exeter Common: Data and functions across the suite
· SMS – Exeter Student Marketing System: Marketing, Recruiting, and
Admissions
· SAS – Exeter Student Aid System: Financial Aid
· SBS – Exeter Student Billing System: Accounts Receivable
· SSS – Exeter Student Service System: Courses and Registration
CRUD: A set of permissions that you can assign to a data domain or responsibility
domain. These permissions determine the level of access that users within a responsibility
are allowed on data belonging to the associated data domain.
· C: Create
· R: Read
· U: Update
· D: Delete
Database: The total collection of Exeter Student Suite tables, views, and procedures
within a single SQL Sever database. SQL Server can have multiple databases on a single
physical server.
Data Domain: A grouping of institution-defined records. Data domains are the primary
data partitioning method in Exeter Student Suite. Data domains exist independently of
modules. The organization of data domains in your system answers the question, Where
are the records that I can access?
FA: Full access permissions. You can assign this permission to a zone. Permissions
determine the level of access that users within a responsibility are allowed on data
belonging to the associated zone. Responsibilities that are mapped to a zone with full
access permissions can create, update, delete, and view data belonging to the zone.
Installation: An operationally separate, complete Exeter Student Suite data set stored
within the same database as other installations. Data from different installations is storedin shared tables in the database.
Menu: A group of menu items. Exeter Student Suite screens are associated with menus.
Responsibilities are mapped to menus.
Permissions: Permissions are assigned screens, data domains, and zones. The
combination of these three permissions determines the user’s level of access.
Responsibility: A role within the database. This set of privileges and stored procedures
enables a group of users to access data and perform actions.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 9/30
Exeter Student Suite Security Model 3
© 2001-2002 SCT ** CONFIDENTIAL **
Responsibility Domain: A group of access permissions on a set of data domains. The
organization of responsibility domains within your system answers the question: What
collection of records can I access?
User: Application end users or administrators. The database administrator is not typically
referred to as a user.
Zone: A grouping of institution-defined records. Zones are typically used to partition
data that crosses boundaries.
What Does the Security Framework Do?
Exeter Student Suite’s security model ensures that users can view and maintain only
appropriate data. For example, a user in the College of Humanities at your school should
not be able to view, update, or delete data pertaining to the College of Fine Arts. In
addition, the flexibility of the security model allows you to specify that data belonging to
the College of Humanities be visible to certain users within the Fine Arts college, if
necessary.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 10/30
4 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
How Does the Security Framework Function?
Two levels of security comprise the Exeter Student Suite security framework. The
authentication level of security ensures that individuals who access the system are valid
users. The individual’s login and password provide the criteria by which authentication is
granted. Only users with a valid login and password are granted access to the system.
Authorization, the second level of the security framework, follows the user authentication
process. The authorization process determines user access to application features and user
access to data. Authorization includes an evaluation of responsibility permissions, data
domain permissions, and zone permissions. Responsibility permissions determine user
access to Exeter Student Suite menus and screens. Zone permissions and data domain
permissions determine user access to specific data within your system.
Figure 1: Exeter Student Suite Security Model
For example, Professor Brown has been assigned to teach Math 410 next fall, and wants
to view the grades of two Math 400 students who will be proceeding to her course. The
professor asks a member of the math department administrative staff to gather this
information. The administrative user logs in successfully with her login name and
password. The math department administrator can access grades for all students in the
Math department. She does not have access to grade data in departments outside of Math.
As a result, this user can view the Math 400 grades for John Smith and Andrea Moore,
Moore, Andrea - Grades
1. CHEM 206 Final A2. MATH 400 Final B
Smith, John - Grades 1. PHY 101 Final D2. MATH 400 Final B
The Exeter Student Suite Security Framework
· Authentication: Login and Password Is this a valid E5 user?
· Authorization of access to product features: Menu and ScreenPermissions
Does this user have access to student grade information?
· Authorization of access to data: Zones and Data Domains
Does this user have access to John Smith’s data?Does this user have access to Andrea Moore’s data?
User attempts to access student grades
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 11/30
Exeter Student Suite Security Model 5
© 2001-2002 SCT ** CONFIDENTIAL **
but not the Physics or Chemistry grades. This administrative user can view grade data,
but is not responsible for entering this information, and has not been assigned the
permissions required to modify or delete the existing grades.
As seen in this example, the carefully constructed intersection of responsibilities,
permissions, zones, and data domains enables you to grant specific levels of access to
data within your system.
What are the Basic Considerations to Security Configuration?
The steps listed below provide a basic overview of the considerations that you must take
into account while designing your school’s security system. These examples are not all-
inclusive, and you should not limit your considerations to the list below. The following
sections of this document elaborate upon these principles.
Before configuring your security model, identify the following:
· Your school’s organization: Who will be using Exeter Student Suite?
· Required product features: What Exeter Student Suite screens will system users
access?
· Data pockets: What are the distinct sets of data upon which users must operate?
· Business practices: What will Exeter Student Suite users be doing?
Use these criteria to configure your security system using logical groups of users,
responsibilities, menus, permissions, data domains, and zones.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 12/30
6 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
User Access to Product FeaturesEach Exeter Student Suite user must have access only to specific product features.
For example, a data entry operator in the Registrar’s office who enters student
enrollment data requires access only to this feature. This user should not have access
to features that allow the user to update or delete course offerings.Two types of users require access to Exeter Student Suite:
· Administrative Users: School administrative staff members who manage
student data and processes belong to this category. These users need to
view and maintain data pertaining to a specific set of students.
· Self-Service Users: Students, faculty, and advisors at the school belong to
this category. The data that is maintained in the system pertains to these
users. For example, a faculty member may want to view a class roster or a
perspective student can submit a request for application materials.
Each category of users will typically access different application interfaces from different
URLs.
Security for Self-Service Interfaces
Self-service interfaces enable end users such as registered students, prospective students,
and faculty to access personal data. Unlike Exeter Student Suite administrative interfaces,
this data pertains to the individual, not the school. For example, a student can view course
grades or GPA information via the self-service interface, and a faculty member can view
registration data for a class he or she is teaching.
Administrative users determine the self-service user’s level of data access.
Administrators can grant users access to any number of self-service responsibilities.
Self-service responsibilities are specific to self-service users. You can associate a
rule to the self-service responsibility that determines which entities in the system are
automatically assigned to the responsibility. This responsibility can be associated to
a menu. This menu is a collection of screens that the user can access. Zones and data
domains have no relevance to self-service users.
The security requirements of self-service interfaces are simple. Each user should be able
to view and maintain only his or her information. Each self-service user should have
access only to relevant data.
Security for Administrative User Interfaces
School administrative staff members that manage student data and processes belong to
this category. These users need to view and maintain data pertaining to a specific set of
students. The security requirements for administrative user interfaces are more complex
than the security requirements for self-service users. This document details the security
configuration needs and methodology for administrative users.
Each of the features in Exeter Student Suite is typically implemented as a menu item.Menu items are the links that appear to users in the left pane of the Web page. Users click
menu items to invoke screens. The screen is a Web page that is displayed on the main
area of the browser window. This screen might call other screens to provide additional
functionality. For example, Person Summary is a menu item located under the Person
menu. This menu item is associated with the Person Summary function. When users click
Person Summary, the Person Summary screen appears in the browser window. From this
screen, users can click links to access additional functions, such as Person Work History
and Person International Info.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 13/30
Exeter Student Suite Security Model 7
© 2001-2002 SCT ** CONFIDENTIAL **
In Exeter Student Suite, users can be given access to a set of menu items. The system
administrator determines access to menu items, based on the needs of the user. However,
if there are fifty data entry operators in the Registrar’s office, and each data entry
operator requires access to the same set of five menu items, individually associating each
user to each menu item becomes tedious.
Exeter Student Suite provides the responsibility feature to address this issue. A
responsibility is a role played by multiple application users. For example, in the scenarioabove, the system administrator could assign Data Entry Operator in Registrar’s Office
as a responsibility to the fifty data entry operators in this office. The system administrator
can configure a responsibility by this name, and associate a menu to this responsibility. A
menu is a set of menu items. Users are assigned responsibilities, and users who perform
multiple roles can be assigned more than one responsibility. Further, Exeter Student Suite
also enables you to easily configure the level of access a user is permitted for specific
screens.
Screen Permissions
The available screen level permissions are:
· E (Edit): If a screen is assigned edit permissions while associating a
responsibility to a menu, users with this responsibility are able to view, create,or update records when they access this screen. Deleting records on this screen
is not allowed.
For example, you assign the Person Addresses screen Edit permissions. You
associate the Person Addresses screen with the Person menu and then associate
the Data Entry Operator responsibility with the Person menu. The user assigned
to the Data Entry Operator responsibility has access to the Person menu and Edit
permissions on the Person Addresses screen. This user can view, create, and
update records on the Person Addresses screen. This user is not permitted to
delete records on this screen.
· D (Delete): If a screen is assigned delete permissions while associating a
responsibility to a menu, users with this responsibility are able to delete records
when they access this screen.
· A (Assign): Exeter Student Suite does not currently support Assign permissions.
Assign permissions are a future enhancement.
· ED: If a screen is assigned edit and delete permissions while associating a
responsibility to a menu, users with this responsibility are able to view, create,
update, and delete records when they access this screen.
· None: If a screen is assigned no permissions while associating a responsibility
to a menu, users with this responsibility are only able to view data when they
access this screen.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 14/30
8 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
System administrators specify the level of permission with which responsibilities are
mapped to each screen. The administrator can specify whether a responsibility has E, D,
ED, or None permissions on each of the available screens.
Using only screen permissions, a user with ED access on the Course Offerings screen
will be able to manipulate course-offering data belonging to all departments at the school.
This level of data access is not restrictive enough for the security requirements of many
schools. Zones and data domains are used to further control data access. These features of the security model are discussed in the following section.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 15/30
Exeter Student Suite Security Model 9
© 2001-2002 SCT ** CONFIDENTIAL **
Data Domains and ZonesIn any installation, multiple system users maintain the same sets of data. For example,
your school can maintain course data that is specific to each department, or your school
can maintain course data that is shared by multiple departments. In each case, more than
one user requires access to the course data.To accommodate multiple users, create logical groups in the system, and allow
responsibilities to access only a select set of these logical groups. For example, identify
each department as a different group, assign responsibilities to specific users, and
associate the responsibilities with access permissions to the departmental groups. Zones
and data domains are two components that are used to define these groups. All data in
your system belongs to at least one zone and one data domain.
Zones and data domains are configured at the installation level. These definitions apply to
all Exeter Student Suite modules in an installation. You cannot configure a different set
of zones and data domains for Exeter Student Marketing System and Exeter Student
Service System if both modules are part of the same installation. Zones and data domains
are configured at the time of installation. When configuring zones and data domains, you
must consider both the current and future needs of your school. While Exeter Student
Suite enables you to configure additional zones and data domains at any point, this can
become difficult if you want to modify the organizational structure of the security
framework. For example, if you configure your installation using data domains for each
department, it is simple to create an additional domain when your school adds a new
department to the academic program. However, if your school later decides to associate
departments with zones instead of domains, this process is incredibly difficult. Modifying
your school’s identification of zones and domains is not recommended.
Data Domains
A data domain is a set of data on which a particular user, or responsibility, is allowed to
perform operations. This is the core data security mechanism provided by Exeter Student
Suite. Only users with the appropriate responsibilityà
data domain permissions canaccess data within the domain.
In order to determine data domain configuration:
1. Identify pockets of data on which a distinct set of users must operate.
2. Classify these pockets as data domains.
Provide data domain access to responsibilities that are assigned to this set of users. For
example, your school wants all users in the College of Engineering to be able to view and
maintain only data pertaining to the College of Engineering and not the data pertaining to
any other college at your school. Classify the College of Engineering data pocket as the
Engineering data domain. Any data that belongs to this college is marked as belonging to
the Engineering data domain. Only users with permissions on this domain can access data
belonging to this domain. Users within the College of Engineering are assigned to
responsibilities that are mapped to this domain with the appropriate level of permissions.
You can assign any one or more of the following permissions to a responsibility à data
domain mapping:
· C (Create): When a responsibility is mapped to a data domain with create
permissions, users assigned to this responsibility can create data within the
mapped domain.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 16/30
10 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
· R (Read): When a responsibility is mapped to a data domain with Read
permissions, users assigned to this responsibility can view data within the
mapped domain.
· U (Update): When a responsibility is mapped to a data domain with update
permissions, users assigned to this responsibility can update data within the
mapped domain.
· D (Delete): When a responsibility is mapped to a data domain with delete
permissions, users assigned to this responsibility can delete data within the
mapped domain.
· A (Assign): Exeter Student Suite does not currently support this responsibility.
Each responsibility can be mapped to any number of data domains, with each mapping
assigned to different levels of access rights.
While most system users will need to access only a single data group, other
administrators may require access to all the school’s data. For example, the Provost of a
university may require access to all of the data belonging to individual colleges within the
university. In this scenario, you can assign a responsibility that has access to all data
domains configured in the installation.
During installation, one data domain is created and you are prompted for the name of this
data domain. For the purposes of this document, the first data domain that is created
during installation is referred to as First domain.
All responsibilities for this installation will automatically have Read access on First
domain. You can assign Create, Update, and Delete access on this domain to any
responsibility. You cannot remove Read access on this domain. Some data that is shipped
with Exeter Student Suite is automatically placed in this data domain. Data that are
shipped with the product, such as code types and profiles, are placed in this data domain.
All users should have a minimum of Read access on this data domain.
You must designate one data domain as Primary for each responsibility. The Primary
domain is the default domain for the responsibility. This should be the data domain on
which this responsibility primarily operates, and typically has CRUD rights.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 17/30
Exeter Student Suite Security Model 11
© 2001-2002 SCT ** CONFIDENTIAL **
You have the option to choose between a non-hierarchical data domain installation and a
no domain installation at the time of installation. You cannot change your selection at a
later time.
· No Domain: In this type of installation, your school chooses not to use any data
domains. Data partitioning is achieved only through the use of zones. All data in
the system resides in the First domain when you select the No Domain option.
· Non-Hierarchical Domain: In this type of installation, data domains are
configured and responsibilities are mapped to domains with CRUD access
levels.
* This document assumes a non-hierarchical installation unless otherwise specified.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 18/30
12 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
Zones
A zone defines a set of data on which a particular user or responsibility is allowed to
operate. Zones are typically used to segment data that crosses boundaries. In most cases,
anything that is achieved by using data domains can also be achieved using zones
A responsibility can be mapped to any number of zones, but the type of access rightsgranted to a responsibilityà zone mapping are different from that of a responsibilityà
data domain mapping:
· FA (Full Access): When a responsibility is mapped to a zone with full access
permissions, users assigned to this responsibility can create, update, delete, and
view data that belong to the mapped zone.
· V (View): When a responsibility is mapped to a zone with view permissions,
users assigned to this responsibility can only view data within the mapped zone.
Zones can be used to identify further data partitions that are required after establishing
data domains. For example, after identifying the College of Engineering as a data
domain, there is a requirement to allow some users in this college to view and maintain
data only for undergraduate students while other users in this college need to view and
maintain only graduate student information. You can use zones to achieve this data
partitioning. Define Undergraduate as one zone and Graduate as a second zone to further
partition data. In addition, you have the option to use these zones in conjunction with data
domains.
One zone is created by default with every installation. View rights are automatically
assigned to every responsibility that is created in this zone. For purposes of this
document, the first zone that is created during installation is referred to as First zone.
Some data that is shipped with Exeter Student Suite is automatically placed in this data
domain. For example, all system users require a minimum of View access on code type
and profile data.
One zone must be marked as the Primary zone for a responsibility. This should be the
zone on which this responsibility mostly operates, and typically has full access rights.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 19/30
Exeter Student Suite Security Model 13
© 2001-2002 SCT ** CONFIDENTIAL **
Interaction of Data Permissions and Screen Permissions
Screen level permission and data level permissions determine the user’s final level of
data access. The final permissions on data for the end-user are determined by both the
access that the user’s responsibility has on zones and data domains, and the screen level
permissions available. Users must have rights to carry out an operation on the zone, data
domain, and the screen in order to perform an operation. If the user does not have rights
to carry out an operation on any one zone, data domain, or screen levels, that operation is
not allowed.
The following table illustrates this interaction:
Data Permission Screen Permission
ZonePermission
Data DomainPermission
E D ED none
FA CRUD Can view, add andupdate data
Can view and delete data Can view, add, updateand delete data
Can view data
FA CRU Can view, add andupdate data
Can view data Can view, add andupdate data
Can view data
FA CRD Can view and addrecords
Can view and delete data Can view, add anddelete data
Can view data
FA RUD Can view and updatedata
Can view and delete data Can view, update anddelete data
Can view data
FA RD Can view data Can view and delete data Can view and deletedata
Can view data
FA RU Can view and updatedata
Can view data Can view and updatedata
Can view data
FA CR Can view and add data Can view data Can view and add data Can view data
FA R Can view data Can view data Can view data Can view data
FA none Screen viewable, butdata not viewable
Screen viewable, butdata not viewable
Screen viewable, butdata not viewable
Screen viewable, butdata not viewable
V Anypermission,
except“none”
Can view data Can view data Can view data Can view data
V None Screen viewable, but
data not viewable
Screen viewable, but
data not viewable
Screen viewable, but
data not viewable
Screen viewable, but
data not viewablenone Anypermission
Screen viewable, butdata not viewable
Screen viewable, butdata not viewable
Screen viewable, butdata not viewable
Screen viewable, butdata not viewable
Figure 2: Permission Interaction Table
Using Zones and Data Domains
Exeter Student Suite’s flexibility allows you to create logical groups using only data
domains, only zones, or both data domains and zones. The data domain-only or the zone-
only configuration is often suitable for installations with minimal security requirements.
As the requirements of the installation become more varied and complex, it becomes
cumbersome to achieve and maintain a security configuration using just one component
for partitioning data. More complex requirements often require the use of both zones anddata domains.
Four scenarios are provided in the Implementation Scenarios section, with the
recommended zone and data domain configurations. In these scenarios, the client needs
and requirements determine the optimal design and implementation of data domains and
zones. The solutions provided below represent only one possible solution to configuration
requirements. It is possible that the requirements from each of these scenarios can be met
with alternate security configurations.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 20/30
14 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
How to Identify Data Domains and Zones
Data domains and zones enable you to set the scope of information available to various
responsibilities. If a school has two admissions offices, one for undergraduate admissions
and one for graduate admissions, the scope of the undergraduate admissions office
includes all undergraduate applicants and related data. Graduate applicants and related
data are outside the scope of the undergraduate admissions office.
You must consider the organization of your school, and the roles played by individuals
and offices in your school, when identifying data domains and zones. For example, if a
school has a single admissions office, through which anyone who is interested in studying
at any college or department in the school must apply, then the scope of the admissions
office user encompasses all student data. Alternatively, if a school has one admissions
office for undergraduate applicants and one separate office for graduate applicants, then
the scope of one office is only undergraduate-related data while the scope of other is only
graduate-related data.
The example above identifies two different scopes. The roles that users play within a
school’s departmental structure determine these two scopes. In the example above, the
scope must also be addressed with regard to the Aid offices, Bursar offices, and Registrar
offices at the school.
Next, match the scopes and security pockets that you have defined with a configuration
of zones and data domains. You can use zones if users require read-only permissions, full
permissions, or no permissions on the data in a particular security pocket. If your school
requires a more granular level of access, you should configure security pockets using data
domains. For example, if a user can create, but not update data in a security pocket,
utilize the CRUD permissions using data domains.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 21/30
Implementation Scenarios 15
© 2001-2002 SCT ** CONFIDENTIAL **
Implementation ScenariosThe implementation scenarios listed below have been derived from actual client
requirements. Figure 3 illustrates the organizational structure of the fictional school, Your
University. While the specific requirements of users in Your University become
increasingly complex throughout the scenarios, the organizational structure of the schoolremains unchanged.
Figure 3: Your University’s Organizational Diagram
Scenario 1: Only Zones
Your University is comprised of the Law College, Business College, Medical College,
and Science College.
There is no single admissions office for all colleges at Your University. Each of the
colleges has their own admissions office, admission policies, and admission
requirements. One admissions office, and one group of users within the office,
administers both prospective graduate students and prospective undergraduate students.
The university level admissions office requires access to data from each of the college’s
admissions offices.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 22/30
16 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
With the exception of the Law College and the Business College, student financial aid
and student bursar accounts are handled independently by each of the colleges. The Law
College and the Business College share the same student financial aid office.
Each college has its own registrar’s office that handles all the academic activities of the
students who are pursuing a degree-major program at that college.
Your University identifies a set of users in each college’s admissions office that require
access to various Exeter Student Marketing System features in order to effectively
perform daily tasks. These users need to view data pertaining to their college, and should
not be able to view the data pertaining to other colleges. This scenario also applies to the
Aid, Bursar, and Registrar activities, with relation to SAS, SBS and SSS respectively.
All users require a specific level of data access. Some users, such as the school’s overall
admissions office, require the ability to view data across all of the colleges. Other users
must view a particular set of data, must be allowed to perform view, add, update, and
delete operations on a set of data, or must not be allowed to view a particular set of data.
Configuring Zones and Data Domains:
The data partitioning needs of Your University in this scenario are simple.
· Choose the No Domain installation option.
· Configure the following zones:
· Law
· Business
· Medical
· Science
· First zone is created by default during installation.
Five logical groups have been configured. All data belongs to one of these logical groups.
Data that must be available to all users, irrespective of the logical group to which they
have access, belongs to the First zone.
Configuring Responsibilities:
Create responsibilities based on the different sets of users and their access needs. The
responsibilities required for this security implementation at Your University include:
· Law Admissions Data Entry Operator . This responsibility is mapped to the
Prospect menus and the SMS Students menus. This responsibility is mapped,
with FA rights, to the Law zone. This responsibility is assigned to users in the
Law College’s Admissions office who accept applications from interested
students and enter the data into the system. Create similar responsibilities for use
by the other colleges’ Admissions, Bursar, Aid, and Registrar’s offices.
· Each college’s admissions office includes a user who sets up the admission
requirements and communication groups. Create a responsibility for such users
with access to these menus and the respective college zone. Grant FA permissions on this zone.
· Create a responsibility for the University-level Admissions office. Assign FA
rights on all the zones.
· For users in the Student Financial Aid office of the Law and Business Colleges,
create a responsibility that has FA rights on the Law and Business zones.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 23/30
Implementation Scenarios 17
© 2001-2002 SCT ** CONFIDENTIAL **
Scenario 2: Only Data Domains
In this scenario, Your University has exactly the requirements detailed in Scenario 1,
with the following exception:
The users at the University-level admissions office should be able to create prospects and
students in any of the individual colleges, but they are not allowed to update this
student/prospect data. As a result, a student can be created in the Law College, either bythe Law College’s Admissions office or the University-level Admissions office. Once
created, only the Law College can update and administer the student data.
Configuring Zones and Data Domains:
Data domains enable Your University to create logical groups that can be associated with
responsibilities. Unlike zones in the previous scenario, specific CRUD permissions can
be given to each responsibilityà data domain mapping in order to allow some users to
create and view, but not update, data.
· Select the Non-Hierarchical Domain installation option.
· Configure the following data domains:
· Law· Business
· Medical
· Science
· University
· First zone is created by default during installation
· First domain is created by default during installation
Six logical groups have been configured, and all data belongs to one of these logical
groups. Each group is a domain-zone combination. The logical groups are:
· Law - First
· Business - First
· Medical - First
· Science - First
· University - First
· First - First
Data that must be made available to all users, irrespective of the logical group to which
they have access, belongs to First domain and First zone.
Configuring Responsibilities:
Create responsibilities based on the different sets of users and their access needs. The
following responsibilities are required for Your University in this scenario:
· Law Admissions Data Entry Operator . This responsibility is mapped to the
Prospect menus and SMS Students menus. This responsibility is mapped to the
Law Domain, with CRUD rights. This is the responsibility that is assigned to
users in the Law College’s admissions office who accept applications from
interested parties and enter the data into the system. Similarly, create
responsibilities for use by the other Admissions, Aid, Accounts, and Registrar’s
offices.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 24/30
18 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
· Each college’s admissions office will have a user who establishes the admission
requirements and communication groups. Create a responsibility for such users
with access to these menus and the respective college data domain. Assign
CRUD rights on this data domain.
· Create a responsibility for the University-level admissions office that has CRUD
rights on the University data domain, and CR rights on all the other data
domains.
· For users in the Financial Aid office of the Law and Business Colleges, create a
responsibility that has CRUD rights on the Law data domain and CRUD rights
on the Business data domain.
Scenario3: Simple Zone and Data Domain
In this scenario, Your University has exactly the requirements detailed in Scenario 2,
with the following exception:
For every kind of user described in the previous scenario, there are two kinds of users in
this scenario. One user administers all undergraduate-related information and the other
user administers all graduate-related information. Instead of a single admissions office,
there is an Undergraduate Admissions office and a Graduate Admissions office.A distinct set of users administers Undergraduate admissions and another set of users
administers Graduate admissions. The same may or may not be the case for the Aid,
Bursar, and Registrar offices.
Configuring Zones and Data Domains:
You can meet this requirement with the approach suggested in Scenario 2, using only
data domains. However, for each data domain created in the previous scenario, there will
now be two data domains, one for Undergraduate and one for Graduate. The solution
used for Scenario 2 is provided as a possible solution for this scenario:
· Choose the Non-Hierarchical Domain installation option.
· Configure the following data domains:
· Law Undergraduate
· Law Graduate
· Business Undergraduate
· Business Graduate
· Medical Undergraduate
· Medical Graduate
· Science Undergraduate
· Science Graduate
· University Undergraduate
· University Graduate· First zone is created by default during installation.
· First domain is created by default during installation.
Eleven logical groups have been configured, and all data belongs to one of these logical
groups. Each group is a domain-zone combination. The logical groups are:
· Law Undergraduate - First
· Law Graduate - First
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 25/30
Implementation Scenarios 19
© 2001-2002 SCT ** CONFIDENTIAL **
· Business Undergraduate - First
· Business Graduate - First
· Medical Undergraduate - First
· Medical Graduate - First
· Science Undergraduate - First
· Science Graduate - First
· University Undergraduate - First
· University Graduate - First
· First - First
Data that must be available for all users, irrespective of the logical group to which they
have access, belongs to the First domain and First zone.
Responsibilities would be configured similar to the manner described for Scenario 2.
The disadvantage to this approach is in the amount of configuration effort that would be
necessary in meeting future requirements. For example, Your University decides to split
graduate administration into graduate and doctoral offices. This change would require
creating five additional data domains, and configuring the respective responsibilities.
Alternatively, use both zones and data domains to achieve the same purpose. Create the
following data domains:
· Law
· Business
· Medical
· Science
· University
· First
Create the following zones:
· Undergraduate
· Graduate
· First
This combination of six data domains, plus the Undergraduate, Graduate, and First zones
produces the required logical groups that result from the first solution using eleven data
domains and one First zone. If graduate is now split into graduate and doctoral, you can
create an additional zone. Access must be granted on this zone to the new responsibilities
that administer doctoral students and other related data.
Using the second approach, you can configure only FA, V, or None for a responsibility’s
access on a zone. This can be a disadvantage if you require more granular rights. The first
approach, creating eleven data domains, enables you to configure CRUD rights in order
to meet this requirement.
Configuring Responsibilities:
The necessary responsibilities for the data domain and zone approach are:
· Law Admissions Undergraduate Data Entry Operator . This responsibility is
mapped to the Prospect menus and SMS Student menus. This responsibility is
mapped to the Law Domain, with CRUD rights, and to the Undergraduate zone
with FA rights. This is the responsibility assigned to users in the Law College’s
Undergraduate Admissions office who accept applications from interested
parties and enter the data into the system. Similarly, create responsibilities for
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 26/30
20 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
use by the other colleges’ Admissions, Aid, Accounts, and Registrar’s offices,
for both Graduate and Undergraduate purposes.
· Each college admissions office has a user who sets up the admission
requirements and communication groups. Create a responsibility for such users
with access to these menus and the respective college data domain. Assign
CRUD rights on the college data domain and FA rights on either the Graduate or
Undergraduate zone.
· Create a responsibility for the University-level admissions office that has CRUD
rights on the University data domain, CR rights on all the other data domains,
and FA rights on both the Graduate and the Undergraduate zones.
· For users in the Student Financial Aid office of the Law and Business Colleges
that handles for both graduate and undergraduate students, create a
responsibility that has CRUD rights on the Law data domain, CRUD rights on
the Business data domain, and FA rights on both Graduate and Undergraduate
zones.
Scenario 4: A More Involved Zone and Data Domain
In this scenario, Your University has exactly the requirements detailed in Scenario 3,with the following exception.
Certain data must be maintained jointly by the Law College and the Business College.
For example, the graduate admission welcome letter is configured and maintained at a
single point for both the Law and Business colleges. One user in the Graduate
Admissions office of the Law College and another user in the Graduate Admissions
office of the Business College may update this letter at any point in time.
Configuring Zones, Data Domains, and Responsibilities:
Neither of the configuration solutions presented above completely suits the needs of
Scenario 4. To meet this particular requirement, both configuring eleven data domains
and configuring six data domains plus three zones are unsuitable. Consider the latter
approach.Using this solution, you have the following responsibilities:
· Law Grad Admissions: CRUD on Law domain and FA on Graduate zone.
· Business Grad Admissions: CRUD on Business domain and FA on Graduate
zone.
In which logical group do you create this common Admission welcome letter?
You could create this letter in the First domain and First zone. However, in this case even
users with no access on either the Law or the Business domains or Graduate zone can
update and even delete this letter. For example, an administrator in the Undergraduate
Medical School’s Admissions office would have access to this letter because it is in the
First domain and First zone, and could update or delete the letter from the First data
domain or First zone. This is not a working solution.
The ability to map a responsibility to multiple data domains or zones becomes useful in
this instance. Follow this approach to meet the needs of Scenario 4:
· Create a Law Grad Admissions responsibility that has CRUD permissions on the
Law domain and FA permission on the Graduate zone.
· Create a Business Grad Admissions responsibility that has CRUD permissions
on the Business domain and FA permission on the Graduate zone.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 27/30
Implementation Scenarios 21
© 2001-2002 SCT ** CONFIDENTIAL **
· Create another responsibility called Law & Business Grad Admissions, and
assign CRUD permissions on both the Law domain and the Business domain,
and FA rights on Graduate zone.
· Map the Law Grad Admissions and Law & Business Grad Admissions
responsibilities to the users in the Law College’s Graduate Admissions office.
Map the Business Grad Admissions and Law & Business Grad Admissions
responsibilities to the users in the Business College’s Graduate Admissionsoffice.
· The common admissions letter is first created by a user in the Law College’s
Admissions office, and is created in the Law domain and the Graduate zone.
· All users in both the Law College’s Graduate admissions office and the Business
College’s Graduate admissions office can view and update this letter by logging
on to the system with the Law & Business Grad Admissions responsibility.
This configuration of zones, data domains, and responsibilities with user access to
multiple zones and data domains appears to meet the requirement needs. However, there
is one limitation to this approach. Consider a user in the Business College Admissions
office who has logged on to the system with the Law & Business Grad Admissions
responsibility. This user will now be able to view and update any data that belongs to
either Law-Graduate logical group or Business-Graduate logical group. This implies that
this user would be able to update and view even student data belonging to Law-Graduate
logical group.
There is a possible solution to overcome this limitation. Instead of associating all the
menus to the Law & Business Grad Admissions responsibility, associate only the Letter
Maintenance menu to this responsibility. As a result, when Business College users log on
to the system with the Law & Business Grad Admissions responsibility, these users will
only be able to see letter data, and not any other student data.
Even this solution does not completely eliminate the problem. Though the Business
College user will now be unable to view student data that belongs to Law College, this
user will still be able to view all letters that belong to the Law College. The requirement
however, is to share the ownership of only one letter. The Business College user can still
update or delete other letters that belong to the Law domain.
To overcome this, use the following approach:
· Create a Law data domain and a Business data domain.
· Create a Graduate zone and an Undergraduate zone.
· Create one more zone, called Law & Business
· Create a Law Grad Admissions responsibility that has CRUD permissions on the
Law domain and FA permission on the Graduate zone.
· Create a Business Grad Admissions responsibility that has CRUD permissions
on the Business domain and FA permission on the Graduate zone.
· Create another responsibility called Law & Business Grad Admissions, and givethis responsibility CRUD permissions on both Law domain and Business
domain, and FA rights on Law & Business zone.
· Map the Law Grad Admissions and the Law & Business Grad Admissions
responsibilities to the users in the Law College Graduate Admissions office.
· Map the Business Grad Admissions and the Law & Business Grad Admissions
responsibilities to the users in the Business College Graduate Admissions office.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 28/30
22 Security Implementation Guide Exeter Student Suite 5.0
© 2001-2002 SCT ** CONFIDENTIAL **
The only data that users are able to view while logging on with the Law & Business Grad
Admissions responsibility is data that belongs to either the Law domain or the Business
domain, and belongs to the Law & Business zone.
Any shared data, data that is owned, viewed, and updated by both the Law College and
the Business College, will be placed in the Law & Business zone. The Law & Business
Grad Admissions responsibility will be mapped only to Letter Maintenance menu.
For some data, such as Codes, Degrees and Majors, it is possible to publish the data to a
set of zones and/or data domains explicitly through the user interfaces. For any other data
that must be shared, the scenario above is the suggested.
The shared data is, as explained above, placed in a separate zone that was created for this
purpose. Instead of creating a zone, you could also create a separate data domain to meet
this requirement. The choice depends on the granularity of access required for various
users. If FA and V are sufficient, the zone approach works. However, if more granular
access is required, use data domains.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 29/30
Summary 23
© 2001-2002 SCT ** CONFIDENTIAL **
SummaryThe basic principles used when configuring security in your system include:
· Control user access to various screens in the application by configuring
responsibilities and mapping these responsibilities to different menus. Inaddition, specify E, D, ED, or no permissions for each screen to which this
responsibility has access.
· Identify pockets of data that must be restricted to specific responsibilities,
and configure these groups as data domains and/or zones. Zones and data
domains are driven by the organization and business practices of your
school.
· Use zones and additional data domains to achieve further partitioning
within these initial data domains. Zones allow FA and V access
rights. Data domains allow data partitioning at a more granular level,
with CRUD access rights.
· In cases where some data must be jointly owned by more than one
data pocket, create an additional zone or data domain, as explained inScenario 4. Configure responsibilities that have access on multiple
data pockets, including this new data pocket.
· For users who need access to data from more than one data pocket, map
their responsibilities to multiple zones and/or multiple data domains, with
appropriate access rights on each.
8/6/2019 E5 Security Implementation Guide
http://slidepdf.com/reader/full/e5-security-implementation-guide 30/30
Index
A
administrative users, 6application, 2
authentication, 4
authorization, 4
C
CMN, 2
CRUD, 2
D
data domain, 2
database, 2
F
FA, 2
I
implementation scenarios, 15
complex zones and data domains, 20
only data domains, 17
only zones, 15
simple zone and data domain, 18
installation, 2
no domain, 11
non-hierarchy, 11
introduction, 1
M
menu, 2
menu item, 6
module, 2
P
permissions, 2assign, 10
create, 9
delete, 7, 10
edit, 7
full access, 12
interaction, 13
none, 7
read, 10
update, 10
view, 12
product features, 6
R
responsibility, 2, 6
responsibility domain, 3
S
SAS, 2
SBS, 2
screen permissions, 7
security model, 4
self-service users, 6
SMS, 2
SSS, 2
summary, 23
T
terms, 2
Z
zones, 3, 12