Authentication System

From Project Auriga

Jump to: navigation, search

The authentication system is being designed with the needs of Freelock Computing in mind.

We break this down into the typical parts of a system:

  • Authentication
  • Authorization

Authentication covers identifying WHO a user is. Authorization determines WHAT they have access to. We break these down into multiple phases.

All controller pages should specify a minimum access level right at the top of the page, before calling config.php. Config.php should then be able to override this access level for particular pages, allowing for custom access level for particular sites. This mechanism is being worked out now.

Contents

[edit] Authentication

Authentication is often shortened to "authn". In the config file, you can register authentication sources using $db->register_authn($type, $args). $type should be a data source plugin that has already been registered. $args are an arbitrary set of arguments passed to the plugin, generally an associative array of the user table, the user column, and the password column. This is passed to the set_auth_src method on the plugin.

Any plugin providing authentication should implement an authenticate($user,$pw) method.

We currently have two authentication plugins: the main auriga plugin, and a custom "email" plugin which is looking in our database of hosted email addresses. LDAP would be another good source here.

The return from the authenticate() method should be an associative array with these fields (minimum):

  • id
  • level
  • type (customer, contractor, employee, manager)
  • primary_group (used to look up account)
  • plugin (name of the plugin that authenticated the result, for future use in authz)

[edit] Level

This part is subject to change. Here are the current user levels: 

-1 - user found, but not authenticated
0 - none, not logged in, wrong password/no password
1 - Regular Customer
2 - Customer - in Finance
3 - Customer - in Admin
4 - Contractor
5 - Employee - Regular
6 - Member
7 - Owner
8 - Manager

[edit] authentication()

The authentication method is called only on login. Authentication details, aside from password, is then stored in the session. So authentication is called serially on all authn objects until it runs out, or until there's a result found.

[edit] Authorization

Authorization is often shortened to authz. Authz is stored in an array in the registry, and may be overridden in the config.php file. The user->authz method can then be called with module_id, account, action, which will walk the authz permissions to determine whether the action is authorized.


[edit] Session Login

As currently implemented, we have a cookie/session-based login. Now that we're using Dojo and XMLHttpRequest for the new code, we're going to draw out a new authentication system using http auth, so that our users can log into Project Auriga and be authenticated for other systems, making it play well in a single-sign on environment.

Here are some notes about implementing the system while the old system is still in production.

First of all, if we use xhr to authenticate, we need to have access to all the scripts in the main page. Using dojo.require is an effective way of loading the bulk of the code after a successful authentication, but we need to load this code on a callback.

We already call session_login.php on all calls to the system, so we can enforce http auth on every request instead of cookies. However, we don't yet have a good resource framework in place.

Here are the code generations we currently have in place, and need to consider when changing session_login.php:

1. Non-AJAX sections. The public parts of the site should fall back to non-AJAX, so we can keep the page load times fast. Need to support cookie logins for this area.

2. First generation code. The timeclock.php section has no dojo code available. Can probably use regular http auth logins, since this is internal.

3. Second generation code. Same as #2, this is dojo 0.4 code, which can be protected with normal http auth.

4. Third generation code. Dojo 0.9/trunk code. This is where to focus efforts and make sure we have a workable flow.

So basically, we can start by requiring http auth for anything over level 3.

[edit] Session Auth scenarios

State: Not logged in.
Request: Page
Result: Page with login form.

State: Not logged in.
Request: Log in
Result: 200, 401, or 403.

State: Not logged in.
Request: Anything else
Result: Authorize(Public) ? Response : 401

State: Logged in
Request: authorized
Result: response

State: Logged in
Request: not authorized
Result: 403

State: Logged in
Request: Log out
Result: 200 (allow new password), "you are now logged out"

[edit] Authorization flow chart

  • if action is log out, return logout template and accept credentials (allows js to set bad password for effective log out).
  • if action is log in, authenticate login, and on success, authorize request.
  • if user is logged out, authorize request.
    • If success, continue (public content)
    • If failure, check for view.
      • If page, return login template with message
      • If ajax, return 401 not authenticated.
  • if user is logged in, authorize request.
    • If success, continue (authorized).
    • If failure, return 403 not authorized.

[edit] Client side/controller design

When page is requested:

  • If authenticated, load all scripts, full menus
  • If not authenticated, load minimal scripts, public menu

When xhr login is requested:

  • on failure, show login form and error message
  • on success, require all other scripts and request view

When response returns 403:

  • show "not authorized" message.

When response returns 401:

  • show login form
  • add original request variables to post
Retrieved from "http://www.projectauriga.org/wiki/Authentication_System"
Personal tools