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.
- Select Long to see more information about each User Group and about each User. Note that passwords will not display on this page, nor will they display on the User Maintenance forms. Select Short to return to the single line display. Note that setting the display mode via the Group Maintenance section header Edit button sets the same display mode for the Users as well.
- Select Insert to create a new Millennium or QlikView User Group.
- Select View Generator to access the application that allows you to perform the many tasks relevant to the display, creation, editing or dropping of SQL views. See View Maintenance for complete details.
- Select Help to access the User Security Help topic. A new instance of the browser will open to display the 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.
- Select Long to see more information about each User Group and about each User. Note that passwords will not display on this page, nor will they display on the User Maintenance forms. Select Short to return to the single line display. Note that setting the display mode via the User Maintenance section header Edit button sets the same display mode for the User Groups as well.
- Select Insert to create a new Millennium User.
- Select Sort
to change the Sort order. The menu expands to show three additional items.
- Alphabetically by User will ASCII order the Users by User Name.
- Alphabetically within SQL Group will ASCII order the SQL Groups, and, within each SQL Group, ASCII order the Users by User Name - this is the default Sort Order.
- Alphabetically within User Group will ASCII order the Millennium User Groups, and within each Millennium User Group, ASCII order the Users by User Name.
Note: If the Sort order selected is not the default Sort order, and if the IIS is reset, the Sort order will reset to the default Sort order.
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:
- a means of identifying a user (in addition to the Database Group described above),
- a means of 'flagging' every data row with the MUG of the user who performed the last edit on the row.
- a means of identifying which individual lookup table entries a user may use, view, or maintain,
- a means of defining a View (which may then be used in the definition of a Database Group), if desired.
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.
- When a user performs any sort of data maintenance, his/her User Group flag is automatically copied into the data row, into the xxxugroup field, (just as his/her User ID is copied into a xxxuserid field.) It may be used to track or monitor data that was created or last edited by a particular set of users. For example, you might want to generate a listing of all rows that were created or edited on a particular day by the users in a specific Millennium User Group, for proof reading purposes.
- Millennium User Groups are used to track the user's permission to access individual rows in Millennium lookup tables. Each lookup row includes an Access field. Those fields will contain a set of Millennium User Group letters that show which User Groups may access that lookup entry for data maintenance purposes. If the user's Group letter does not appear in the Access field, he or she will not be allowed to use it on an Insert or Update form. It will not appear in the pull-down list for that user. If it was already present in a data row which the user subsequently edits, he or she will not be allowed to change it.
- Millennium User Groups are used to track the user's permission to maintain individual rows in Millennium lookup tables. Each lookup row includes an Maintenance field. Those fields will contain a set of Millennium User Group letters that show which User Groups may view and edit that lookup entry within the Lookup Table Maintenance function. If the user's Group letter does not appear in the Maintenance field, when the user views the lookup table in the Tools World, that entry will simply not appear.
- Although Millennium User Group assignments in themselves have no direct impact or connection to the Database Group security settings or Views that are part of the Database Group, they can be an powerful tool to use in that context. In the same way that any other field from a data row may be used as part of the definition of a View, the MUG flag can be a very effective means of identifying rows that you want to identify within a View. For example, a View may be created and used that selects only the rows from a data table that have a particular MUG in the xxxugroup field. This technique would only let users have access to those rows that have been created or edited by other members of the same MUG.
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:
- Select encompasses the display of existing data rows and the creation of new ones, in the Profile, Reporting, or any of the Millennium Worlds.
- Update refers to the editing of any existing data rows.
- Delete refers to the deleting of any existing data rows.
- Insert refers to the creation of new data rows.
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.
Create a Group that includes the following Views for the Basic Data, Name, and Attribute tables only:
For Basic Data:
- Select corebio_full
- Update (none)
- Delete (none)
For Name:
- Select names_full
- Update (none)
- Delete (none)
For Attribute:
- Select attribute_sports
- Update attribute_sports
- Delete attribute_sports
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.