Securing Campus Community

This chapter discusses how to:

Set up communication, checklist, and comment (3C) group security.
Set up service indicator security.
Copy user security.
Apply demographic data access security.

Setting Up 3C Group Security

To set up 3C group security, use the 3C Group Security component (OPR_GRP_3C_TABLE).

You can select which 3C groups user IDs can view and update. The Campus Community 3C engine also uses the security that you set up here. The 3C engine does not process the user's request if the user does not have update access for the 3C value used in the process. 3C groups allow access to specific communication categories, checklist codes, and comment categories.

This section lists prerequisites and discusses how to grant 3C group security.

Prerequisite

Before you set up 3C group security, set up 3C groups and complete institution security setup.

Page Used to Set Up 3C Group Security

Page Name	Object Name	Navigation	Usage
3C Group Security	OPR_GRP_3C_TABLE	Set Up SACR, Security, Secure Student Administration, User ID, 3C Group Security	Grant user access to 3C group information.

Granting 3C Group Security

Access the 3C Group Security page.

Institution

Select an institution. Only institutions to which this user ID has access are available.

3C Update/Inquiry Group

Select the 3C group that the user ID should have access to for the selected institution. The 3C groups are defined inside the Group 3C Table page (GRP_3C_TABLE page).

Inquiry Indicator

Select to enable the user ID to view all data in the 3C group. The inquiry indicator is used to widen or narrow searches on 3C inquiry pages throughout the system. For example, a user that has inquiry access to a certain 3C group will only be able to view the communications, checklists, or a comments assigned to an individual or to an organization that is tied to the 3C group.

Update Indicator

Select to enable the user ID to update—enter or alter—data in the 3C group. You should also select this check box if you want the user ID to be able to process 3C items by using the 3C engine. If the user ID does not have update access to the 3C group, the 3C engine does not process a request by using the 3C group. This is similar to the way the system manages manual assignments for communications, checklists, or comments.

Setting Up Service Indicator Security

To set up service indicator security, use the Service Indicator Security component (SCRTY_TABL_SRVC).

This section lists prerequisites and discusses how to grant access to service indicators.

Prerequisite

Before you set up service indicator security, set up service indicators in the Service Indicator table.

Page Used to Set Up Service Indicator Security

Page Name	Object Name	Navigation	Usage
Service Indicator Security	SCRTY_TABL_SRVC	Set Up SACR, Security, Secure Student Administration, User ID, Service Indicator Security	Grant access to service indicators for a user ID for a particular institution.

Granting Access to Service Indicators

Access the Service Indicator Security page.

Service Indicator Code

Select a code for each service indicator that the user ID should be able to access. To restrict the use of a service indicator by reason, enter multiple rows for the service indicator and select the different reasons that apply. You define service indicator codes inside the Service Indicator Table.

Reason

To limit the use of a service indicator code, select a reason indicating when the user ID can access the service indicator. If you do not select a reason, the user ID can use the service indicator in all cases.

For example, if this user ID should only be able to use the conference guest service indicator for football recruitment visits or Special Olympics guests, select each of those reasons for the conference guest service indicator. You define the reasons for using a service inside the Service Indicator Table.

Placement and Release

Select if this user ID should have permission to assign or release the service indicator.

Copying User Security

To set up the copying of user security, use the User Security Replacement component (SCRTY_OPRID_REPLAC).

Copying a security setup is the same as going to each appropriate menu and entering data for each security object to assign security for a specific user. Replacement security automates the process for you by enabling you to copy a security profile to another user.

This section discusses how to copy user security setup.

Page Used to Copy User Security

Page Name	Object Name	Navigation	Usage
User Security Replacement	SCRTY_OPRID_REPLAC	Set Up SACR, Security, Secure Student Administration, Setup, User Security Replacement	Copy the security setup of one user to another user.

Copying User Security Setup

Access the User Security Replacement page.

Default Replacement User

To replace or create all of this user ID's security objects with the same security objects assigned to another user ID, specify the user whose security objects you want to copy in this field. When you exit the field, the system copies each security object from the replacement user and automatically populates the remaining fields with the replacement values.

If you do not want to replace each of this user's security objects with all the security objects of one user ID, indicate the replacement user ID for each object that you want to replace. You do not have to replace all objects. For those objects that you do not want to replace, leave the field blank.

User Preferences

When you enter a user ID in this field, the default values that you set up in the User Default component for the entered user ID are assigned to the user ID, including the enrollment override defaults and user 3C group security.

User defaults are set up in the User Defaults component.

See Setting User Defaults.

When you enter a user ID in any of the other fields on this page, the user ID is assigned the same security that you set up for the selected user ID for that item. All of these fields refer to the security that you set up on the pages in Set Up SACR, Security, Secure Student Administration, User ID.

Applying Demographic Data Access Security

To set up demographic data access (DDA) security, use the Demographic Data Access component (PERS_MSK_CFG) and the Demographic Data Access process component (RUNCTL_MSK_CFG).

This section provides an overview of DDA security, setting up DDA security, and discusses how to:

Define DDA masking configurations.
Run the DDA process.

Understanding DDA Security

With DDA security, you can mask the display of national ID and birthdate data in search records, prompt records, and on the Bio/Demo Data and the Relationships pages if these pages have display-only security. You can mask the entire fields or the first five characters of the national ID field or the year of the birthdate field. You can apply masking to one, both, or neither field. No matter which masking configuration you use, users can search on the entire national ID field.

Note. You can make the masking of National ID and birthdate in Search/Match functionality become more flexible. See Search/Match display options. National ID and birthdate data is also not masked in queries and reports.

See Setting Up Search/Match.

To apply DDA security, you define masking configurations for all primary permission lists and assign a primary permission list to each user ID as part of his or her User Profile.

For example, suppose a primary permission list assigned to a user ID is named ALLPANLS. You might not want national IDs to appear throughout the system for this permission list, but you do want partial birthdates to appear. You would access the Demographic Data Access setup page and insert a row for the ALLPANLS permission list. In that row, you would configure the system to 1) mask the entire national ID, and 2) to display a partial birthdate field (masking the year).

You must then run the Demographic Data Access (MSK_CFG) process to replace data in the masking configuration table with the masking configuration that you defined and to apply the new configuration to each user to whom that permission list is assigned.

In the example, after running the Demographic Data Access process, each user whose primary permission list is ALLPANLS will not see national IDs on search pages or prompts, but they will see the birth month and day where birthdates appear. The masking configuration for the primary permission list to which a user is assigned also controls how national ID and birthdate data appear on the Bio/Demo Data page (SCC_BIO_DEMO_PERS) and the Relationships page (RELATIONSHIPS) throughout the system.

Note. The national ID and the birthdate fields appear masked on the Biographical Details page and the Relationships page only for users who have security set to show the pages in display-only mode. If a user has more than one permission list and therefore has both add/update and display-only access to a masked page, the least restrictive setting (add/update) takes precedent and masking is not applied.

Setting Up DDA Security

To set up DDA security, you must assign a primary permission list to each user ID, grant administrative access to components for managing DDA, and define masking configurations for each primary permission list.

Note. All Campus Solutions search records and prompts depend on DDA security. You must therefore assign a primary permission list to each user, even to those who do not need the national ID and the birthdate fields masked. In the latter case, simply set the masking configurations in the primary permission list for both the National ID and the Date of Birth to Display entire field.

Pages Used to Apply DDA Security

Page Name	Object Name	Navigation	Usage
General	USER_GENERAL	PeopleTools, Security, User Profiles, User Profiles, General	Assign a primary permission list to a user ID.
Pages	ACL_MENU2	PeopleTools, Security, Permissions & Roles, Permission Lists, Pages	Grant access to new components for managing DDA masking configurations for each primary permission list. Grant access to new Student components for users that should prompt only against Students.
Demographic Data Access (setup)	PERS_MSK_CFG	Set Up SACR, Security, Secure Student Administration, Permission List, Demographic Data Access	Define masking configurations for primary permission lists.
Demographic Data Access (run control)	RUNCNTL_MSK_CFG	Set Up SACR, Security, Secure Student Administration, Process, Demographic Data Access	Initialize the primary permission list configuration for all primary permission lists assigned to users.

Defining DDA Masking Configurations

Access the Demographic Data Access (setup) page.

Important! Each time you make changes to the Demographic Data Access page, you must run the DDA process to apply the changes.

Set as Default	Select to assign this masking configuration to all permission lists used as primary permission lists. When selected, the Primary Permission List field becomes unavailable.
Primary Permission List	Insert a row for each primary permission list that requires a masking configuration different than the default masking configuration. When you run the process, the system applies this masking configuration to all users to whom this primary permission list is assigned.
Mask National ID	Enter the configuration to use for national IDs. Options are Display entire field, Display partial field, and Mask entire field. If you display a partial field, the system masks the first five characters of the national ID field. These translate values should not be modified.
Mask Birthdate	Enter the configuration to use for birthdates. Options are Display entire field, Display partial date, and Mask entire field. If you display a partial date, the system masks the year and displays month and day in the default date format for each birthdate field. These translate values should not be modified.

Running the DDA Process

Access the Demographic Data Access (run control) page.

You must run the DDA process (MSK_CFG) to apply changes made on the Demographic Data Access (setup) page and to apply the default masking configuration to any newly created, newly assigned primary permission list whose masking configuration is not otherwise defined.

Note. The process applies the masking configuration only for permission lists that are used as “primary” permission lists. Therefore if you assign a User ID a primary permission list that was not used as primary the last time the DDA process was run, you will need to run the process again.

Institution	Select an institution. Only institutions to which this user ID has access are available.
3C Update/Inquiry Group	Select the 3C group that the user ID should have access to for the selected institution. The 3C groups are defined inside the Group 3C Table page (GRP_3C_TABLE page).
Inquiry Indicator	Select to enable the user ID to view all data in the 3C group. The inquiry indicator is used to widen or narrow searches on 3C inquiry pages throughout the system. For example, a user that has inquiry access to a certain 3C group will only be able to view the communications, checklists, or a comments assigned to an individual or to an organization that is tied to the 3C group.
Update Indicator	Select to enable the user ID to update—enter or alter—data in the 3C group. You should also select this check box if you want the user ID to be able to process 3C items by using the 3C engine. If the user ID does not have update access to the 3C group, the 3C engine does not process a request by using the 3C group. This is similar to the way the system manages manual assignments for communications, checklists, or comments.