Using the Member Database to Control Web Site Security

Association web site security automated by using codes from the member database to control access to member only areas. Automated export and online registration take staff out of routine authorization maintenance. Highly granular access control to resources based on member type and section / special interest group memberships.

Automated Maintenance

Most web server software provides for public and private areas. IIS on NT and Apache on most platforms provide for tie-ins with operating system security and using OS usernames and passwords. Beyond that, providing granular security becomes a matter for custom programing. While ATLA NET was on the legal publisher's host, we were limited to public and private areas. All registered members had access to all private areas.

When ATLA took control of its own site, the two major functional areas that it gained control over were the list server set up and site security. Hosting our own site let us take site security in directions that few sites other than intranets have gone with highly granular security and selective access to limited areas. Intranets, however, tend to get their security definitions from the underlying OS. Network administrators maintain the user databases or directories against which the web server software authenticates users. Since this has been a core part of network administration since the inception of LANs there is no special additional overhead other than perhaps adding a few web specific user groups.

Where the number of users, in this case members, is enormous compared to the number of support staff, any administrative procedure that requires staff involvement to set up or control member access to a web site quickly becomes a major administrative burden and in the long run probably can not be supported. ATLA had already taken the first steps towards automating web user administration while still on the legal publishers site.

Member Authentication

Though the Netscape server authentication file provided only for public and private areas and no differentiation within the private areas, this file was maintained via an online registration process where ATLA members created their own user names and passwords. To register a member had to provide their last name, their ATLA member number and their bar year or birth date. We examined all the data in the member database and considered what we could have the member enter, that they would know or have easy access to, that the public could not easily get and that would match unambiguously against the actual data stored in our member database.

Lawyer's last names are public information but neither ATLA's member ID or a lawyer's birthday or bar year are easily obtained by persons not associated with the member. When we considered what data to verify members against we always tried to keep in mind that our primary concern was to protect access to the system so that non members could not get into and use the online member services as members. Our traditional computer security concerns were relatively minor compared to this. Simply put, there is very little data of value to anyone except members and their legal opponents on the web site. Most of the information is derived from other sources and is well backed up. The site is not an e-commerce site so a denial of service attack or even the complete loss of the system to crackers would be more of a (big) nuisance than a catastrophe.

Since ATLA does not do and is not likely ever to do background checks on its members, anyone who really wants access to the system merely needs to fraudulently complete a membership application claiming they are a lawyer who has just started to practice law. This puts the price of illicit admission at about $50. When you consider that, it's pointless to go to the lengths that many sites need to protect themselves. Until early 1999 when we created a public member directory that gave away one of the key pieces of information necessary to enter the site as a member, we felt that our security was appropriate to our needs.

NT Users and OS Security

On the old system the user assigned themselves a username and a password and when they completed registration, the username and encrypted password were saved in a file, used by the Netscape server, to grant on/off access to the private areas of the site. The new system changed this so that the registration process actually created a new NT user record from the username and password provided by the member registrant. In addition, codes in the member record were used to add the member to as many NT user groups as necessary, one NT group per each code. Thus member record codes translated directly to membership in NT user groups which were in turn, granted access to various resources on the system.

The preceding statement is not strictly true. In ATLA's membership system codes that may grant access to resources on the web site come from at least four different sets of codes in the member record. Theoretically, at any time new areas of the site could be added that correspond to an entirely different set of codes in the member record. There is a single primary member type, potentially a multiplicity of other member types, committee codes and a catch all category code.

The primary member type correlates most importantly with voting status and dues level. The other member types were for ATLA Sections which are extra fee specialty groups focused on specific areas of the law. Some resources are available only to voting members and some benefits go only with a particular dues level such as the higher paying types getting larger, more comprehensive, directory listings.

Many of ATLA's access rules are not so simple however but rather based on certain combinations of codes. When looking at the resources associated with Sections some were simple and depended only on membership in the Section but others depended on being a voting member and a member of any one or more sections. Still others required being a member of the specific section and others both a voting member and a member of the specific section. The very highest level of primary membership overrode most of these and provided access to nearly all the section related resources, regardless of whether the member was a member of the section or of any section. Finally some sections had special access rules that allowed types of members who were barred from accessing comparable resources in other Sections, to use certain resources within the specific Section area.

Member Data Export

Clearly, trying to embed complex logic like this in various routines, or even a centralized security module on the web site that is not directly tied to the member database and has no knowledge of the member database structure, would likely cause problems. The solution was to translate various combinations of codes into a series of simple codes in one place. The data export module that prepared data from the membership database for the web site performed this function. This export program, used procedural logic to create the various relationships between different sets of codes and to explicitly account for the unique cases.

The first exports, were initially developed in 1995 when ATLA's site was remotely hosted, ATLA had no continuous high speed connectivity to the Internet, and VPNs and real time ODBC back end database to web site connectivity were things of the future. In very resource limited environments such as most associations there is a strong tendency to make minor modifications to existing infrastructure. If such changes can achieve the functionality that is needed immediately, there is little inclination to review core infrastructure to determine how well it's likely to meet long terms needs. Further, "long term" needs in an association environment are much more volatile, being subject to rapid change based on current leadership, than long term needs in a traditional profit oriented business.

For a number of services that are provided by ATLA's web site, the export model works quite well. The procedural logic in the export routine is able to translate complex business rules and multiple codes stored in different locations in the member record into single codes that grant or deny access to specific resources on the web site.

Application Level Security

For the protection of static resources, some codes passed to the web site are turned into NT user groups. There is a table that defines which member codes become which NT user groups. For dynamic content provided via scripts, as mentioned previously, a limitation in NT security required the development of application level security via a function that all protected scripts had to call.

Ultimately, regardless of the functionality provided by NT and IIS, such a module would have been needed to provide controlled access to specific resources to which the scripts gave access. As an example, ATLA Online includes a significant number of list servers which are available to various subsets of ATLA's members. The same basic scripts provide the font ends for all lists. The security module needs to determine which member is running the script and whether or not they are allowed to access the list they are trying to get to.

The security module is called at the beginning of each private script and determines if the user has access to the script. The security module is passed the logical name of the function to be protected. If the user has access, control is returned to the calling function, otherwise the security module terminates the program and displays an HTML page that indicates the user is not authorized to use the function they are trying to access.

Though the security model is largely table driven, there is more to it than this. The function names are hierarchical in nature. The security module always attempts to determine access based on the most specific function name provided but if there is no table entry that matches the current function name, that name is reduced to the next higher level and another check performed. As long as a match is found at some level, the remote users access codes are checked against those allowed for the function being tested and if an exact match is found, access is allowed.

The multi level naming structure allows broad classes of security access to be defined but specific security can be placed on any function, any point within a function or any resource accessed by a function, as necessary. This allows for highly flexible, but low maintenance application security, as specific table entries do not need to be created for every possible function point to be protected. Safety is provided at two levels: once a match is found in the security tables, the user must have access at that level. No further checking is done if they do not. Access is denied. Unless at least one match is found in the security table, no access is allowed to any user. This prevents careless security setup from unintentionally opening a protected function to unauthorized users.

Adaptive Scripts

Further, any protected function may define numerous points within its own logic that can have different function names and thus different levels of access for various members. This allows scripts to dynamically adjust the content they display depending on who is running them. Thus, a link to a resource the user does not have access to is not displayed at all rather than being displayed and inviting the user to click on it only to be met with a password prompt or access denied message. Alternatively, if the member might become eligible to use the resource they might be shown instructions on using the resource or a description of the resource, which in turn may dynamically adjust to indicate why the user is seeing instructions and not the actual resource and what the user must to gain access to the actual resource.

Where a script provides access to and protects a resource, such as a Section membership related benefit, the scripts pass the section name (or a shortened version) between themselves which causes the appropriate resource to be presented to the user. The function names that are passed to the security function are dynamically created before calling the security function and where variable resources such as section related benefits are involved, the section name becomes part of the function name that is passed. By systematic use of the multilevel naming structure, highly flexible security can be provided with a minimum of administrative maintenance. Only a limited number of security definition tables need to be maintained. All user specific setup is handled automatically by the system.

Batch Updates

So far everything that has been described covers, the initial user account creation and setup and dynamic access to interactive web functions. One important piece is missing. In any membership organization, over time, some significant number of members will lapse, upgrade or otherwise change their membership status. The web site has to dynamically accommodate this without either staff or member intervention. In an environment where the integration with the member database is handled via data export, as long as this function is performed automatically at the end of each business day, for most practical purposes, the web member database is kept synchronized with the central member database.

Updating the web member data is all that is necessary to control access to the dynamic site content. Dynamic content is accessed through scripts that call the central security module, each time a script is run. The security module in turn checks the current member data. This leaves at least two other areas which must be dealt with separately. Unless the NT user record which is created during the online registration is removed or disabled a lapsed member would continue to have access to static site content. Also any application, such as list servers, that have their own application security are not protected from changed member status just because the web member data has been updated. List server integration and security will be discussed at length in the next section on list server integration.

In general, what is needed is a batch function that examines all users created via the online registration process which then determines these users current access. The batch process cannot process all NT users as there are likely to be users created by normal administrative processes and not via the online registration. Specifically administrators, server operators and web content developers are created outside the registration process and have access to the web site quite different than that provided members via the online registration process. It's worth noting that the registration process operates as the anonymous user which is defined as an NT account operator. An account operator can create and delete users but only users with no administrator or operator privileges. This is believed to be safer and more secure than the alternative of storing an administrator password somewhere on the server that the registration process would use to change its user context to an administrator account context.

Also the batch process cannot process all member records because most members have never registered and do not have matching NT users. The online registration process maintains a file that correlates NT user names with ATLA member IDs. It's that file that the batch process uses and for each entry in it, finds the corresponding member record and NT user record. As long as the member remains active and eligible to use the site the NT user record is kept. If the member lapses, the NT user record is removed and an email composed notifying the former user that their access to the web site has been disabled and explaining why and what to do to regain access. As long as the member remains eligible, then all NT user groups are compared against the codes in the member record and the table of member codes and corresponding NT user groups. The NT user is added to or removed from NT user groups based on the current codes in their member record. This allows the NT OS to grant or deny access to all static web pages based on current membership status.

Top of Page - Site Map

Copyright © 2000 - 2014 by George Shaffer. This material may be distributed only subject to the terms and conditions set forth in https://geodsoft.com/terms.htm (or https://geodsoft.com/cgi-bin/terms.pl). These terms are subject to change. Distribution is subject to the current terms, or at the choice of the distributor, those in an earlier, digitally signed electronic copy of https://geodsoft.com/terms.htm (or cgi-bin/terms.pl) from the time of the distribution. Distribution of substantively modified versions of GeodSoft content is prohibited without the explicit written permission of George Shaffer. Distribution of the work or derivatives of the work, in whole or in part, for commercial purposes is prohibited unless prior written permission is obtained from George Shaffer. Distribution in accordance with these terms, for unrestricted and uncompensated public access, non profit, or internal company use is allowed.