synapses-cas 0.1.0 → 0.1.1

data/bin/cas_config.yml

@@ -0,0 +1,595 @@
+# 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).
+
+#ri_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@synapses-tools.com.br
+#    ServerName mclaren
+#
+#    SSLEngine Off
+#     SSLCertificateFile /etc/apache2/ssl.crt/example.pem
+#
+#    RailsAutoDetect off
+#
+#    DocumentRoot /home/jlucasps/.rvm/gems/ruby-1.9.3-p125/gems/rubycas-server-0.7.1.1/public
+#
+#    <Directory "/home/jlucasps/.rvm/gems/ruby-1.9.3-p125/gems/rubycas-server-0.7.1.1">
+#      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: postgresql
+  database: synapses_ws_development
+  username: postgres
+  password: postgres
+  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
+# validate# Drupal) try using the SQLMd5 version of the SQL authenticator.
+# 
+# Example:
+#
+authenticator:
+#  class: CASServer::Authenticators::SQL
+  class: CASServer::Authenticators::SQLEncrypted
+  database:
+    adapter: postgresql
+    database: synapses_ws_development
+    username: postgres
+    password: postgres
+    host: localhost 
+  user_table: users
+  username_column: email
+#  password_column: password_hash
+  encrypt_function: 'user.password_hash == Digest::SHA256.hexdigest("#{@password}#{user.password_salt}") && (user.status == "A")'
+  extra_attributes: name, default_locale, must_change_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: Authenticator
+#  source: /media/truecrypt1/worspace_aptana_synapses_ws/synapses_ws/lib/auth/authenticator.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: bootstrap
+
+# The name of your company/organization. This will show up on the login page.
+organization: Synapses
+
+# 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://www.synapses.com.br/">Synapses</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: pt
+
+##### 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/synapses_cas_server.log
+  level: DEBUG
+
+
+# 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/synapses_cas_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

data/bin/synapses-cas

@@ -9,7 +9,6 @@ $:.unshift File.dirname(__FILE__) + "/../lib"
 
 if ARGV.join.match('--debugger')
   require 'ruby-debug'
-  puts
   puts "=> Debugger Enabled"
 end
 
@@ -20,7 +19,7 @@ if ARGV.join.match('-c')
     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`.")
+    $stderr.puts("To specify a custom config file use `synapses-cas -c path/to/config_file_name.yml`.")
     exit
   end
 end

data/lib/casserver/authenticators/sql.rb

@@ -67,7 +67,7 @@ class CASServer::Authenticators::SQL < CASServer::Authenticators::Base
 
     @user_model = const_get(user_model_name)
     @user_model.establish_connection(options[:database])
-    @user_model.set_table_name(options[:user_table] || 'users')
+    @user_model.table_name = options[:user_table] || 'users'
     @user_model.inheritance_column = 'no_inheritance_column' if options[:ignore_type_column]
   end
 

data/lib/casserver/model.rb

@@ -53,12 +53,12 @@ module CASServer::Model
   end
 
   class LoginTicket < Ticket
-    set_table_name 'casserver_lt'
+    self.table_name = 'casserver_lt'
     include Consumable
   end
 
   class ServiceTicket < Ticket
-    set_table_name 'casserver_st'
+    self.table_name = 'casserver_st'
     include Consumable
 
     belongs_to :granted_by_tgt,
@@ -80,7 +80,7 @@ module CASServer::Model
   end
 
   class TicketGrantingTicket < Ticket
-    set_table_name 'casserver_tgt'
+    self.table_name = 'casserver_tgt'
 
     serialize :extra_attributes
 
@@ -90,7 +90,7 @@ module CASServer::Model
   end
 
   class ProxyGrantingTicket < Ticket
-    set_table_name 'casserver_pgt'
+    self.table_name = 'casserver_pgt'
     belongs_to :service_ticket
     has_many :granted_proxy_tickets,
       :class_name => 'CASServer::Model::ProxyTicket',