More information

Tools World

Site Specific Notes

About User Security

This topic discusses the general background and functionality for Group Maintenance, User Maintenance, and View Maintenance within Millennium.

Follow these links listed for explanations and specific procedures for Group Maintenance, User Maintenance, and View Maintenance:

User Security Display

When User Security is accessed, two areas display. Information about the Millennium User Groups is displayed under the Group Maintenance header, and information about each individual Millennium user is displayed under the User Maintenance header. The information about the user groups and the users display as individual 'data' rows in typical Millennium fashion. Edit buttons are located to the left of each entry and a fly-over context menu appears when you move the mouse pointer over either the Section Header Edit button or any one of the edit buttons.

By default, the user data is shown is Short mode - a single line display. In Short mode, the display for the Millennium User Group information includes the name of the group only. In Short mode, the display for Millennium Users includes the Name ( Millennium User id), Millennium User Group (MUG), and the SQL Group (Database Group) for each user. By default, the Sort order is ASCII order within SQL Group; that is to say, User Names are first sorted into SQL Groups and then ASCII ordered within each SQL Group.

The context menu that is accessed via the Group Maintenance section header Edit button includes items that allow you to switch the display between Short and Long view, Insert a new Millennium User Group, access the View Generator, or access this Help topic.

The context menu that is accessed via the User Maintenance section header Edit button includes items that allow you to switch the display between Short and Long view, Insert a new Millennium User, Sort the list of Millennium Users, or Close the context menu.

Security Background Information

There are three levels of security that may be applied to the operation of Millennium in an SQL environment. Each has a different purpose and application and each is administered independently (or nearly so). These are:

Database Group Security

Database Group Security is administered through the Group Maintenance function of User Security in Millennium, using Views that were created using the View Generator. This form of security is used to determine which data rows a user may access, edit, or delete.

Millennium User Group (MUG) Security

MUG security is administered through the User Maintenance function of User Security in Millennium. This form of security is used as:

Secure Socket Layer (SSL) Security

SSL security is entirely administered through Microsoft's Internet Information Server (IIS). This form of security is used to encrypt the transmission of data across a network and is used to secure a system against intruders. This form of security is external to the function of Millennium and is not addressed by this topic.

Terminology

An understanding of the following terminology is necessary for the Group Maintenance and User Maintenance documentation, which follows.

Groups

Millennium uses the term, group in several different ways. This topic describes the distinct differences between the Database Group and the Millennium User Group and how they are applied to the subject of security in Millennium. There are additional kinds of groups within Millennium that have no particular relationship to the topic of security but are simply mentioned to ensure that the reader is aware of the distinctions. These include the Lookup Table Group - a standard field in all lookup table rows that allows an institution to classify a set of lookup table entries in some way, and also a Criteria Group - which allows the Millennium Reporter to select multiple sets of constituents within a single run of a report. Those groups are discussed with Lookup Tables or Reporting, respectively.

Views

A View is an SQL object, sometimes referred to as a virtual table, which may be used to restrict access to selected data in a particular data table.

Views are constructed and saved via the Millennium View Generator, which is accessed via the Group Maintenance Options button in the User Security display page. When Millennium is delivered and installed, a default set of Views is provided. That set consists of one View per Millennium data table, each named <tablename>_full. For example, the default view on the Basic Data table is named corebio_full. Each of those Views gives access to all rows in the designated data table.

You may define any number of custom Views that apply to individual data tables. A listing of all Views that have been created and stored may be seen and used from within the Group Maintenance function of Millennium.

You may define a custom View for the purpose of masking the display of sensitive information. For example, you may want the users in a particular Millennium User Group to be able to see that a constituent has a death record, but you may not want them to be able to view the cause of death. Define a custom View that selects all fields from the death table. If the deathcause field contains information, select a series of masking characters (typically asterisks) instead of the actual text contained in the field. Give this Millennium User Group select privileges for this view. When displaying a constituent's death record, then, users would see the masking characters instead of the cause of death.

Important! Do not define a custom View to mask the display of Millennium's encrypted fields (coressnum, credccnum, credssnum). When these fields display through Millennium, the software will attempt to decrypt the masking characters and the results will not be correct.

When a View is defined (that describes the conditions for access to rows in a specific data table) that definition may reference data in other tables, in the conditional statement. For example, you might construct a View that would allow access to all Gift rows that belong to any constituents who do not have a Y(es) in the Anonymous field in their Basic Data row. That View would have no effect on the access to the Basic Data row. A separate View would be needed to define Basic Data access.

Database Group

A Database Group is a SQL technique for creating a "packaged set" of Views, naming that Group and then assigning users to that Database Group (rather than having to select individual Views for each user that you want to add to the system). Millennium includes the tools necessary to define a Database Group via the Group Maintenance function within the Tools World. When a Group is defined via Millennium, it is automatically "registered" appropriately within SQL. Likewise, when you are using Millennium to define a Group, all Views that are have been created within the system are shown and are available for use in creating a Database Group.

When Millennium is delivered, it includes a default Database Group, which is named mill. This Database Group consists of the "full" View for each of the Millennium data tables and for all functions that a user might perform. If you want, you may assign all users to the mill group. This would give all users complete access to all data, for all functions (viewing, creating, editing, and deleting).

This "wide open" approach to security will not be appropriate for most institutions, and therefore, you will want to create additional Database Groups in order to impose the necessary restrictions.

Do not confuse the Database Group with the Millennium User Group, which is described below.

Millennium User Groups

The Millennium User Group (MUG) is a one character, upper or lower case alphabetic character "flag" that is associated with the individual's User ID. They have several applications within Millennium.

Millennium User Groups do not need to be defined or set up within Millennium prior to the time that you assign the flag to a user, though you will certainly want to have a meaningful plan for doing so. They may be defined in any way that your institution wants. We anticipate that institutions will want to use this technique for identifying users within different geographical offices, different departments, or different divisions within the institution. You might also want to distinguish groups of users based on their use of Millennium.

Group Maintenance Background Information

When Millennium is installed, it includes a single Database Group, named mill. The mill group is based on a default set of Views, which are also delivered with the software. This default set consists of a full View for each of the Millennium data tables. For example, there is an actions_full, an address_full, etc. Therefore, since the mill group includes the full View for every data table, any user who is assigned to the mill group has complete access to all rows in all tables in Millennium.

There are no Views for lookup tables in Millennium. Database Groups may also be given various levels of access to Lookup Table maintenance functions as part of the definition of the Database Group. These permissions are applied to all lookup tables and all entries within them. Further control of the Access and maintenance capability may be applied to individual entries in any lookup table via Millennium User Group settings.

The system administrator may create additional Groups, which use a different combination of SQL Views (including none), for certain tables or functions. When these Database Groups are created from within Millennium, the system automatically registers these as SQL Groups within SQL Administration. While it is possible to create a Database Group through SQL Administration (bypassing Millennium), such Groups will NOT be available within Millennium.

To restrict a user's access to Millennium data and functions, you must create additional Groups or alter mill, removing certain access for users in that Group. Groups may be used to restrict the user's access to the data in several ways.

Views for Selected Tables (only)

You may define a Database Group in such a way that no Views of certain of the data tables are included. For example, you might define a Group in such a way that includes Views of all of the Biographical and Giving data tables but no View of the Tracking data tables. If no View of a particular data table is included in a Database Group, when a user from that group attempts to display a constituent's data from that table, the Profiles display will show the Section Header followed by the text (in red), Insufficient Security to View (Table Name).
You may pick and choose from any of the default or custom Views that are present on the system when assigning Views to a Database Group.

Variable Views by Function Within a Data Table

You may define a Group that assigns different Views to different functions within a single data table. These functions are:

For example, you might define an Executive Group in such a way that all users in the Group have the full Views of particular data tables for the Select function but no View assigned to the Update, Delete, or Insert function. This would allow those users to look at anything in that table (in Profiles, Reporting, or any other world that accesses that table), but would provide no ability to edit, delete, or create any existing rows.

When you are defining a new Group or editing an existing one within Millennium Security's Group Maintenance, you must first choose a data table from the Table List box, and then the system will display all of the Views that are available for that data table. This includes the standard ones (for example <tablename>_full) and custom ones that you have defined. You may choose any that are available for that data table, and assign them to any of the functions described above.

Example:

Create a Group that includes the following Views for the Basic Data, Name, and Attribute tables only:

For Basic Data:

For Name:

For Attribute:

Any user who is assigned to such a Database Group would be able to see (select) any Basic Data row, or any Name row. They would also be able to see (select) any Attribute row that conforms to the conditions of the View named attribute_sports. And they would also be able to update or delete any Attribute row that conforms to the attribute_sports View conditions.

Top of Page