What is Central Authentication Service (CAS)?

From Wikipedia (Central Authentication Service):

The Central Authentication Service (CAS) is a single sign-on protocol for the web.[1] Its purpose is to permit a user to access multiple applications while providing their credentials (such as userid and password) only once. It also allows web applications to authenticate users without gaining access to a user's security credentials, such as a password. The name CAS also refers to a software package[1] that implements this protocol.

Georgia Tech implements the CAS service to allow campus members to easily log into campus websites using their GT Account Username and associated password.  However, for a website to utilize CAS, it must be set up correctly, which usually means adding a module, plugin, or library, and configuring it to work with Georgia Tech's CAS servers.

• Setting up CAS for Drupal 7 and 8 - Georgia Tech Drupal Article
• Setting up CAS for WordPress
• Setting up CAS for a stand-alone PHP application
• Setting up CAS for a static website on OIT Web Hosting - OIT FAQ Article

CAS Sub-Topics

With changes to web browsers (Chrome in particular) coming soon that will mark non-SSL (http://) websites as Not secure, now is the time to consider upgrading your site to SSL encryption.  The first part is getting an SSL certificate and adding it to your hosting account.  However, you also have to check through and adjust your site for optimal results.

In most cases, switching to SSL will not outright break a site, but its not impossible in some cases:

• Chrome and possibly some other browsers will not show a non-SSL page in an IFRAME of an SSL page.  Unlike other types of security issues, Chrome will not let the user bypass or ignore the issue on non-SSL page in an IFRAME, so the user will be completely blocked from getting to the IFRAMEd content.

• Custom code might break if it dissects page URLs and doesn't treat "http://" and "https://" as the same site, or has been coded to only work with http:// URLs.

The more common issue is a page being flagged as having mixed content, which means that something included on an SSL encrypted page (an image, a video embed, a CSS file, a JavaScript file, etc.) is being loaded from a non-encrypted site.  A lot of times, this is due to a local resource having been added to the page with a fully qualified URL (e.g. http://foobar.gatech.edu/styles.css) instead of using a relative URL (e.g. /styles.css).  Updating those URLs will fix the problem, though finding them can be a challenge.  Getting comfortable with your favorite browser's development inspector can help a lot, as many have a Network feature to let you see all of the files being loaded by the page and which ones were SSL encrypted and which ones were not.

There are other places you should check to optimize your site:

• Menu bars often have fully qualified links added to them, so check for ones that can either be shortened to a relative link or updated from "http://" to "https://"

• Redirects in .htaccess files are sometimes entered as fully qualified links.  Once again, they should be made relative or updated from "http://" to "https://".  If your content management system has its own redirection system (e.g. the Drupal 7/8 Redirect module), you may need to check its tables for URLs that need to be updated in the same way.

Certain applications may need a little assistance:

• WordPress has two settings on the General settings page:  WordPress Address (URL) and Site Address (URL).  Both need to be updated to begin with "https://"

In most cases, you'll not only want to clean up the links and settings of your site, but also redirect all of your non-SSL traffic to your SSL site, and content systems don't typically handle this for you.  To cover all of your bases, it's good to add the following to your site's .htaccess file, ahead of any other Rewrite Engine rules:

RewriteEngine on
# This forces the visitor to the non-www.* address *before* forcing them to SSL
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [L,R=301]
# This checks to make sure the connection is not already HTTPS
RewriteCond %{HTTPS} !=on
# This rule will redirect users from their original location, to the same location but using HTTPS.
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]

One final tip: if you control any other websites that link to the site you're upgrading, you should go into them and update those links from "http://" to "https://", and also make sure they're using the version of your site's domain name that matches your SSL certificate (in most cases, this will be a version without "www." at the beginning.)

SSL encryption (technically Transport Layer Security, but still commonly referenced as SSL, the acronym for its now deprecated predecessor) is a protocol for encrypting communications between a web browser and a web server. Encrypted connections (denoted by a web URL starting with 'https://') are not easily monitored by third parties unlike unencrypted connections (denoted by a web URL starting with 'http://'), where all content can be easily viewed by anyone with access to some part of the connection path. SSL works through a system of public-key cryptography, and is intended to not only keep communications private, but to also help ensure that you are actually communicating with the right server and not a hacker's rogue server that is merely impersonating a legitimate server.

By default, SSL is provided and available on OIT Webhosting, and can be enabled other types of on-campus web hosting where you or your information technology support staff have low-level management access to the web server.

SSL Certificates

In order to enable SSL encryption for a website, you need to have an SSL certificate that securely identifies that your server is the genuine server for your website's domain name. There are many possibilities for obtaining an SSL certificate – too many to list here.

Presently, Georgia Tech is a member of InCommon, a collective of universities which have pooled resources. This means campus units can get SSL certificates for free. Usually one person in a department, college and/or school has the ability to request and issue certificates. Ask your information technology support staff for assistance if you need a certificate for a web site.

InCommon Certificate Caveats

• Georgia Tech's InCommon account can issue certificates for sub domains of Georgia Tech (addresses that end in .gatech.edu) as well as non-Georgia Tech domains. If you need a certificate for a non-Georgia Tech domain, you will need to contact the InCommon admins who will assist with granting authority to sign the non-Georgia Tech domain, and provide instructions on verifying the ownership of the non-Georgia Tech domain. This is usually accomplished by uploading a unique key file to your site's docroot for verification.
• If your site is on OIT Web Hosting, you may not need a certificate, as web hosting has a 'wildcard' / multi-site certificate that covers a lot of common Georgia Tech sub domains, and they are often willing to add additional Georgia Tech sub domains if you ask. Please see the OIT FAQ Article on SSL Certificates and Web Hosting for more information.
• As of now OIT Web Hosting only allows creation of 2048 bit certificates. Most security standards now call for a minimum of 4096 bit SSL certificates.

Other Types of SSL Certificates

Before InCommon, there were several options for SSL certificates. You may stumble across them:

• Paid SSL certificates - Issued by GoDaddy, Thawte, Comodo and others.
• Self signed certificates - Generated and signed on the server that hosts them.  These are fine for development, but should never be used in production, as users will get a certificate error message in their browser when accessing a site with a self-signed certificate.
• Georgia Tech Signed certificates - For many years, Georgia Tech had its own root certificate.  It's no longer used, but may still be on systems.  If you find this, you should remove it, as the root certificate has expired, as have any certificates signed by that root certificate.

Implementing SSL Encryption

• Enabling and Using SSL Encryption on OIT Web Hosting

Patch, Patch, Patch

The most important security practice for web application software is to keep up with your software patches.  The more commonly used the application, the greater a chance that someone out there is looking for insecure installations to hack.

Systems like Drupal and WordPress are so popular that you need to be prepared to deploy security patches for them just as soon as they come out.  If your hosting server is running Installatron, you can configure it to automatically install many of these updates.  If you don't have Installatron, you can still configure WordPress to automatically install new updates on its own.  Drupal, unfortunately, requires manual intervention if you don't have an outside tool like Installatron, but modules can usually be updated from within the application.  Drupal core updates have to be installed from the command line or from a web hosting file manager control panel.

Non-security patches can be important, too, but should be tested more thoroughly before deployment since they could break things.  (Security patches could break things, too, but sometimes it may be better to break a small feature of your site temporarily than to leave it susceptible to a known vulnerability.)

Lock Down Site Access

Securing the back doors to your site is pointless if you leave the front door wide open.  Make sure you have configured your web application properly so that only the proper authorized people can access it.  

• Consider user roles carefully and don't give out more access privileges than are necessary.
• Audit user access lists and remove users who no longer need access (employees who no longer work for your unit, students who have graduated, anyone who has moved to a different role that doesn't need to use the application.)
• Besides auditing access lists within web applications, also audit the access lists for their server hosting accounts as well.  Make sure that the people with access to administer those accounts still have reason to be doing so.  Take old developers off of these accounts if they aren't actively working for you, even if you think you'll bring them back in later, and remove anyone who has left Georgia Tech, as they could potentially still be able to get to your hosting account even after many of their standard IT privileges have expired.
• If you implement a configuration where anyone with a GT Account can log into your application, be very careful about what you make available to these 'regular' users.  Keep in mind that when you include all GT Accounts, you include all guest users, outside vendors and developers who are doing work for Georgia Tech units, retirees, alumni, etc.  That's a pretty big pool of people.  If you really don't need to include all of those people, look into options for validating that someone logging in is a current faculty/staff member or student.
• If you add custom security modules to content systems like Drupal and WordPress, don't just assume they work as you have configured them:  open a different browser and test to make sure a non-logged in user really can't get to the content you are trying to protect.  A security configuration that doesn't actually work is worthless.

Run a Tight Ship

Module and plugin based applications like Drupal and WordPress have one distinct downside:  not all modules and plugins are created equal, and poorly written and managed ones can put your application at risk.

Before installing a module or plugin, review it carefully.  Avoid ones that do not have active support, ones that haven't been updated in several years, and ones that have never left alpha/beta status.  It's usually better to tell a stakeholder that there's nothing available to provide a certain functionality than to offer up a module or plugin that isn't stable and risks introducing security holes.  It's also far better to say no up front than to try something that stakeholders get used to, only to later discover a serious uncorrectable problem that necessitates removing the plugin/module.

Avoid Frankensites

What's a Frankensite?  It's a module/plugin based web application where so many extra components have been added to it that it's impossible to properly audit the functionality of the site.  Upgrading these sites can either become impossible, or strokes of pure luck if a major update doesn't break several things at once.

When any kind of complex functionality is required, look at abstracting that functionality out to a separate application that can run in parallel with the main application.  For example, if you are running a Drupal site and your stakeholders want a nice photo album, don't load up the Drupal site with the half-dozen extra modules needed to make a barely functional internal photo album system.  Instead, set up a copy of ZenPhoto, which is designed from the ground up to handle photo albums.  Or, suggest the usage of a hosted in-the-cloud system.  Any of these options will keep your main website application from turning into an unmanageable Frankensite.

(Setting up multiple applications may seem like more work at first glance, but it's far less work in the long run, as you'll be able to streamline the installation of updates, not to mention that you can update the secondary applications one at a time without having to bring down any others or the main application/site.)

Enable and Monitor Security Logs

Many applications and all hosting account systems will log different kinds of activity related to your web application.  While a lot of these logs may seem unreadable to the untrained person, they could still be invaluable should a problem arise - especially a security incident.  It's a good idea to keep these logs around for at least six months, and even longer if your application handles any sensitive data.  Check the Georgia Tech data security policy to find institute requirements and recommendations for log retention.

When possible, sending logs to a remote server is a really good idea, as that prevents those remote copies from being modified by a hacker who gets too far into your web server.

Make Regular Site Backups

Nothing is worse than having a site crash without a recent backup available.  Whether the crash was due to a patch gone bad or a hacker getting into the site, being able to restore the site to a previously known good state is critical.  Here are some recommended guidelines for handling backups:

• For all sites, run a full backup once a week, and for important sites, also run an incremental backup daily.
• Store backups in a safe location, ideally on a remote server.  If possible, configure your infrastructure so that the web server can't modify a backup once it's been written to the remote server, so that a hacker who breaks into the web server can't delete your backups.
• TEST your backups!  Far too many a systems administrator has been bitten hard by backup files that were corrupted, missing important components, or even just plain missing because the backup process didn't write out the files as expected.  After running your first backup, download the files and try to recreate the website in a test environment to make sure you have a complete backup of the site.  And, don't forget to check the backup archives periodically to make sure they're still functioning as you expect.
• Be sure to cycle out old backup files periodically, so that your backup system doesn't run out of disk space.  This is yet another way to discover that you have no recent backups when you need them the most.

Install and Utilize Security Tools

Some applications may have third-party tools to help you monitor for security problems.  A good, reliable security tool can block many types of known attacks, stop brute-force login attempts, log more details about accesses to the site, and/or point out configuration settings that you ought to change to make the site more secure.

Since every application is unique, you'll have to research the available security tools that work with a specific applications.  Be sure to look at how well respected the tool is within the user community, as that will give you an idea of how safe and reliable it will be.

There are also server level security tools that you can utilize, such as Web Application Firewalls (WAFs).  These have to be installed by a server administrator, but can add an extra layer of protection beyond the tools available for the specific application(s) you are running.  The OIT Web Hosting servers all run a WAF that protects their hosting accounts by filtering any requests coming from off-campus.

Write Safe Code

If you are coding applications for the web or even just coding modules / plugins / themes for existing applications, take the time to write safe code:

• Sanitize any user input that you utilize to deter hackers from running malicious commands by submitting carefully crafted values into a form field.
• Use proper security wrapping methods to make sure that authorization is being checked properly before the execution of any higher level command.
• Avoid putting in a backdoor "just for testing", as it can be all too easy to forget to remove it later.  If you must use one, document it boldly and clearly so that it's easy to detect when you review the code later.
• Do carefully review your code before putting it into production, and even better, have someone else review it as well, since they might catch bugs that aren't obvious to you.
• Always keep a copy of your code on a separate server, so that if your development or production servers get hacked, you can run a code comparison to your protected code to see if anything was changed by the hackers.

Clean Up After Yourself

Leaving junk behind in your public web hosting account directories can cause multiple problems, so keep your public directories clean:

• When installing code updates, keep the installers out of your public directories, or at least move them out once you are finished with the update.  If your hosting account doesn't already have a private directory, create one and use it for installers, backups, etc.
• If you edit live code, don't leave any backup copies in the live directories.  If you need to make a backup of a file before editing it, put the copy in a private directory.  There are many ways in which an improperly named backup file could accidentally expose the program code to a hacker, and depending on the file, this could expose internal user account credentials, shared secrets, or internal server names, all of which could be quite valuable to a hacker.
• If you run a major update and want to move your current installation to a different folder, once again move it somewhere inside a private (non-public) directory, especially if there is no need to be able to access the old installation over the web.  If you do need to leave the old installation up temporarily, plan a date at which it will be shut down, and if at all possible, firewall that directory for the interim to just on-campus IP addresses (or if possible, just IP addresses for your local unit).  Old installations usually never get patched, and thus can become huge forgotten security holes if left publicly accessible over the web.
• Security precautions aside, keeping your public web directories neatly cleaned up will help you in many other ways, including making it easier to debug problems and in some cases even speeding up application performance.