Page History

...

Information about university data policy can be found at: http://www.it.cornell.edu/security/data/index.cfm^{Image Removed}

General information about application security can be found at: https://www.owasp.org^{Image Removed}

This page is meant to provide some technical details on options of how to secure your website while using the Hosting CF9 environment. 

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
6. Satisfy any/all
7. Tests/Examples

1. Application based authorization

...

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 done properly.

...

In this example this also allows you to have "site1.cornell.edu that is "public" and "site2.cornell.edu" that is restricted like below. Be careful not to place a top-level ".htaccess" file.

...

5. Suggested layout for a restricted site

If all your access is going to require authentication it is still a best practice to utilize application based authorization, but you have further options if you want to restrict all your sites.  If you want to restrict all your sites you can place a top-level ".htaccess" file in your htdocs directory.

...

Unlike in the previous example both site1/site2 will inherit the permission that is set in the top-level restricted directory. You can only further restrict sub-directories using CU WebAuth. So it is not possible to limit the entire site to "staff" and then try and make a sub-directory accessible by "students"!

6. Satsify any/all

If you need to open access to the top-level of your SSL site, but want to secure sub-directories in your site you need to do a careful mixture of "satisfy any" and "satisfy all".

To open up access at the top:

htdocs/site1/.htaccess:
satisfy any

to protect a sub directory:

htdocs/site1/secure/.htaccess:
satisfy all
require netid emc256

Note that if you do not add "satisfy all" the "secure" directory will not be protected!

7. Tests/Examples

The attached zip file.  Provides some tests/examples of using CU WebAuth.   To use the examples you will need to upload the contents of the zip file so that it can be accessed at: https://\[your website]/cuwebauth_test/