Implementation

As stated above, load balancing is not an inherent problem within PortalGuard due to its design. The question of how to load balance PortalGuard is effectively reduced to the question:

How do you load balance a .NET application on IIS?

Since this is such a relatively generic topic, different companies and customers have different ideas about how to do this. Please consider the following areas.

Network

The primary considerations here are:

  • What device handles SSL session negotiation?
  • How is load spread among front-end HTTP servers?

These questions typically have the same answer: a hardware-based load balancer. Concentrating SSL connections to a specific device reduces the number and/or cost of 3rd party SSL certificates which would typically be used when supporting external customers. Most of our customers utilize hardware-based solutions like F5’s BIG-IP or Cisco. PortalGuard does not have a specific recommendation here because each company has different requirements and most already have a device that handles this.

For configuration of the network proxy, an important note to remember is that “sticky sessions” are not required by PortalGuard. This is due to PortalGuard’s RESTful design and allows different steps of a PortalGuard action (e.g. account unlock) to be handled by different PortalGuard/IIS instances.

It is also important that any device or appliance placed in front of PortalGuard should offer protection against attacks such as port-scanning and denial of service. It is much more efficient and effective to have these attacks prevented at this level by a specialized device or solution.

PortalGuard Data

PortalGuard maintains its own data to track user state and configuration. The data is categorized as follows:

User Profile Data

This is where PortalGuard stores information like phone number and provider, hashed challenge answers and “last login” timestamps (all based on configured features). Please see this earlier section for more specifics on user profile data. This data is constantly updated and plays the largest role in ensuring a consistent user experience.

User profile data can be stored in flat files on the PortalGuard server or in SQL. The default behavior is to store user profile data in flat files as it is effective for quickly standing up a PortalGuard deployment and works well for user populations up to a few thousand users. Management of these files becomes more unwieldy around the 2000 user mark so it is recommended that the data be stored in SQL if you anticipate this many user accounts.

Load balanced architectures must be configured to store the user profile data in SQL. Storing the data in SQL allows it to be shared concurrently by multiple PortalGuard instances. Please see the SQL section below for more specifics about PortalGuard’s user profile data in SQL.

Repository Configurations

These configurations control how the PortalGuard server will contact the user repository, be it Active Directory, LDAP or SQL. It also contains the account credentials used to establish these connections.

The following points about repository configurations should be considered:

  • They can only be stored in flat files, not SQL
  • They are text files stored in the “<PG_Root>\Policies” folder and end with a “.sysdir” file extension
  • They should rarely be changed after initial setup, if at all. If your find yourself constantly changing these, please contact PortalGuard support for help.
  • Windows file ACLs can be used to restrict which admins can modify these files

NOTE: PortalGuard’s IIS application pool identity must have Read access

  • A formal change control process is recommended to ensure changes are tracked outside of PortalGuard. This can also serve as a form of “version control” should someone accidentally make a breaking change.
  • They should only be editing using PG_Config.exe, but they can be copied from one server to another using the OS.
  • Starting in PortalGuard version 4.0, changes to repository configurations will not affect users until manually “applied” through PG_Config.exe -OR- until the IIS worker process restarts (which could occur due to inactivity timeouts or scheduled recycling based on IIS settings). In versions of PortalGuard prior to v4, changes took effect immediately with no need to restart the IIS server but performance was much slower as a result.
  • Starting in PortalGuard version 4.0, PG_Config.exe has a feature to copy all configuration files to multiple PortalGuard servers and apply them to the running/in-memory configuration of each:

  • Automated file synchronization/mirroring software is not recommended and should not be required due to how infrequently they change.

Security Policies

Security policies control what features are enabled for PortalGuard users. Please see this earlier section for more specifics about PortalGuard’s security policies. Coupled with user profile data, security policies have the biggest impact on the end-user experience with PortalGuard.

Policies can be applied to entire groups of users by specifying the group name from the user repository explicitly in the PortalGuard security policy. It is considered a “best practice” to create a specific “master” group in your user repository for each PortalGuard security policy. Assign only this master group in the PortalGuard security policy. In the user repository, add all specific groups of users that should have this policy applied to them as subgroups of the master group. This effectively eliminates changes of PortalGuard’s security policy related to user membership.

Security policies have nearly identical parameters as PortalGuard’s repository configurations. The following points about security policies should be considered:

  • They can only be stored in flat files, not SQL
  • They are text files stored in the “<PG_Root>\Policies” folder and end with a “.txt” file extension
  • They should rarely be changed after initial setup, if at all. If your find yourself constantly changing these, please contact PortalGuard support to identify a better approach.
  • Windows file ACLs can be used to restrict which admins can modify these files

NOTE: PortalGuard’s IIS application pool identity must have Read access

  • A formal change control process is recommended to ensure changes are tracked outside of PortalGuard. This can also serve as a form of “version control” should someone accidentally make a breaking change.
  • They should only be editing using PG_Config.exe, but they can be copied from one server to another using the OS.
  • Starting in PortalGuard version 4.0, changes to security policies will not affect users until manually “applied” through PG_Config.exe -OR- until the IIS worker process restarts (which could occur due to inactivity timeouts or scheduled recycling based on IIS settings). In versions of PortalGuard prior to v4, changes took effect immediately with no need to restart the IIS server but performance was much slower as a result.
  • Starting in PortalGuard version 4.0, PG_Config.exe has a feature to copy all configuration files to multiple PortalGuard servers and apply them to the running/in-memory configuration of each:

  • Automated file synchronization software is not recommended for load balanced instances and should not be required due to how infrequently they change.

Bootstrap Configuration

The PortalGuard bootstrap contains service specific information that is shared across all security policies. Examples of this include SMTP configuration, SQL ODBC data source/login credentials and YubiKey or CAPTCHA service keys.

The bootstrap is contained within a single text file whose location is specified by the %PS_PG_BOOTSTRAP_FILE% environment variable. The following points about the bootstrap should be considered:

  • It is only stored in a flat file
  • This file can be copied from one server to another as long as the folder structure of the PortalGuard servers is the same.
  • Other than file paths, it contains no server-specific information
  • It should be changed very infrequently
  • Formal change control is recommended
  • Use of explicit ACLs can be done if needed (PortalGuard only needs Read access)
  • Automated file synchronization is not recommended for load balanced instances
  • Starting in PortalGuard version 4.0, changes to the bootstrap configuration will not affect users until manually “applied” through PG_Config.exe -OR- until the IIS worker process restarts (which could occur due to inactivity timeouts or scheduled recycling based on IIS settings). In versions of PortalGuard prior to v4, changes took effect immediately with no need to restart the IIS server but performance was much slower as a result.
  • Starting in PortalGuard version 4.0, PG_Config.exe has a feature to copy all configuration files (including the bootstrap) to multiple PortalGuard servers and apply them to the running/in-memory configuration of each:

Internet Information Services (IIS)

As stated above, PortalGuard on IIS is effectively a very lean .NET application. Part of what makes it “lean” is that it does not utilize .NET view state or session state (which would ordinarily be used once a user has logged in). As such, all of IIS’s session state options (InProc, StateServer, SQL server, custom) can be effectively ignored. This is a key point that ensures different PortalGuard servers can easily handle any part of a larger PortalGuard “action”.

The PortalGuard IIS website is configured to use .NET’s Forms-Based Authentication (FBA). Once a user has logged in, IIS creates and maintains their user identity with a session-based HTTP cookie (default name: “.ASPXAUTH”). PortalGuard uses this cookie alone to determine the authenticated name for the user when performing any “post login” actions such as modifying challenge answers or enrolling a hardware token. By using a load balanced server alias (e.g. “pwreset.acme.com”) each PortalGuard IIS server in the load balanced cluster should automatically receive this HTTP cookie.

The lone consideration for IIS load balancing is that IIS’s FBA cookies and form viewstate are encrypted and checked using the IIS server’s validation and decryption keys. These can be manually set and must be identical across all PortalGuard IIS servers in a load balanced configuration. This allows an FBA cookie created by one PortalGuard IIS server to be honored by the other PortalGuard IIS server(s). Please see this MSDN article for information about synchronizing these keys across the servers in a web farm.

SQL

As stated above, PortalGuard must be configured to store user profile data in SQL to support load balancing. However, PortalGuard does not leverage a complex relational design. The standard “normalized” form for SQL data utilizing multiple tables joined by foreign keys does not suit PortalGuard because additional fields are always required for storing data associated with new features. This approach was abandoned early in favor of an opaque XML column for user data. Now, user profile data is read out as an opaque XML string, manipulated by PortalGuard internally then written back as opaque XML if any updates were made. This design is extremely flexible and does not require schema upgrades or the data export/import process associated with it. Fittingly, PortalGuard has not changed its SQL DDL since cutting over to this model.

Here are the SQL tables in the current schema:

  1. HDLogging (more info) – Stores audit data for actions performed through PortalGuard’s Help Desk application. Rows are only created in this table, never updated.
  2. RBAEvents (more info) – Stores logging information for each PortalGuard action performed by end users when “Credibility-based Authentication” is enabled. Rows are only created in this table, never updated.
  3. UserProfile (more info) – Stores all user-specific data using an XML typed data column. Rows in this table are constantly updated with new rows being added automatically for first-time users of PortalGuard.

Due to the use of an XML typed data column, PortalGuard requires use of Microsoft SQL Server 2005 or later. The Express versions of SQL Server are supported.

All reads and writes of the PortalGuard tables leverage stored procedures to ensure rigid type checking and help defend against SQL injection attacks. Furthermore, PortalGuard’s SQL implementation does not utilize complex views or put undue strain on the SQL server’s indexer. Both logging tables above leverage identity columns as their primary key and the UserProfile table alone employs a text-based username column as its primary key with an XML index on the data column.

SQL clustering is not necessarily required, but makes sense if load balancing is being implemented to ensure no “single point of failure”. Best practices for load balancing Microsoft SQL server are outside the scope of this document but Microsoft support has ample resources available on this topic. Some potential starting points are:

http://support.microsoft.com/kb/254321

http://www.sqlskills.com/whitepapers.asp

Lastly, data archiving must be done manually by the DBA as PortalGuard does not perform this natively. The frequency with which this must be done is largely based on how temporal user accounts are in your environment. A general rule of thumb would be to revisit it annually using the “Modified” column of the UserProfile table to determine when each user record was last used/accessed.

As noted in the Background section, ODBC is used to isolate PortalGuard from the specifics of SQL connectivity. DBAs can control which ports are used to connect to SQL based solely on the ODBC configuration.

Caching

The framework files for the PortalGuard user interface encompasses the only “static” content for the entire product. This includes the images, CSS and JavaScript files found in the “<IIS_Root>\PortalGuard\_layouts\images\PG” folder. These are the only files that can be cached by an external web server such as a reverse proxy.

PortalGuard also can be classified as an “infrequently used” application since the user typically only interacts with it during authentication. All standard transactions between the user and PortalGuard server contain sensitive, user-specific information. As such, we do not recommend any form of caching outside of what happens via the standard HTTP protocol.