simpleSAMLphp modules
==================================================

<!-- 
	This file is written in Markdown syntax. 
	For more information about how to use the Markdown syntax, read here:
	http://daringfireball.net/projects/markdown/syntax
-->

  * Version: `$Id: simplesamlphp-modules.txt 1241 2009-02-06 08:11:55Z andreassolberg $`


This document describes how the module system in simpleSAMLphp
works. It descibes what types of modules there are, how they are
configured, and how to write new modules.

Overview
--------

There are currently three parts of simpleSAMLphp which can be stored in modules - authentication sources, authentication processing filters and themes. There is also support for defining hooks - functions run at specific times. More than one thing can be stored in a single module. There is also support for storing supporting files, such as templates and dictionaries, in modules.

The different functionalities which can be created as modules will be described in more detail in the following sections; what follows is a short introduction to what you can du with them:

 - Authentication sources implement different methods for authenticating users, for example simple login forms which authenticate against a database backend, or login methods which use client-side certificates. 
 - Authentication processing filters perform various tasks after the user is authenticated and has a set of attributes. They can add, remove and modify attributes, do additional authentication checks, ask questions of the user, +++. 
 - Themes allow you to package custom templates for multiple modules into a single module.


## Module layout

Each simpleSAMLphp module is stored in a directory under the the
`modules`-directory. The module directory contains the following
directories and files:

default-disable
:   The presence of this file indicates that the module is disabled
    by default. This module can be enabled by creating a file named
    `enable` in the same directory.

default-enable
:   The presence of this file indicates that the module is enabled
    by default. This module can be disabled by creating a file named
    `disable` in the same directory.

dictionaries
:   This directory contains dictionaries which belong to this
    module. To use a dictionary stored in a module, the extended tag
    names can be used:
    `{<module name>:<dictionary             name>:<tag name>}` For
    example, `{example:login:hello}` will look up `hello` in
    `modules/example/dictionaries/login.php`.

:   It is also possible to specify
    `<module             name>:<dictionary name>` as the default
    dictionary when instantiating the `SimpleSAML_XHTML_Template`
    class.

hooks
:   This directory contains hook functions for this module. Each
    file in this directory represents a single function. See the
    hook-section in the documentation for more information.

lib
:   This directory contains classes which belong to this module.
    All classes must be named in the following pattern:
    `sspmod_<module name>_<class name>` When looking up the filename of
    a class, simpleSAMLphp will search for `<class name>` in the `lib`
    directory. Underscores in the class name will be translated into
    slashes.

:   Thus, if simpleSAMLphp needs to load a class named
    `sspmod_example_Auth_Source_Example`, it will load the file named
    `modules/example/lib/Auth/Source/Example.php`.

templates
:   These are module-specific templates. To use one of these
    templates, specify `<module name>:<template             file>.php`
    as the template file in the constructor of
    `SimpleSAML_XHTML_Template`. For example, `example:login-form.php`
    is translated to the file
    `modules/example/templates/default/login-form.php`. Note that
    `default` in the previous example is defined by the `theme.use`
    configuration option.

themes
:   This directory contains themes the module defines. A single
    module can define multiple themes, and these themes may override
    all templates in all modules. Each subdirectory of `themes` defines
    a theme. The theme directory contains a subdirectory for each
    module. The templates stored under `simplesamlphp/templates` can be
    overridden by a directory named `default`.

:   To use a theme provided by a module, the `theme.use`
    configuration option should be set to
    `<module name>:<theme name>`.

:   When using the theme `example:blue`, the template
    `templates/default/login.php` will be overridden by
    `modules/example/themes/blue/default/login.php`, while the template
    `modules/core/templates/default/loginuserpass.php` will be
    overridden by
    `modules/example/themes/blue/core/loginuserpass.php`.

www
:   All files stored in this directory will be available by
    accessing the URL
    `https://.../simplesamlphp/module.php/<module             name>/<file name>`.
    For example, if a script named `login.php` is stored in
    `modules/example/www/`, it can be accessed by the URL
    `https://.../simplesamlphp/module.php/example/login.php`.

:   To retrieve this URL, the
    `SimpleSAML_Module::getModuleURL($resource)`-function can be used.
    This function takes in a resource on the form `<module>/<file>`.
    This function will then return an URL to the given file in the
    `www`-directory of `module`.


## Authentication sources

An authentication source is used to authenticate a user and receive a set of attributes belonging to this user. In a single-signon setup, the authentication source will only be called once, and the attributes belonging to the user will be cached until the user logs out.

Authentication sources are defined in `config/authsources.php`. This file contains an array of `name => configuration` pairs. The name is used to refer to the authentication source in metadata. When configuring an IdP to authenticate against an authentication source, the `auth` option should be set to this name. The configuration for an authentication source is an array. The first element in the array identifies the class which implements the authentication source. The remaining elements in the array are configuration entries for the authentication source.

A typical configuration entry for an authentication source looks like this:

    'example-static' => array(
      /* This maps to modules/exampleauth/lib/Auth/Source/Static.php */
      'exampleauth:Static',
    
      /* The following is configuration which is passed on to the exampleauth:Static authentication source. */
      'uid' => 'testuser',
      'eduPersonAffiliation' => array('member', 'employee'),
      'cn' => array('Test User'),
    ),

To use this authentication source in a SAML 2.0 IdP, set the
`auth`-option of the IdP to `'example-static'`:

    '__DYNAMIC:1__' => array(
      'host' => '__DEFAULT__',
      'privatekey' => 'server.pem',
      'certificate' => 'server.crt',
      'auth' => 'example-static',
    ),

### Creating authentication sources

Authentication sources are implemented by creating a class which is a subclass of the `SimpleSAML_Auth_Source`-class. They must implement at least one function - `authenticate`. This function may can either update the `$state`-array it receives with the attributes of the user and return, or it may save the state and redirect the user to another page for authentication. It redirects, it should later retrieve the state array, update it with the attributes and call `SimpleSAML_Source_Auth::completeAuth($state)`.

There is also a simpler way to implement many authentication sources. If the authentication source only needs a username and password from the user, it may subclass `sspmod_core_Auth_UserPassBase`, and implement a single function - `login($username, $password)`. This function receives the username and password the user gives, and should return an associative array with the attributes of the user. If the username or password is incorrect, it should throw an exception: `SimpleSAML_Error_Error('WRONGUSERPASS')`

Requirements for an authentication source:

-   Must be derived from the `SimpleSAML_Auth_Source`-class.

-  
    If a constructor is implemented, it must first call the parent
    constructor, passing along all parameters, before accessing any of
    the parameters. In general, only the $config parameter should be
    accessed.

-  
    The `authenticate(&$state)`-function must be implemented. If this
    function completes, it is assumed that the user is authenticated,
    and that the $state array has been updated with the user's
    attributes.

-  
    If the `authenticate`-function does not return, it must at a later
    time call `SimpleSAML_Auth_Source::completeAuth` with the new
    state. The state must be an update of the array passed to the
    `authenticate`-function.

-  
    No pages may be shown to the user from the `authenticate`-function.
    Instead, the state should be saved, and the user should be
    redirected to a new page. This must be done to prevent
    unpredictable events if the user for example reloads the page.

-  
    No state information about any authentication should be stored in
    the authentication source object. It must instead be stored in the
    state array. Any changes to variables in the authentication source
    object may be lost.

-  
    The authentication source object must be serializable. It may be
    serializes between being constructed and the call to the
    `authenticate`-function. This means that, for example, no database
    connections should be created in the constructor and later used in
    the `authenticate`-function.


Authentication processing filters
---------------------------------

*Authentication processing filters* is explained in a separate document:

  * [Authentication processing filters](http://rnd.feide.no/content/authentication-processing-filters-simplesamlphp)



## Themes

This feature allows you to collect all your custom templates in one place. The directory structure is like this: `modules/<thememodule>/themes/<theme>/<module>/<template>` `thememodule` is the module where you store your theme, while `theme` is the name of the theme. A theme is activated by setting the `theme.use` configuration option to `<thememodule>:<theme>`. `module` is the module the template belongs to, and `template` is the template in that module.

For example, `modules/example/themes/test/core/loginuserpass.php` replaces `modules/core/templates/default/loginuserpass.php`. `modules/example/themes/test/default/frontpage.php` replaces `templates/default/frontpage.php`. This theme can be activated by setting `theme.use` to `example:test`.

## Hook interface

The hook interface allows you to call a hook function in all enabled modules which define that hook. Hook functions are stored in a directory called 'hooks' in each module directory. Each hook is stored in a file named `hook_<hook name>.php`, and each file defines a function named `<module name>_hook_<hook name>`.

Each hook function accepts a single argument. This argument will be passed by reference, which allows each hook to update that argument.

There is currently a single user of the hook interface - the front page. The front page defines a hook named `frontpage`, which allows modules to add things to the different sections on the front page. For an example of this, see `modules/modinfo/hooks/hook_frontpage.php`.



