You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

The page "Restricting and Opening Access to Your Site" has general information about utilizing CU WebAuth: https://confluence.cornell.edu/x/hc9gBg.

This page is meant to provide some technical details on options of how to secure your website. 

  1. Application based authorization
  2. Public/Private sites
  3. .htaccess vs. Directory vs. Location Restrictions
  4. Suggested layout for Public site
  5. Suggested layout for Restricted site

1. Application based authorization

This is the preferred method of performing authorization on an application is to either check the NetID or permit against a known authorization list.  This ensure that if the application is ever placed into a data area that is not protected CU WebAuth it will not inadvertently share privileged information.

2. Public/Private sites

In some cases you may want to have non-SSL public site and a private SSL protected site that uses the same name.  This can be accomplished by following the directions at https://confluence.cornell.edu/x/9QobCg.  SPECIAL care should be taken to ensure that content that private content is protected.  It is possible to have content that IS protected by CU WebAuth on the SSL portion of a website to NOT be protected on the non-SSL portion of the website.  This makes sense for a content management system where you want to have a public portion and restricted administrative function, but can be a DISASTER if you do not do application based authorization.  This can be a very tricky configuration and special care should be taken to ensure that it is down properly.

3. .htaccess vs. Directory vs. Location Restrictions

In CF9 there are now 3 different ways that you can configure authorization!  This may seem really confusing, but there is a reason that all 3 are supported.

  • .htaccess
    This is the traditional method of restricting a directory and can be used to limit access to a website. 
  • Directory
    Using a Customer VirtualHost include it is possible to set a "Directory" level restriction in the Apache VirtualHost configuration.  This can work effectively the same as a ".htaccess" file, but is stored in the server configuration.
  • Location
    A Location block is independent of directory structure and may be necessary if you have a script/process that does not map to a physical directory.  For ColdFusion this is less of a issue, but it is documented for completeness.

Be VERY VERY careful if you choose to mix any of the above.  It is possible to have competing configurations that override each other.  This is especially true if you have multiple virtualhosts that map to the same data directory.  It is best to choose one of the above options and use it consistently to avoid issues.

4. Suggested layout for public site

If you are going to have a mixture of both public and private data it is recommended to not specify a top-level ".htaccess" file, but instead only explicitly protect content either through application authorization or protected sub-directories.  A layout could look like:

htdocs/site1/index.cfm
htdocs/site1/secure_pdfs/.htaccess
htdocs/site1/secure_pdfs/private.pdf

In the above example the ".htaccess" file contains:

AuthName Cornell
AuthType All
AuthBasicAuthoritative off
require permit cit.coldfusion.support

The "index.cfm" contains:

  • No labels