synapses-cas 0.1.0

data/CHANGELOG

@@ -0,0 +1,3 @@
+=== 0.1.0 :: 2012-05-10
+
+* First public release.

data/Gemfile

@@ -0,0 +1,3 @@
+source "http://rubygems.org"
+gemspec
+

data/LICENSE

@@ -0,0 +1,27 @@
+Portions of Synapses-CAS contributed by Tiago Machado and João Lucas are copyright (c) 2012 Synapses Group.
+Portions of RubyCAS-Server contributed by Matt Zukowski are copyright (c) 2011 Urbacon Ltd.
+Other portions are copyright of their respective authors. 
+
+The MIT License
+
+Permission is hereby granted, free of charge, to any person
+obtaining a copy of this software and associated documentation
+files (the "Software"), to deal in the Software without
+restriction, including without limitation the rights to use,
+copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following
+conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.
+

data/README.md

@@ -0,0 +1,20 @@
+# Synapses RubyCAS-Server
+
+## Copyright
+
+Forked From RubyCAS-Server, by Matt Zukowski are copyright (c) 2011 Urbacon Ltd.
+Other portions are copyright of their respective authors.
+
+## Authors
+
+* Tiago Machado (tiago@synapses.com.br)
+* João Lucas (joaolucas@synapses.com.br
+
+## Differences between Synapses CAS and the original RubyCAS
+
+[0001] Changed the location of translations path at "localization.rb
+
+## License
+
+Synapses RubyCAS-Server is licensed for use under the terms of the MIT License.
+See the LICENSE file bundled with the official RubyCAS-Server distribution for details.

data/Rakefile

@@ -0,0 +1,2 @@
+Dir['tasks/**/*.rake'].each { |rake| load rake }
+task :default => :spec

data/bin/synapses-cas

@@ -0,0 +1,30 @@
+#!/usr/bin/env ruby
+
+# Enables UTF-8 compatibility in ruby 1.8.
+$KCODE = 'u' if RUBY_VERSION < '1.9'
+
+require 'rubygems'
+
+$:.unshift File.dirname(__FILE__) + "/../lib"
+
+if ARGV.join.match('--debugger')
+  require 'ruby-debug'
+  puts
+  puts "=> Debugger Enabled"
+end
+
+if ARGV.join.match('-c')
+  c = ARGV.join.match(/-c\s*([^\s]+)/)
+  if (c && c[1])
+    ENV['CONFIG_FILE'] = c[1]
+    puts
+    puts "=> Using custom config file #{ENV['CONFIG_FILE'].inspect}"
+  else
+    $stderr.puts("To specify a custom config file use `rubycas-server -c path/to/config_file_name.yml`.")
+    exit
+  end
+end
+
+require 'casserver'
+
+CASServer::Server.run!

data/config.ru

@@ -0,0 +1,17 @@
+require 'rubygems'
+
+# Assume all necessary gems are in place if bundler is not installed.
+begin
+  require 'bundler/setup'
+rescue LoadError => e
+  raise e unless e.message =~ /no such file to load -- bundler/
+end
+
+$:.unshift "#{File.dirname(__FILE__)}/lib"
+require "casserver"
+
+use Rack::ShowExceptions
+use Rack::Runtime
+use Rack::CommonLogger
+
+run CASServer::Server.new

data/config/config.example.yml

@@ -0,0 +1,592 @@
+# IMPORTANT NOTE ABOUT YAML CONFIGURATION FILES
+# ---> Be sure to use spaces instead of tabs for indentation. YAML is 
+#      white-space sensitive!
+
+##### SERVER SETUP ################################################################
+
+# There are several ways to run RubyCAS-Server:
+#
+# webrick   -- stand-alone WEBrick server; should work out-of-the-box; this is 
+#              the default method, but probably not suited for high-traffic usage
+# mongrel   -- stand-alone Mongrel server; fast, but you'll need to  install  
+#              and compile Mongrel and run it behind an https reverse proxy like 
+#              Pound or Apache 2.2's mod_proxy (since Mongrel cannot serve out
+#              over SSL on its own).
+# passenger -- served out by Apache via the mod_rails/mod_rack module
+#              (see http://www.modrails.com/)
+#
+# The following are example configurations for each of these three methods:
+#
+
+
+###
+### WEBrick example
+###
+# WEBrick is a simple, all-Ruby web server. This is the easiest method for running
+# RubyCAS-Server. All you need is an SSL certificate (enter its path under the
+# ssl_cert option). WEBrick is fine for sites with low to medium traffic, but for
+# high-performance scenarios you may want to look into deploying using Mongrel
+# or Passenger.
+
+server: webrick
+port: 443
+ssl_cert: /path/to/your/ssl.pem
+
+# If your private key is in a separate file from the cert
+
+#ssl_key: /path/to/your/private_key.pem
+
+# If you do not already have an SSL certificate and would like to automatically
+# generate one, run the "generate_ssl_certificate" rake task and use the following 
+# settings:
+
+#  ssl_cert: ssl/cert.pem
+#  ssl_key: ssl/key.pem
+
+
+# By default the login page will be available at the root path 
+# (e.g. https://login.example.net/). The uri_path option lets you serve it from a 
+# different path (e.g. https://login.example.net/cas).
+
+#uri_path: /cas
+
+
+# This lets you bind the server to a specific address. Use 0.0.0.0 to listen on
+# all available interfaces (this is the default).
+
+#bind_address: 0.0.0.0
+
+
+###
+### Mongrel example 
+###
+# Mongrel is much faster than WEBrick, but there are two caveats:
+#  1. Since Mongrel can't serve out encrypted HTTP on its own (and CAS requires this),
+#     you will have to set up a reverse proxy like Pound or Apache's mod_proxy and
+#     route through it requests to the Mongrel server. So for example,
+#     your Pound server will receive all of the requests to RubyCAS-Server on port 443,
+#     and forward them to the Mongrel server listening on port 11011.
+#  2. Some of Mongrel's components are compiled into native binaries, so if you are 
+#     installing on Linux, make sure you have all of the standard build tools
+#     available. The binaries should be automatically compiled for you when you
+#     install the mogrel gem (if you're runnings Windows, pre-compiled
+#     binaries will be downloaded and installed, so don't worry about this).
+
+#server: mongrel
+#port: 11011
+
+
+# Bind the server to a specific address. Use 0.0.0.0 to listen on all
+# available interfaces (this is the default).
+
+#bind_address: 0.0.0.0
+
+### Reverse proxy configuration examples
+# If you're using mod_proxy, your Apache vhost config should look something like this:
+#
+#  Listen 443
+#  <VirtualHost *:443>
+#    ServerAdmin admin@example.net
+#    ServerName login.example.net
+#  
+#    SSLEngine On
+#    SSLCertificateFile /etc/apache2/ssl.crt/example.pem
+#  
+#    # Don't do forward proxying, we only want reverse proxying
+#    ProxyRequests Off
+#  
+#    <Proxy balancer://rubycas>
+#      Order allow,deny
+#      Allow from all
+#      BalancerMember http://127.0.0.1:11011
+#    </Proxy>
+#  </VirtualHost>
+#
+# For Pound, the config should be something like:
+#
+#  ListenHTTPS
+#    Address 0.0.0.0
+#    Port    11011
+#    Cert    "/etc/ssl/example.pem"
+#  
+#    Service
+#      BackEnd
+#        Address localhost
+#        Port    443
+#      End
+#    End
+#  End
+
+
+###
+### Phusion Passenger (running under Apache configured for SSL)
+###
+
+# No additional configuration is requried to run RubyCAS-Server under
+# passsenger. Just follow the normal instructions for a Passenger app
+# (see http://www.modrails.com/).
+#
+# Here's an example Apache vhost config for RubyCAS-Server and Passenger:
+#
+#  Listen 443
+#  <VirtualHost *:443>
+#     ServerAdmin admin@example.net
+#     ServerName login.example.net
+#
+#     SSLEngine On
+#     SSLCertificateFile /etc/apache2/ssl.crt/example.pem
+#
+#     RailsAutoDetect off
+#
+#     DocumentRoot /usr/lib/ruby/gems/1.8/gems/rubycas-server-0.8.0/public
+#
+#     <Directory "/usr/lib/ruby/gems/1.8/gems/rubycas-server-0.8.0/public">
+#       AllowOverride all
+#       Allow from all
+#     </Directory>
+#  </VirtualHost>
+#
+
+
+##### DATABASE #################################################################
+
+# Set up the database connection. Make sure that this database is secure!
+# 
+# By default, we use MySQL, since it is widely used and does not require any 
+# additional ruby libraries besides ActiveRecord.
+#
+# With MySQL, your config would be something like the following:
+# (be sure to create the casserver database in MySQL beforehand,
+#   i.e. `mysqladmin -u root create casserver`)
+
+database:
+  adapter: mysql
+  database: casserver
+  username: root
+  password: 
+  host: localhost
+  reconnect: true
+
+# IMPORTANT! By default, the server can handle up to ~5 concurrent requests
+# (without queuing). You can increase this by setting the database connection
+# pool size to a higher number. For example, to handle up to ~10 concurrent 
+# requests:
+#
+#database:
+#  pool: 10
+#  adapter: mysql
+#  database: casserver
+#  username: root
+#  password: 
+#  host: localhost
+
+#
+# Instead of MySQL you can use SQLite3, PostgreSQL, MSSQL, or anything else 
+# supported by ActiveRecord.
+#
+# With SQLite3 (which does not require a separate database server), your 
+# configuration would look something like the following (don't forget to install 
+# the sqlite3-ruby gem beforehand!):
+
+#database:
+#  adapter: sqlite3
+#  database: /var/lib/casserver.db
+  
+
+# By default RubyCAS-Server will run migrations at every startup to ensure
+# that its database schema is up-to-date. To disable this behaviour set
+# the following option to true:
+
+#disable_auto_migrations: true
+
+##### AUTHENTICATION ###########################################################
+
+# Configure how username/passwords are validated.
+#
+# !!! YOU MUST CONFIGURE AT LEAST ONE OF THESE AUTHENTICATION METHODS !!!
+#
+# There are several built-in methods for authentication:
+# SQL, ActiveDirectory, LDAP, and GoogleAccounts. If none of these work for you, 
+# it is relatively easy to write your own custom Authenticator class (see below).
+#
+# === SQL Authentication =======================================================
+#
+# The simplest method is to validate against a SQL database. This assumes
+# that all of your users are stored in a table that has a 'username' column
+# and a 'password' column. When the user logs in, CAS connects to this database
+# and looks for a matching username/password in the users table. If a matching
+# username and password is found, authentication is successful.
+#
+# If you prefer to have your passwords stored in an encrypted form, have a 
+# look at the SQLEncrypted authenticator: 
+# http://code.google.com/p/rubycas-server/wiki/UsingTheSQLEncryptedAuthenticator
+#
+# If your users table stores passwords with MD5 hashing (for example as with
+# Drupal) try using the SQLMd5 version of the SQL authenticator.
+# 
+# Example:
+#
+#authenticator:
+#  class: CASServer::Authenticators::SQL
+#  database:
+#    adapter: mysql
+#    database: some_database_with_users_table
+#    username: root
+#    password: 
+#    host: localhost
+#  user_table: users
+#  username_column: username
+#  password_column: password
+#
+# When replying to a CAS client's validation request, the server will normally
+# provide the client with the authenticated user's username. However it is
+# possible for the server to provide the client with additional attributes.
+# You can configure the SQL authenticator to provide data from additional
+# columns in the users table by listing the names of the columns under the 
+# 'extra_attributes' option. Note though that this functionality is experimental.
+# It should work with RubyCAS-Client, but may or may not work with other CAS
+# clients. 
+#
+# For example, with this configuration, the 'full_name' and 'access_level'
+# columns will be provided to your CAS clients along with the username:
+#
+#authenticator:
+#  class: CASServer::Authenticators::SQL
+#  database:
+#    adapter: mysql
+#    database: some_database_with_users_table
+#  user_table: users
+#  username_column: username
+#  password_column: password
+#  extra_attributes: full_name, access_level
+#
+#
+#
+# === Google Authentication ====================================================
+#
+# The Google authenticator allows users to log in to your CAS server using
+# their Google account credentials (i.e. the same email and password they
+# would use to log in to Google services like Gmail). This authenticator
+# requires no special configuration -- just specify its class name:
+#
+#authenticator:
+#  class: CASServer::Authenticators::Google
+#
+# If you are behind an http proxy, you can try specifying proxy settings as follows:
+#
+#authenticator:
+#  class: CASServer::Authenticators::Google
+#  proxy:
+#    host: your-proxy-server
+#    port: 8080
+#    username: nil
+#    password: nil
+#
+# Note that as with all authenticators, it is possible to use the Google 
+# authenticator alongside other authenticators. For example, CAS can first
+# attempt to validate the account with Google, and if that fails, fall back
+# to some other local authentication mechanism.
+#
+# For example:
+#
+#authenticator:
+#  - class: CASServer::Authenticators::Google
+#  - class: CASServer::Authenticators::SQL
+#    database:
+#      adapter: mysql
+#      database: some_database_with_users_table
+#      username: root
+#      password:
+#      host: localhost
+#    user_table: user
+#    username_column: username
+#    password_column: password
+#
+#
+# === ActiveDirectory Authentication ===========================================
+#
+# This method authenticates against Microsoft's Active Directory using LDAP.
+# You must configure the ActiveDirectory server, and base DN. The port number
+# and LDAP filter are optional. You must also enter a CN and password
+# for a special "authenticator" user. This account is used to log in to
+# the ActiveDirectory server and search LDAP. This does not have to be an
+# administrative account -- it only has to be able to search for other
+# users.
+# 
+# Note that the auth_user parameter must be the user's CN (Common Name).
+# In Active Directory, the CN is genarally the user's full name, which is usually
+# NOT the same as their username (sAMAccountName).
+#
+# For example:
+#
+#authenticator: 
+#  class: CASServer::Authenticators::ActiveDirectoryLDAP
+#  ldap:
+#    host: ad.example.net
+#    port: 389
+#    base: dc=example,dc=net
+#    filter: (objectClass=person)
+#    auth_user: authenticator
+#    auth_password: itsasecret
+#
+# A more complicated example, where the authenticator will use TLS encryption,
+# will ignore users with disabled accounts, and will pass on the 'cn' and 'mail' 
+# attributes to CAS clients:
+#
+#authenticator:
+#  class: CASServer::Authenticators::ActiveDirectoryLDAP
+#  ldap:
+#    host: ad.example.net
+#    port: 636
+#    base: dc=example,dc=net
+#    filter: (objectClass=person) & !(msExchHideFromAddressLists=TRUE)
+#    auth_user: authenticator
+#    auth_password: itsasecret
+#    encryption: simple_tls
+#  extra_attributes: cn, mail
+#
+# It is possible to authenticate against Active Directory without the
+# authenticator user, but this requires that users type in their CN as
+# the username rather than typing in their sAMAccountName. In other words
+# users will likely have to authenticate by typing their full name,
+# rather than their username. If you prefer to do this, then just
+# omit the auth_user and auth_password values in the above example.
+#
+#
+# === LDAP Authentication ======================================================
+#
+# This is a more general version of the ActiveDirectory authenticator.
+# The configuration is similar, except you don't need an authenticator
+# username or password. The following example has been reported to work 
+# for a basic OpenLDAP setup.
+#
+#authenticator:
+#  class: CASServer::Authenticators::LDAP
+#  ldap:
+#    host: ldap.example.net
+#    port: 389
+#    base: dc=example,dc=net
+#    username_attribute: uid
+#    filter: (objectClass=person)
+#
+# If you need more secure connections via TSL, specify the 'encryption'
+# option and change the port. This example also forces the authenticator
+# to connect using a special "authenticator" user with the given
+# username and password (see the ActiveDirectoryLDAP authenticator
+# explanation above):
+#
+#authenticator:
+#  class: CASServer::Authenticators::LDAP
+#  ldap:
+#    host: ldap.example.net
+#    port: 636
+#    base: dc=example,dc=net
+#    filter: (objectClass=person)
+#    encryption: simple_tls
+#    auth_user: cn=admin,dc=example,dc=net
+#    auth_password: secret
+#
+# If you need additional data about the user passed to the client (for example,
+# their 'cn' and 'mail' attributes, you can specify the list of attributes
+# under the extra_attributes config option: 
+#
+#authenticator:
+#  class: CASServer::Authenticators::LDAP
+#  ldap:
+#    host: ldap.example.net
+#    port: 389
+#    base: dc=example,dc=net
+#    filter: (objectClass=person)
+#  extra_attributes: cn, mail
+#
+# Note that the above functionality is somewhat limited by client compatibility.
+# See the SQL authenticator notes above for more info.
+#
+#
+# === Custom Authentication ====================================================
+#
+# It should be relatively easy to write your own Authenticator class. Have a look
+# at the built-in authenticators in the casserver/authenticators directory. Your
+# authenticator should extend the CASServer::Authenticators::Base class and must
+# implement a validate() method that takes a single hash argument. When the user 
+# submits the login form, the username and password they entered is passed to 
+# validate() as a hash under :username and :password keys. In the future, this 
+# hash might also contain other data such as the domain that the user is logging 
+# in to.
+#
+# To use your custom authenticator, specify it's class name and path to the 
+# source file in the authenticator section of the config. Any other parameters 
+# you specify in the authenticator configuration will be passed on to the 
+# authenticator and made availabe in the validate() method as an @options hash.
+#
+# Example:
+#
+#authenticator:
+#  class: FooModule::MyCustomAuthenticator
+#  source: /path/to/source.rb
+#  option_a: foo
+#  another_option: yeeha
+#
+# === Multiple Authenticators ==================================================
+#
+# If you need to have more than one source for authentication, such as an LDAP 
+# directory and a database, you can use multiple authenticators by making 
+# :authenticator an array of authenticators.
+#
+#authenticator:
+#  -
+#    class: CASServer::Authenticators::ActiveDirectoryLDAP
+#    ldap:
+#      host: ad.example.net
+#      port: 389
+#      base: dc=example,dc=net
+#      filter: (objectClass=person)
+#  -
+#    class: CASServer::Authenticators::SQL
+#    database:
+#      adapter: mysql
+#      database: some_database_with_users_table
+#      username: root
+#      password:
+#      host: localhost
+#    user_table: user
+#    username_column: username
+#    password_column: password
+#
+# During authentication, the user credentials will be checked against the first
+# authenticator and on failure fall through to the second authenticator.
+#
+
+
+##### LOOK & FEEL ##############################################################
+
+# Set the path to the theme directory that determines how your CAS pages look. 
+#
+# Custom themes are not well supported yet, but will be in the near future. In 
+# the meantime, if you want to create a custom theme, you can create a 
+# subdirectory under the CASServer's themes dir (for example, 
+# '/usr/lib/ruby/1.8/gems/casserver-xxx/public/themes', if you installed CASServer 
+# on Linux as a gem). A theme is basically just a theme.css file that overrides 
+# the themes/cas.css styles along with a collection of image files
+# like logo.png and bg.png.
+#
+# By default, we use the 'simple' theme which you can find in themes/simple.
+theme: simple
+
+# The name of your company/organization. This will show up on the login page.
+organization: CAS
+
+# A short bit of text that shows up on the login page. You can make this blank 
+# if you prefer to have no extra text shown at the bottom of the login box.
+infoline: Powered by <a href="http://code.google.com/p/rubycas-server/">RubyCAS-Server</a>
+
+# Custom views directory. If set, this will be used instead of 'lib/casserver/views'.
+#custom_views: /path/to/custom/views
+
+# Custom public directory. If set, static content (css, etc.) will be served from here rather 
+# than from rubycas-server's internal 'public' directory (but be mindful of any overriding 
+# settings you may have in your web server's config).
+#public_dir: /path/to/custom/public
+
+##### LOCALIZATION (L10N) #######################################################
+# The server will attempt to detect the user's locale and show text in the 
+# appropriate language based on:
+#
+#   1. The 'lang' URL parameter (if any)
+#   2. The 'lang' cookie (if any)
+#   3. The HTTP_ACCEPT_LANGUAGE header supplied by the user's browser.
+#   4. The HTTP_USER_AGENT header supplied by the user's browser.
+#
+# If the locale cannot be established based on one of the above checks (in the 
+# shown order), then the below 'default_locale' option will be used.
+#
+# The format is the same as standard linux locales (langagecode_COUNTRYCODE): 
+#
+#   ru_RU - Russian, Russia
+#   eo_AQ - Esperanto, Antarctica 
+#   
+# It will also work if you leave out the region (i.e. just "ru" for Russian,
+# "eo" for Esperanto).
+#
+# If you are interested in contributing new translations or have corrections
+# to the existing translations, see 
+# http://code.google.com/p/rubycas-server/wiki/HowToContribueTranslations
+#
+default_locale: en
+
+##### LOGGING ##################################################################
+
+# Configure general logging. This log is where you'll want to look in case of 
+# problems.
+#
+# You may want to change the file to something like /var/log/casserver.log
+# Set the level to DEBUG if you want more detailed logging.
+
+log:
+  file: /var/log/casserver.log
+  level: INFO
+
+
+# If you want full database logging, uncomment this next section.
+# Every SQL query will be logged here. This is useful for debugging database 
+# problems.
+
+#db_log:
+#  file: /var/log/casserver_db.log
+
+
+# Setting the following option to true will disable CLI output to stdout.
+# i.e. this will get rid of messages like ">>> Redirecting RubyCAS-Server log..."
+# This is useful when, for example, you're running rspecs.
+
+#quiet: true
+
+
+##### SINGLE SIGN-OUT ##########################################################
+
+# When a user logs in to a CAS-enabled client application, that application
+# generally opens its own local user session. When the user then logs out
+# through the CAS server, each of the CAS-enabled client applications need
+# to be notified so that they can close their own local sessions for that user.
+#
+# Up until recently this was not possible within CAS. However, a method for
+# performing this notification was recently added to the protocol (in CAS 3.1). 
+# This works exactly as described above -- when the user logs out, the CAS 
+# server individually contacts each client service and notifies it of the 
+# logout. Currently not all client applications support this, so this
+# behaviour is disabled by default. To enable it, uncomment the following
+# configuration line. Note that currently it is not possible to enable
+# or disable single-sign-out on a per-service basis, but this functionality
+# is planned for a future release.
+
+#enable_single_sign_out: true
+
+
+##### OTHER ####################################################################
+
+# You can set various ticket expiry times (specify the value in seconds).
+
+# Unused login and service tickets become unusable this many seconds after
+# they are created. (Defaults to 5 minutes)
+
+#maximum_unused_login_ticket_lifetime: 300
+#maximum_unused_service_ticket_lifetime: 300
+
+# The server must periodically delete old tickets (login tickets, service tickets
+# proxy-granting tickets, and ticket-granting tickets) to prevent buildup of
+# stale data. This effectively limits the maximum length of a CAS session to
+# the lifetime given here (in seconds). (Defaults to 48 hours)
+# 
+# Note that this limit is not enforced on the client side; it refers only to the
+# the maximum lifetime of tickets on the CAS server.
+
+#maximum_session_lifetime: 172800
+
+
+# If you want the usernames entered on the login page to be automatically 
+# downcased (converted to lowercase), enable the following option. When this 
+# option is set to true, if the user enters "JSmith" as their username, the 
+# system will automatically
+# convert this to "jsmith".
+
+#downcase_username: true