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

CONFIDENTIAL

141 Portland Street Cambridge, MA 02139

617.452.0400

www.sct.com

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

Contents i 2001-2002 SCT ** CONFIDENTIAL **

Table of Figures
Figure 1: Exeter Student Suite Security Model .............................................................................................. 4 Figure 2: Permission Interaction Table......................................................................................................... 13 Figure 3: Your Universitys Organizational Diagram .................................................................................. 15

ii Security Implementation Guide 2001-2002 SCT

Exeter Student Suite 5.0 ** CONFIDENTIAL **

Introduction
This 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 Implementers Guide that is available with each application. These guides include additional information regarding the implementation of security features.

Introduction 1 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 terms and concepts that drive Exeter Student Suites 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 stored in 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 users 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. 2 Security Implementation Guide 2001-2002 SCT Exeter Student Suite 5.0 ** 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 Suites 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.

Exeter Student Suite Security Model 3 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 individuals 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.

User attempts to access student grades

The Exeter Student Suite Security Framework

Authentication: Login and Password Is this a valid E5 user? Authorization of access to product features: Menu and Screen Permissions 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 Smiths data? Does this user have access to Andrea Moores data?

Smith, John - Grades 1. PHY 101 Final D 2. MATH 400 Final B

Moore, Andrea - Grades 1. CHEM 206 Final A 2. MATH 400 Final B

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, 4 Security Implementation Guide 2001-2002 SCT Exeter Student Suite 5.0 ** 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 schools security system. These examples are not allinclusive, 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 schools 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.

Exeter Student Suite Security Model 5 2001-2002 SCT ** CONFIDENTIAL **

User Access to Product Features

Each Exeter Student Suite user must have access only to specific product features. For example, a data entry operator in the Registrars 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 users 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. 6 Security Implementation Guide 2001-2002 SCT Exeter Student Suite 5.0 ** 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 Registrars 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 scenario above, the system administrator could assign Data Entry Operator in Registrars 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.

Exeter Student Suite Security Model 7 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 Security Implementation Guide 2001-2002 SCT

Exeter Student Suite 5.0 ** CONFIDENTIAL **

Data Domains and Zones

In 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 schools 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 can access data within the domain. In order to determine data domain configuration: 1. 2. Identify pockets of data on which a distinct set of users must operate. 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.

Exeter Student Suite Security Model 9 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 schools 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.

10 Security Implementation Guide 2001-2002 SCT

Exeter Student Suite 5.0 ** 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.

Exeter Student Suite Security Model 11 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 rights granted 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.

12 Security Implementation Guide 2001-2002 SCT

Exeter Student Suite 5.0 ** CONFIDENTIAL **

Interaction of Data Permissions and Screen Permissions

Screen level permission and data level permissions determine the users final level of data access. The final permissions on data for the end-user are determined by both the access that the users 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 Zone Permission FA FA FA FA FA FA FA FA FA V Data Domain Permission CRUD CRU CRD RUD RD RU CR R none Screen Permission E Can view, add and update data Can view, add and update data Can view and add records Can view and update data Can view data D ED none Can view data Can view data Can view data Can view data Can view data Can view data Can view data Can view data Screen viewable, but data not viewable Can view data

Can view and delete data Can view, add, update and delete data Can view data Can view, add and update data Can view and delete data Can view, add and delete data Can view and delete data Can view, update and delete data Can view and delete data Can view and delete data Can view and update Can view data Can view and update data data Can view and add data Can view data Can view and add data Can view data Screen viewable, but data not viewable Can view data Can view data Screen viewable, but data not viewable Can view data Can view data Screen viewable, but data not viewable Can view data

V none

Any permission, except none None Screen viewable, but data not viewable Any Screen viewable, but permission data not viewable

Screen viewable, but data not viewable Screen viewable, but data not viewable

Screen viewable, but data not viewable Screen viewable, but data not viewable

Screen viewable, but data not viewable Screen viewable, but data not viewable

Figure 2: Permission Interaction Table

Using Zones and Data Domains

Exeter Student Suites 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 zoneonly 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 and data 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. Exeter Student Suite Security Model 13 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 schools 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.

14 Security Implementation Guide 2001-2002 SCT

Exeter Student Suite 5.0 ** CONFIDENTIAL **

Implementation Scenarios
The 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 school remains unchanged.

Figure 3: Your Universitys 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 colleges admissions offices. Implementation Scenarios 15 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 registrars 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 colleges 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 schools 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 Colleges 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 Registrars offices. Each colleges 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.

16 Security Implementation Guide 2001-2002 SCT

Exeter Student Suite 5.0 ** 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 by the Law Colleges 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 Colleges 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 Registrars offices.

Implementation Scenarios 17 2001-2002 SCT ** CONFIDENTIAL **

Each colleges 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 Exeter Student Suite 5.0 ** CONFIDENTIAL **

18 Security Implementation Guide 2001-2002 SCT

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 responsibilitys 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 Colleges Undergraduate Admissions office who accept applications from interested parties and enter the data into the system. Similarly, create responsibilities for Implementation Scenarios 19 2001-2002 SCT ** CONFIDENTIAL **

use by the other colleges Admissions, Aid, Accounts, and Registrars 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 Schools 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. Exeter Student Suite 5.0 ** CONFIDENTIAL **

20 Security Implementation Guide 2001-2002 SCT

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 Colleges Graduate Admissions office. Map the Business Grad Admissions and Law & Business Grad Admissions responsibilities to the users in the Business Colleges Graduate Admissions office. The common admissions letter is first created by a user in the Law Colleges Admissions office, and is created in the Law domain and the Graduate zone. All users in both the Law Colleges Graduate admissions office and the Business Colleges 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 give this 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. Implementation Scenarios 21 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.

22 Security Implementation Guide 2001-2002 SCT

Exeter Student Suite 5.0 ** CONFIDENTIAL **

Summary
The 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. In addition, 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 in Scenario 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.

Summary 23 2001-2002 SCT ** CONFIDENTIAL **

Index
A administrative users, 6 application, 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 permissions, 2 assign, 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 P

24 Security Implementation Guide 2001-2002 SCT

Exeter Student Suite 5.0 ** CONFIDENTIAL **