kch-rubycas-server 0.8.0.20090715

data/Manifest.txt

@@ -0,0 +1,85 @@
+CHANGELOG.txt
+History.txt
+LICENSE.txt
+Manifest.txt
+PostInstall.txt
+README.txt
+Rakefile
+bin/rubycas-server
+bin/rubycas-server-ctl
+config.example.yml
+config.ru
+config/hoe.rb
+config/requirements.rb
+custom_views.example.rb
+lib/casserver.rb
+lib/casserver/authenticators/active_directory_ldap.rb
+lib/casserver/authenticators/base.rb
+lib/casserver/authenticators/client_certificate.rb
+lib/casserver/authenticators/google.rb
+lib/casserver/authenticators/ldap.rb
+lib/casserver/authenticators/ntlm.rb
+lib/casserver/authenticators/open_id.rb
+lib/casserver/authenticators/sql.rb
+lib/casserver/authenticators/sql_encrypted.rb
+lib/casserver/authenticators/sql_md5.rb
+lib/casserver/authenticators/sql_rest_auth.rb
+lib/casserver/authenticators/test.rb
+lib/casserver/cas.rb
+lib/casserver/conf.rb
+lib/casserver/controllers.rb
+lib/casserver/load_picnic.rb
+lib/casserver/localization.rb
+lib/casserver/models.rb
+lib/casserver/postambles.rb
+lib/casserver/utils.rb
+lib/casserver/version.rb
+lib/casserver/views.rb
+lib/rubycas-server.rb
+lib/rubycas-server/version.rb
+locale/de_DE/LC_MESSAGES/rubycas-server.mo
+locale/es_ES/LC_MESSAGES/rubycas-server.mo
+locale/fr_FR/LC_MESSAGES/rubycas-server.mo
+locale/ja_JP/LC_MESSAGES/rubycas-server.mo
+locale/pl_PL/LC_MESSAGES/rubycas-server.mo
+locale/pt_BR/LC_MESSAGES/rubycas-server.mo
+locale/ru_RU/LC_MESSAGES/rubycas-server.mo
+po/de_DE/rubycas-server.po
+po/es_ES/rubycas-server.po
+po/fr_FR/rubycas-server.po
+po/ja_JP/rubycas-server.po
+po/pl_PL/rubycas-server.po
+po/pt_BR/rubycas-server.po
+po/ru_RU/rubycas-server.po
+po/rubycas-server.pot
+public/themes/cas.css
+public/themes/notice.png
+public/themes/ok.png
+public/themes/simple/bg.png
+public/themes/simple/favicon.png
+public/themes/simple/login_box_bg.png
+public/themes/simple/logo.png
+public/themes/simple/theme.css
+public/themes/urbacon/bg.png
+public/themes/urbacon/login_box_bg.png
+public/themes/urbacon/logo.png
+public/themes/urbacon/theme.css
+public/themes/warning.png
+resources/init.d.sh
+script/console
+script/destroy
+script/generate
+script/txt2html
+setup.rb
+tasks/deployment.rake
+tasks/environment.rake
+tasks/localization.rake
+tasks/website.rake
+vendor/isaac_0.9.1/LICENSE
+vendor/isaac_0.9.1/README
+vendor/isaac_0.9.1/TODO
+vendor/isaac_0.9.1/VERSIONS
+vendor/isaac_0.9.1/crypt/ISAAC.rb
+vendor/isaac_0.9.1/isaac.gemspec
+vendor/isaac_0.9.1/setup.rb
+vendor/isaac_0.9.1/test/TC_ISAAC.rb

data/PostInstall.txt

@@ -0,0 +1,3 @@
+
+For more information on RubyCAS-Server, see http://code.google.com/p/rubycas-server
+

data/README.rdoc

@@ -0,0 +1,26 @@
+= RubyCAS-Server
+
+*Copyright*:: Portions contributed by Matt Zukowski are copyright (c) 2008 Urbacon Ltd.
+              Other portions are copyright of their respective authors.
+*Authors*::   See http://github.com/gunark/rubycas-server/commits/
+*Homepage*::  http://rubycas-server.googlecode.com
+
+For info and installation instructions please see http://code.google.com/p/rubycas-server
+
+
+== License
+
+RubyCAS-Server is free software; you can redistribute it and/or modify
+it under the terms of the GNU Lesser General Public License as published 
+by the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+RubyCAS-Server is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU Lesser General Public License
+along with RubyCAS-Server; if not, write to the Free Software
+Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+

data/Rakefile

@@ -0,0 +1,4 @@
+require 'config/requirements'
+require 'config/hoe' # setup Hoe + all gem configuration
+
+Dir['tasks/**/*.rake'].each { |rake| load rake }

data/bin/rubycas-server

@@ -0,0 +1,13 @@
+#!/usr/bin/env ruby
+
+require File.expand_path(File.dirname(__FILE__)+"/../lib/casserver/load_picnic")
+
+require 'picnic/cli'
+
+cli = Picnic::Cli.new(
+  'rubycas-server',
+  :app_module => 'CASServer',
+  :app_file => File.expand_path(File.dirname(__FILE__)+"/../lib/casserver.rb")
+)
+
+cli.handle_cli_input

data/bin/rubycas-server-ctl

@@ -0,0 +1,9 @@
+#!/usr/bin/env ruby
+
+require File.expand_path(File.dirname(__FILE__)+"/../lib/casserver/load_picnic")
+
+require 'picnic/service_control'
+
+ctl = Picnic::ServiceControl.new('rubycas-server')
+
+ctl.handle_cli_input

data/config.example.yml

@@ -0,0 +1,544 @@
+# 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 exampe 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 separate from cert
+
+#ssl_key: /path/to/your/private_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: 110011
+
+
+# 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 442
+#  <VirtualHost *:442>
+#     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
+
+
+#
+# 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
+#  dbfile: /var/lib/casserver.db
+  
+
+##### 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
+#
+# 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
+#      user: 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
+#      user: 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 file.  Overrides methodes in lib/casserver/views.rb
+#custom_views_file: /path/to/custom/views.rb
+
+##### 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
+
+
+##### 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