uchouhan-rubycas-server 1.0.a

data/public/themes/simple/theme.css

@@ -0,0 +1,28 @@
+body {
+  background-image: url(bg.png);
+}
+
+#headline-container {
+  margin-bottom: 5px;
+}
+
+#login-box {
+  margin: 0 auto;
+  width: 450px;
+  top: 110px;
+  position: relative;
+}
+
+#login-form {
+  background-color: #fff;
+  border: 1px #aaa solid;
+}
+
+#logo-container {
+  vertical-align: middle;
+}
+
+#logo {
+    width: 128px;
+    height: 128px;
+}

data/public/themes/tadnet/theme.css

@@ -0,0 +1,55 @@
+body {
+	background: white;
+}
+
+#headline-container {
+	margin-bottom: 5px;
+	text-align: center;
+}
+
+#login-box {
+	margin: 0 auto;
+	width: 450px;
+	top: 110px;
+	position: relative;
+}
+
+#login-form {
+	margin: 0;
+	padding: 0;
+}
+
+#logo-container {
+	vertical-align: middle;
+}
+
+#logo {
+}
+
+#submit-container {
+	padding-top: 10px;
+	text-align: center !important;
+}
+
+button {
+	cursor: pointer;
+  border: none;
+  background-color: transparent;
+}
+
+label {
+	color: #666666;
+	font-size: 12px;
+	font-weight: normal;
+	float: right;
+	width: 8em;
+	text-align: right;
+}
+
+#username, #password {
+	float: left;
+	font-size: 14px;
+	width: 15em;
+	margin-left: 5px;
+	padding: 2px;
+}

data/public/themes/urbacon/theme.css

@@ -0,0 +1,33 @@
+body {
+  background-image: url(bg.png);
+}
+
+label {
+  color: #5c6156;
+}
+
+#login-form {
+  background-repeat: no-repeat;
+  background-image: url(login_box_bg.png);
+  height: 175px;
+  width: 210px;
+  padding: 20px;
+}
+
+#logo-container {
+  vertical-align: top;
+}
+
+#logo {
+    width: 115px;
+    height: 171px;
+}
+
+#infoline {
+  color: #5c6156;
+  font-size: 8px;
+}
+
+#headline-container {
+  margin-right: 15px;
+}

data/resources/config.example.yml

@@ -0,0 +1,574 @@
+# 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 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
+
+###
+### Proxy support (Google, etc)
+###
+# If your server is behind a proxy you can uncomment the following lines in order
+# to activate proxy support:
+#
+#  proxy_host: your-proxy-server
+#  proxy_port: 8080
+#  proxy_username: nil
+#  proxy_passsword: nil
+
+
+# By default the login page will be available at the root path 
+# (e.g. https://login.example.net/). The uri_path option lets you serve it from a 
+# different path (e.g. https://login.example.net/cas).
+
+#uri_path: /cas
+
+
+# This lets you bind the server to a specific address. Use 0.0.0.0 to listen on
+# all available interfaces (this is the default).
+
+#bind_address: 0.0.0.0
+
+
+###
+### Mongrel example 
+###
+# Mongrel is much faster than WEBrick, but there are two caveats:
+#  1. Since Mongrel can't serve out encrypted HTTP on its own (and CAS requires this),
+#     you will have to set up a reverse proxy like Pound or Apache's mod_proxy and
+#     route through it requests to the Mongrel server. So for example,
+#     your Pound server will receive all of the requests to RubyCAS-Server on port 443,
+#     and forward them to the Mongrel server listening on port 11011.
+#  2. Some of Mongrel's components are compiled into native binaries, so if you are 
+#     installing on Linux, make sure you have all of the standard build tools
+#     available. The binaries should be automatically compiled for you when you
+#     install the mogrel gem (if you're runnings Windows, pre-compiled
+#     binaries will be downloaded and installed, so don't worry about this).
+
+#server: mongrel
+#port: 11011
+
+
+# Bind the server to a specific address. Use 0.0.0.0 to listen on all
+# available interfaces (this is the default).
+
+#bind_address: 0.0.0.0
+
+### Reverse proxy configuration examples
+# If you're using mod_proxy, your Apache vhost config should look something like this:
+#
+#  Listen 443
+#  <VirtualHost *:443>
+#    ServerAdmin admin@example.net
+#    ServerName login.example.net
+#  
+#    SSLEngine On
+#    SSLCertificateFile /etc/apache2/ssl.crt/example.pem
+#  
+#    # Don't do forward proxying, we only want reverse proxying
+#    ProxyRequests Off
+#  
+#    <Proxy balancer://rubycas>
+#      Order allow,deny
+#      Allow from all
+#      BalancerMember http://127.0.0.1:11011
+#    </Proxy>
+#  </VirtualHost>
+#
+# For Pound, the config should be something like:
+#
+#  ListenHTTPS
+#    Address 0.0.0.0
+#    Port    11011
+#    Cert    "/etc/ssl/example.pem"
+#  
+#    Service
+#      BackEnd
+#        Address localhost
+#        Port    443
+#      End
+#    End
+#  End
+
+
+###
+### Phusion Passenger (running under Apache configured for SSL)
+###
+
+# No additional configuration is requried to run RubyCAS-Server under
+# passsenger. Just follow the normal instructions for a Passenger app
+# (see http://www.modrails.com/).
+#
+# Here's an example Apache vhost config for RubyCAS-Server and Passenger:
+#
+#  Listen 443
+#  <VirtualHost *:443>
+#     ServerAdmin admin@example.net
+#     ServerName login.example.net
+#
+#     SSLEngine On
+#     SSLCertificateFile /etc/apache2/ssl.crt/example.pem
+#
+#     RailsAutoDetect off
+#
+#     DocumentRoot /usr/lib/ruby/gems/1.8/gems/rubycas-server-0.8.0/public
+#
+#     <Directory "/usr/lib/ruby/gems/1.8/gems/rubycas-server-0.8.0/public">
+#       AllowOverride all
+#       Allow from all
+#     </Directory>
+#  </VirtualHost>
+#
+
+
+##### DATABASE #################################################################
+
+# Set up the database connection. Make sure that this database is secure!
+# 
+# By default, we use MySQL, since it is widely used and does not require any 
+# additional ruby libraries besides ActiveRecord.
+#
+# With MySQL, your config would be something like the following:
+# (be sure to create the casserver database in MySQL beforehand,
+#   i.e. `mysqladmin -u root create casserver`)
+
+database:
+  adapter: mysql
+  database: casserver
+  username: root
+  password: 
+  host: localhost
+
+# 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
+#  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
+#      username: root
+#      password:
+#      host: localhost
+#    user_table: user
+#    username_column: username
+#    password_column: password
+#
+#
+# === ActiveDirectory Authentication ===========================================
+#
+# This method authenticates against Microsoft's Active Directory using LDAP.
+# You must configure the ActiveDirectory server, and base DN. The port number
+# and LDAP filter are optional. You must also enter a CN and password
+# for a special "authenticator" user. This account is used to log in to
+# the ActiveDirectory server and search LDAP. This does not have to be an
+# administrative account -- it only has to be able to search for other
+# users.
+# 
+# Note that the auth_user parameter must be the user's CN (Common Name).
+# In Active Directory, the CN is genarally the user's full name, which is usually
+# NOT the same as their username (sAMAccountName).
+#
+# For example:
+#
+#authenticator: 
+#  class: CASServer::Authenticators::ActiveDirectoryLDAP
+#  ldap:
+#    host: ad.example.net
+#    port: 389
+#    base: dc=example,dc=net
+#    filter: (objectClass=person)
+#    auth_user: authenticator
+#    auth_password: itsasecret
+#
+# A more complicated example, where the authenticator will use TLS encryption,
+# will ignore users with disabled accounts, and will pass on the 'cn' and 'mail' 
+# attributes to CAS clients:
+#
+#authenticator:
+#  class: CASServer::Authenticators::ActiveDirectoryLDAP
+#  ldap:
+#    host: ad.example.net
+#    port: 636
+#    base: dc=example,dc=net
+#    filter: (objectClass=person) & !(msExchHideFromAddressLists=TRUE)
+#    auth_user: authenticator
+#    auth_password: itsasecret
+#    encryption: simple_tls
+#  extra_attributes: cn, mail
+#
+# It is possible to authenticate against Active Directory without the
+# authenticator user, but this requires that users type in their CN as
+# the username rather than typing in their sAMAccountName. In other words
+# users will likely have to authenticate by typing their full name,
+# rather than their username. If you prefer to do this, then just
+# omit the auth_user and auth_password values in the above example.
+#
+#
+# === LDAP Authentication ======================================================
+#
+# This is a more general version of the ActiveDirectory authenticator.
+# The configuration is similar, except you don't need an authenticator
+# username or password. The following example has been reported to work 
+# for a basic OpenLDAP setup.
+#
+#authenticator:
+#  class: CASServer::Authenticators::LDAP
+#  ldap:
+#    host: ldap.example.net
+#    port: 389
+#    base: dc=example,dc=net
+#    username_attribute: uid
+#    filter: (objectClass=person)
+#
+# If you need more secure connections via TSL, specify the 'encryption'
+# option and change the port. This example also forces the authenticator
+# to connect using a special "authenticator" user with the given
+# username and password (see the ActiveDirectoryLDAP authenticator
+# explanation above):
+#
+#authenticator:
+#  class: CASServer::Authenticators::LDAP
+#  ldap:
+#    host: ldap.example.net
+#    port: 636
+#    base: dc=example,dc=net
+#    filter: (objectClass=person)
+#    encryption: simple_tls
+#    auth_user: cn=admin,dc=example,dc=net
+#    auth_password: secret
+#
+# If you need additional data about the user passed to the client (for example,
+# their 'cn' and 'mail' attributes, you can specify the list of attributes
+# under the extra_attributes config option: 
+#
+#authenticator:
+#  class: CASServer::Authenticators::LDAP
+#  ldap:
+#    host: ldap.example.net
+#    port: 389
+#    base: dc=example,dc=net
+#    filter: (objectClass=person)
+#  extra_attributes: cn, mail
+#
+# Note that the above functionality is somewhat limited by client compatibility.
+# See the SQL authenticator notes above for more info.
+#
+#
+# === Custom Authentication ====================================================
+#
+# It should be relatively easy to write your own Authenticator class. Have a look
+# at the built-in authenticators in the casserver/authenticators directory. Your
+# authenticator should extend the CASServer::Authenticators::Base class and must
+# implement a validate() method that takes a single hash argument. When the user 
+# submits the login form, the username and password they entered is passed to 
+# validate() as a hash under :username and :password keys. In the future, this 
+# hash might also contain other data such as the domain that the user is logging 
+# in to.
+#
+# To use your custom authenticator, specify it's class name and path to the 
+# source file in the authenticator section of the config. Any other parameters 
+# you specify in the authenticator configuration will be passed on to the 
+# authenticator and made availabe in the validate() method as an @options hash.
+#
+# Example:
+#
+#authenticator:
+#  class: FooModule::MyCustomAuthenticator
+#  source: /path/to/source.rb
+#  option_a: foo
+#  another_option: yeeha
+#
+# === Multiple Authenticators ==================================================
+#
+# If you need to have more than one source for authentication, such as an LDAP 
+# directory and a database, you can use multiple authenticators by making 
+# :authenticator an array of authenticators.
+#
+#authenticator:
+#  -
+#    class: CASServer::Authenticators::ActiveDirectoryLDAP
+#    ldap:
+#      host: ad.example.net
+#      port: 389
+#      base: dc=example,dc=net
+#      filter: (objectClass=person)
+#  -
+#    class: CASServer::Authenticators::SQL
+#    database:
+#      adapter: mysql
+#      database: some_database_with_users_table
+#      username: root
+#      password:
+#      host: localhost
+#    user_table: user
+#    username_column: username
+#    password_column: password
+#
+# During authentication, the user credentials will be checked against the first
+# authenticator and on failure fall through to the second authenticator.
+#
+
+
+##### LOOK & FEEL ##############################################################
+
+# Set the path to the theme directory that determines how your CAS pages look. 
+#
+# Custom themes are not well supported yet, but will be in the near future. In 
+# the meantime, if you want to create a custom theme, you can create a 
+# subdirectory under the CASServer's themes dir (for example, 
+# '/usr/lib/ruby/1.8/gems/casserver-xxx/public/themes', if you installed CASServer 
+# on Linux as a gem). A theme is basically just a theme.css file that overrides 
+# the themes/cas.css styles along with a collection of image files
+# like logo.png and bg.png.
+#
+# By default, we use the 'simple' theme which you can find in themes/simple.
+theme: simple
+
+# The name of your company/organization. This will show up on the login page.
+organization: CAS
+
+# A short bit of text that shows up on the login page. You can make this blank 
+# if you prefer to have no extra text shown at the bottom of the login box.
+infoline: Powered by <a href="http://code.google.com/p/rubycas-server/">RubyCAS-Server</a>
+
+# Custom views 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