|
|
|
|
@ -1,581 +0,0 @@
|
|
|
|
|
# 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: 6543
|
|
|
|
|
ssl_cert: /home/URBACON/mzukowski/Private/ssl/urbacon.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 *: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
|
|
|
|
|
reconnect: true
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# 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.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
authenticator:
|
|
|
|
|
-
|
|
|
|
|
class: CASServer::Authenticators::Test
|
|
|
|
|
password: spec_password
|
|
|
|
|
-
|
|
|
|
|
class: CASServer::Authenticators::SQL
|
|
|
|
|
password_column: display_name
|
|
|
|
|
database:
|
|
|
|
|
adapter: mysql
|
|
|
|
|
database: utrack_development
|
|
|
|
|
username: root
|
|
|
|
|
password:
|
|
|
|
|
host: localhost
|
|
|
|
|
#-
|
|
|
|
|
# class: CASServer::Authenticators::ActiveDirectoryLDAP
|
|
|
|
|
# ldap:
|
|
|
|
|
# server: urbacon-ad01.urbacon.net
|
|
|
|
|
# port: 636
|
|
|
|
|
# base: dc=urbacon,dc=net
|
|
|
|
|
# filter: (objectClass=person) & !(msExchHideFromAddressLists=TRUE)
|
|
|
|
|
# auth_user: ldapq
|
|
|
|
|
# auth_password: urbacon
|
|
|
|
|
# encryption: simple_tls
|
|
|
|
|
# extra_attributes: cn, mail, memberOf
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# 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: urbacon
|
|
|
|
|
|
|
|
|
|
# The name of your company/organization. This will show up on the login page.
|
|
|
|
|
organization: URBACON
|
|
|
|
|
|
|
|
|
|
# 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: "Matt's Dev Server"
|
|
|
|
|
|
|
|
|
|
# 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: /mnt/old-system/var/log/rails-logs/rubycas-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/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
|
Matt Zukowski