Note that these directions only apply for sites that were created AFTER January 15th, 2011. Sites created prior to this date may be using a "legacy" configuration that may differ from the following.
Sites that utilize CU WebAuth are required to use SSL.
There are two options for having an SSL configured. One is referred to as "HTTPS" and one as "BOTH".
If you wish to have ALL traffic protected by SSL we recommend that you request "HTTPS" for the protocol. This will create a redirect so that any traffic that goes to //[my site]/ will be redirected to //[my site]/.
In some cases you may wish to only have a portion of your site protected by SSL while the option portion is not. In this case if you specify "BOTH" then you will be responsible for determining whether a page can be displayed using SSL or non-SSL.
When using "BOTH" non-SSL connections have NO restrictions, that means that all files are publicly available unless you explicitly put in a ".htaccess" to protect the directory using CU WebAuth.
Some examples of restricting access via a ".htaccess" file:
Require SSL (will just cause a 403 error)
SSLRequireSSL
Redirect to SSL
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}/$1
Note that if you protect a directory with CU WebAuth and you go to the non-SSL site you will get the following error "CUWebAuth error... Server is not properly configured. Check the Kerberos principal.". In this case you need to be sure to specify the "https" URL and not the "http" URL to avoid getting the error. If you wish to setup a redirect from the non-SSL site to the SSL site for the ".htaccess" protected directory you'll either need to specify the redirect in a parent directory or via a custom vhost include.
Migrating from a "legacy" configuration
If your website was created prior to January 15th, you may need to update your ".htaccess" files to conform with the requirement that CUWebAuth is only configured for SSL sites. The need to update configurations can likely occur if you previously had both public/private portions of your website and used CUWebAuth to protect portions of your site. If ALL of your content is CUWebAuth protected then we recommend a configuration of "HTTPS" which will redirect all traffic to SSL and preserve the behavior that previously existed. If you have the need to have both public/private portions of your site then you'll likely need to following the following.
The following is technical information on how to update existing configurations.
Prior to January 15th the configuration for CUWebAuth took the position of all content was CUWebAuth protected and you would need to explicitly disable CUWebAuth to enable access to the public. The new configuration takes that reverse position that CUWebAuth is disabled for non-SSL traffic and SSL traffic is configured similar to the previous configuration of CUWebAuth is enabled by default.
This can create problems with existing configurations and you may need to update your sites ".htaccess" files to conform to the new configuration.
Example of a problem configuration #1 (require noprompt)
Some websites, in particular CommonSpot sites, have a ".htaccess" file that contains the following:
AuthName Cornell AuthType All require noprompt
This will case a problem for new "HTTP" configurations since CUWebAuth is not loaded for non-SSL traffic. One possible fix is to remove "require noprompt" if you wish to have no CUWebAuth protection.
Example of a problem configuration #2 (require netid or permit)
Some websites will have a sub-directory that contains something like the following:
htdocs/mysite/secure/.htaccess: AuthName Cornell AuthType All require permit my.group
In this case this configuration will NOT work with non-SSL traffic. You will need to ensure that an SSL certificate is obtained for your site and that CUWebAuth is enabled. Once you have SSL enabled you may notice that requests to the secure directory using http will generate a 500 error while requests to the https directory will work. One option is to create a redirect for non-SSL traffic using the top-level ".htaccess" file, i.e.:
htdocs/mysite/secure/.htaccess:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^secure/(.*) https://%{HTTP_HOST}%{REQUEST_URI}/secure/$1