From a156542ee98c9b4e5cfddd6dccbabe0bd72e6b44 Mon Sep 17 00:00:00 2001 From: Truong Hoang Dung Date: Sat, 1 Sep 2012 17:07:10 +0700 Subject: [PATCH 1/2] My config --- config/config.yml | 603 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 603 insertions(+) create mode 100644 config/config.yml diff --git a/config/config.yml b/config/config.yml new file mode 100644 index 00000000..f3b1a68b --- /dev/null +++ b/config/config.yml @@ -0,0 +1,603 @@ +# 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: 8443 +ssl_cert: /home/rev/casserver.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 +# +# 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 +# +# +# Order allow,deny +# Allow from all +# BalancerMember http://127.0.0.1:11011 +# +# +# +# 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 +# +# 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 +# +# +# AllowOverride all +# Allow from all +# +# +# + + +##### 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: /home/rev/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: 10.1.0.200 +# port: 8080 +# username: nil +# password: nil +# +# If you want to restrict access to only those Google accounts in a +# particular domain, as might be the case for an organization that +# uses Google for its domain's e-mail, add the restricted_domain +# option: +# +#authenticator: +# class: CASServer::Authenticators::Google +# restricted_domain: example.com +# +# 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::SQLEncrypted + database: + adapter: postgresql + database: users + port: 5433 + username: test + password: test + host: 10.1.0.195 + user_table: credentials + username_column: username + password_column: password + encrypt_function: 'require "digest/md5"; user.password == Digest::MD5.hexdigest("#{@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: HPU + +# 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 RubyCAS-Server + +# 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: /home/rev/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 From da96ae2f9b7b09ba92ee7effac83ac029494fe75 Mon Sep 17 00:00:00 2001 From: checkraiser Date: Sat, 5 Jan 2013 15:35:01 +0700 Subject: [PATCH 2/2] Update lib/casserver/authenticators/sql.rb - Change @model.set_table_name to @model.table_name - Change #{user_model.connection_pool.instance_variable_get(:@checked_out).length to #{user_model.connection_pool.instance_variable_get(:@size) --- lib/casserver/authenticators/sql.rb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/casserver/authenticators/sql.rb b/lib/casserver/authenticators/sql.rb index a2be72b7..b992eff2 100644 --- a/lib/casserver/authenticators/sql.rb +++ b/lib/casserver/authenticators/sql.rb @@ -67,7 +67,7 @@ class #{user_model_name} < ActiveRecord::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 @@ -79,7 +79,7 @@ def validate(credentials) read_standard_credentials(credentials) raise_if_not_configured - $LOG.debug "#{self.class}: [#{user_model}] " + "Connection pool size: #{user_model.connection_pool.instance_variable_get(:@checked_out).length}/#{user_model.connection_pool.instance_variable_get(:@connections).length}" + $LOG.debug "#{self.class}: [#{user_model}] " + "Connection pool size: #{user_model.connection_pool.instance_variable_get(:@size)}/#{user_model.connection_pool.instance_variable_get(:@size)}" user_model.connection_pool.checkin(user_model.connection) if matching_users.size > 0