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



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.



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



ii Security Implementation Guide Exeter Student Suite 5.0


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



Introduction 1


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.



2 Security Implementation Guide Exeter Student Suite 5.0


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.



Exeter Student Suite Security Model 3


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.





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





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.





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.





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.





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.





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.





· 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.





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.





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.





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



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


data not viewable


data not viewablenone Anypermission





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.





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.



Implementation Scenarios 15


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.





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.





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.


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.


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.





· Each college’s admissions office will have a user who establishes the admission


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.


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





· 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.


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





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


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.





· 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.





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.



Summary 23


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.



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

e5 security implementation guide

Documents