Rule-based authentication use cases

Multiple realm use case 1: Domain acquired; explicit proxy

Multiple realm use case 2: Internal domain added; explicit proxy

Multiple realm use case 3: Temporary domain added; transparent proxy

Multiple realm use case 1: Domain acquired; explicit proxy

This describes a common case in which a second domain is added to an existing, single-domain environment.Content Gateway is an explicit proxy; clients use a PAC file.

An organization—let's call them Quality Corp—uses a software installation of Content Gateway. They have one domain (QCORP), and one domain controller. They use NTLM to authenticate users.

Quality Corp acquires New Corp who has their own domain (NCORP) and domain controller. They use LDAP to authenticate users.

Quality Corp would like to manage the combined employees in a single domain, but they aren't ready to make the infrastructure changes. Until they are, they would like to have a separate use policy for New Corp users (i.e., not use the "default" user on the QCORP domain).

Rule-based authentication makes this possible.

To configure the solution, Quality Corp would:

Enable Rule-Based Authentication.

Add a second, non-default HTTP port (Configure > Protocols > HTTP > General). This port will be used by all members of NCORP.

Create a PAC file for members of NCORP that causes them to connect to Content Gateway on the new, second port.

Create authentication rules, one each for the QCORP and NCORP domains:

On Configure > Security > Access Control > Domains, add the QCORP and NCORP domains to the Domains list.

When adding NCORP, use the Aliasing option to specify "NCorpUser" for use in policy determination.

On Configure > Security > Access Control > Authentication Rules, create an NCORP rule for connections on the second port. You must know the IP addresses/ranges of New Corp users, and specify the NCORP domain.

Define the QCORP rule to handle all other connections.

In Web Security manager, add "NCorpUser" to the QCORP domain as a valid user and create policy for that user.

At this point, everyone connecting to Content Gateway from NCORP is authenticated against the NCORP domain controller and gets the group policy associated with NCorpUser. Note that no individual user-based policy or features, such as quota time, are possible in this scenario. Transactions are logged as NCorpUser. This is all performed with no effect on the authentication, policy, or logging of users on the QCORP domain.

Multiple realm use case 2: Internal domain added; explicit proxy

This describes a common case in which a second domain is added to an existing, single-domain environment. Content Gateway is an explicit proxy; clients use a PAC file.

An organization—let's call it BigStars—uses a software installation of Content Gateway. They have one domain (BIG), and one domain controller. They use NTLM to authenticate users.

A group in the company converts to Apple computers, which can't be authenticated with NTLM. The IT group installs an LDAP server and creates a new domain—BIGAPL—for the Apple users.

Because this group of users previously existed and was managed on the primary domain (BIG), the IT department expects that both user-based policy and logging still apply.

The Rule-Based Authentication feature makes this possible.

To configure the solution, BigStars would:

Verify that every user in BIGAPL is also in BIG with the exact same user name.

Enable Rule-Based Authentication.

Add a second, non-default HTTP port (Configure > Protocols > HTTP). This port will be used by all members of BIGAPL.

Create a PAC file for members of BIGAPL that causes them to connect to Content Gateway on the new, second port.

Create authentication rules, one each for the BIGAPL and BIG domains.

On Configure > Security > Access Control > Domains, add the BIGAPL and BIG domains to the Domains list.

On Configure > Security > Access Control > Authentication Rules, create a BIGAPL rule for connections on the second port.

Define the BIG rule to handle all other connections.

At this point, all members of BIGAPL are authenticated with LDAP, but maintain their individual policy as specified by their existing NTLM identities. Logs and reports also refer to that same user.

Multiple realm use case 3: Temporary domain added; transparent proxy

This describes a common case in which a second, special-purpose domain is added to an existing, single-domain environment. Content Gateway is a transparent proxy using WCCP v2.

An organization—let's call it Creative Corp—uses a software installation of Content Gateway. They have one domain (CCORP), and one domain controller. They use NTLM to authenticate users.

Creative Corp is about to launch a new product and wants to make a big splash. They decide to have an open house complete with kiosks, demonstrations, and presenters. The kiosks only need the default Internet policy to properly demonstrate the new product. The IT manager wants to keep the kiosk network as walled off from the corporate intranet as possible. In this scenario, logging individual users isn't a requirement.

The Rule-Based Authentication feature makes this possible.

To configure the solution, Creative Corp would:

Build a new, temporary network complete with its own domain controller. Let's call this domain CTEMP.

Add one or more users to CTEMP. They can either match one-to-one with existing users on the primary domain, or be one or more generic users for use by the presenters.

Redirect Internet traffic on CTEMP to Content Gateway with WCCP v2.

Enable Rule-Based Authentication.

Create authentication rules, one each for the CTEMP and CCORP domains:

On Configure > Security > Access Control > Domains, add the CTEMP domain, enable Aliasing and leave the name field blank. This will have the result of applying the Default policy to all users of CTEMP.

Add the CCORP domain to the Domains list.

On Configure > Security > Access Control > Authentication Rules, create a CTEMP rule to apply to all connections coming from the IP address range assigned to the CTEMP domain.

Define the CCORP rule to handle all other connections.

At this point, anyone using the Internet on one of the kiosks is authenticated against the CTEMP network and has the Default policy applied to their requests.