Permalink
Browse files

Update config.example

  • Loading branch information...
1 parent ae00262 commit b7f21b37bcc69e1803170445c86ea5795e7377f6 @mitfik committed Apr 10, 2012
Showing with 96 additions and 89 deletions.
  1. +96 −89 config/config.example.yml
View
@@ -203,7 +203,7 @@ database:
# Configure how username/passwords are validated.
#
-# !!! YOU MUST CONFIGURE AT LEAST ONE OF THESE AUTHENTICATION METHODS !!!
+# !!! YOU MUST ADD AT LEAST ONE OF AUTHENTICATION METHODS TO AUTHENTICATORS ARRAY !!!
#
# There are several built-in methods for authentication:
# SQL, ActiveDirectory, LDAP, and GoogleAccounts. If none of these work for you,
@@ -226,17 +226,18 @@ database:
#
# 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
+#authenticators:
+# -
+# 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
@@ -250,17 +251,16 @@ database:
# 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
-#
-#
+#authenticators:
+# -
+# 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 ====================================================
#
@@ -269,18 +269,20 @@ database:
# 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
+#authenticators:
+# -
+# 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
+#authenticators:
+# -
+# 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
@@ -289,7 +291,7 @@ database:
#
# For example:
#
-#authenticator:
+#authenticators:
# - class: CASServer::Authenticators::Google
# - class: CASServer::Authenticators::SQL
# database:
@@ -319,31 +321,33 @@ database:
#
# 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
+#authenticators:
+# -
+# 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
+#authenticators:
+# -
+# 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
@@ -360,44 +364,47 @@ database:
# 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)
+#authenticators:
+# -
+# 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
+#authenticators:
+# -
+# 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
+#authenticators:
+# -
+# 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.
@@ -421,19 +428,19 @@ database:
#
# Example:
#
-#authenticator:
-# class: FooModule::MyCustomAuthenticator
-# source: /path/to/source.rb
-# option_a: foo
-# another_option: yeeha
+#authenticators:
+# -
+# 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.
+# directory and a database, you can add just multiple authenticators.
#
-#authenticator:
+#authenticators:
# -
# class: CASServer::Authenticators::ActiveDirectoryLDAP
# ldap:
@@ -454,7 +461,7 @@ database:
# password_column: password
#
# During authentication, the user credentials will be checked against the first
-# authenticator and on failure fall through to the second authenticator.
+# authenticator and on failure fall through to the second authenticator and so on.
#
@@ -478,7 +485,7 @@ 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>
+infoline: Powered by <a href="http://github.com/rubycas/rubycas-server/">RubyCAS-Server</a>
# Custom views directory. If set, this will be used instead of 'lib/casserver/views'.
#custom_views: /path/to/custom/views

3 comments on commit b7f21b3

zuk replied Jun 8, 2012

Asking users to prefix all of their authenticator configs with a mysterious " - " line is confusing. Keep in mind many RubyCAS users have never seen a YAML file, and won't understand that this implies an array. I'd rather keep the authenticator config a single value for now. Users sophisticated enough to want to chain multiple authenticators can probably figure out the YAML array syntax for themselves.

Owner

mitfik replied Jun 8, 2012

That is true mysterious "-" can confuse :). I just wanted to avoid having two almost the same variable authenticator and authenticators because if both are setup is not clear which one will work. I will think that instead of using yaml syntax we can just do it like that:

authenticators:
   ldap:    # <- it will be name of the authenticator like (ldap, google, sql etc)
      class: CASServer::Authenticators::LDAP
      ...
   foo:
      class: FooModule::MyCustomAuthenticator
    ... 

This avoid us to have two very similar variables and provide clear syntax for config file. Give me know what do You think about that and I could implement it.

zuk replied Jun 15, 2012

Both authenticator and authenticators will work. I realize that might be confusing -- users might not know which one to use -- but the upside is that it doesn't matter if they make a mistake. Both authenticators and authenticator will work.

The reason we have this aliasing is because when rubycas-server was first released, you could only specify one authenticator. Later we added the ability to chain authenticators, so we added the authenticators alias. However I didn't remove the singular authenticator since this would break people's existing installations (everyone already deployed had authenticator as the key name).

I like the idea you're suggesting, with named keys for each authenticator. The problem is that unlike arrays, hashes like this in Ruby 1.8 are not normally ordered so there's no guarantee that the ldap authenticator will be checked before the foo authenticator. We might be able to get around this using an OrderedHash (and in 1.9 I think it would just work, since hashes are ordered) but I'm not sure this problem is worth the effort. Like I said, I suspect that people who are sophisticated enough to think about chaining authenticators are also sophisticated enough to figure out how to write an array in YAML..

Please sign in to comment.