UC Berkeley Rails Security

UCB::Rails::Security simplifies CAS auth and ldap authz within your rails application by adding custom filters to your rails controllers.

Description

This plugin adds authentication/authorization to your rails application. Currently CAS is the only supported authentication scheme. Authorization is handled by various filters that this plugin provides. The filters can utilize: values from a users and or roles table as well as ldap attributes of the authenticated user. These filters are typically added to your application controller by including the ucb_rs_controller_methods module. Example: user has CAS authenticated

class ApplicationController < ActionController::Base
  include UCB::Rails::Security::ControllerMethods
  before_filter :filter_logged_in
end

This would only allow access to if the user has CAS authenticated

Installation

These installation instructions assume that you already have a database configured for your rails application and that you have already run the initial rake db:migrate command to setup your schema_info table.

From RAILS_ROOT run:

script/generate ucb_rails_security

This will generate scaffolding for a rudimentary user/role administration interface.

It will also install a db:migration: xxx_create_ucb_rails_security_tables.rb, where xxx is the next highest available migration number.

Now run: rake db:migrate to run the migrations.

Configuration

Configuration for this plugin is handled in the file: RAILS_ROOT/config/initializers/ucb_security_config.rb

You probably want to uncomment the first config option so your application can use the users table. The file itself has comments explaining the options.

Before you can use the users table, you must create a security user.

Run the following from RAILS_ROOT:

rake ucb:create_security_user UID=#{your_uid}

This adds you to the users table and gives you the ‘Security’ role.

By default, you must have the ‘Security’ role to access the administrative interface. Now start your application server and point your browser to:

localhost:3000/ucb_security/

You should be redirected to CAS. CAS authenticate and you should now have access to the ucb_security administrator pages.

Customization

The ucb_security scaffolding includes an rudimentary administrative interface to manage users and roles within your rails application. Most of the ucb_security scaffolding has been installed under the namespace ucb_security:

RAILS_ROOT/apps/controller/ucb_security
RAILS_ROOT/apps/views/ucb_security
RAILS_ROOT/apps/helpers/ucb_security
RAILS_ROOT/public/stylesheets/ucb_security.css

The models, however, are installed directly beneath your models directory:

RAILS_ROOT/apps/models/user
RAILS_ROOT/apps/models/roles
RAILS_ROOT/apps/models/user_roles

Finally, the ucb_security scaffolding added custom routes to the top of your route file:

RAILS_ROOT/config/routes.rb

Don’t like how something looks? Feel free to change the views, or the stylesheet. If you start changing the models or routes, make sure you add tests!

Usage

Authentication

The simplest use of this module is to require that users be authenticated by CAS, i.e., they have entered a valid CalNet id and passphrase.

The following controller requires a user be authenticated:

class MyController < ApplicationController
  before_filter :filter_logged_in
end

If the user is already logged in (has been CAS authenticated) then the user can access the controller.

If not logged in the user will be redirected to the CAS authentication service. Upon successful authentication the user will be redirected to the originally requested url.

Authentication Methods

The only authentication method supported is CAS [auth.berkeley.edu/cas/login].

More info about CAS.

Authorization

LDAP Filters

UCB::Rails::Security is closely integrated with, and in fact depends on UCB::LDAP. Authenticated users are looked up in the LDAP directory and the corresponding UCB::LDAP::Person instance is stored in the Rails session.

Applications have easy access to a logged in user’s LDAP attributes for general purposes, but more importantly these attributes can be used in controller filters with minimal effort (next section). Applications can manage access to controllers based on LDAP attributes.

This controller can only be accessed by UCB employees:

class MyController < ApplicationController
  before_filter :filter_ldap_employee?
end

Note that this filter is dynamically created and queries the employee? method of the user’s UCB::LDAP::Person entry to do its work.

See UCB::Rails::Security::ControllerMethods for more information.

User and Role Filters

If an application has User and Role tables, they can be used to control authorization.

User Filters

This controller is restricted to users in the user table:

class MyController < ApplicationController
  before_filter :filter_in_user_table
end

This controller is restricted to users that can update:

class MyController < ApplicationController
  before_filter :filter_user_can_update?
end

Note that this filter is dynamically created by sending the can_update? message to the user instance.

Any filter of the form “:filter_user_method” will return true if the user instance returns true when sent method.

Role Filters

This controller is restricted to users who have the admin role:

class MyController < ApplicationController
  before_filter :filter_role_admin
end

Note that this filter is dynamically created and queries the roles for the user to see if “admin” is one of the roles.

See UCB::Rails::Security::ControllerMethods for more information.

More Information

  • UCB::Rails::Security for configuration

  • UCB::Rails::Security::ControllerMethods for filters, form helpers, etc.

Version

:include: ./version.yml

Author

Steven Hansen ([email protected]) Steve Downey