This document will explain to what extent security is considered in Exponential. During the design of Exponential security was one of the factors constantly considered. The performance and flexibility were important factors during the design.

When you consider security there are two main parts you need to consider, authentication and authorization. Authentication is a method of recognizing the user which accesses the system, i.e. login. Authorization defines what the user has access to when already logged in.

Authentication

Exponential identification is based on the combination of username and password or e-mail and password. To log in a user supplies the combination of username/e-mail and password to the system. Exponential will then look for a hashed version of the password in the user table. The password is normally stored as an md5 of the password, but this is configurable. This means that the original password is not stored, but encrypted with a one way encryption. If the system matches a username/e-mail in combination with a password hash the user is authenticated and logged in to the system.

Exponential sets a session variable for the current session which indicates the current authenticated user. This session variable is stored in the Exponential database and is not sent from the server in any way.

Every session is identified by a session key, which is a unique md5 hash. This session key is normally stored in a cookie, but it can also be appended to the URL. The latter is to be considered less secure as the session key then will be stored in the apache access log and is therefore accessable by any user on the server which has read access to apaches access log. It's up to the PHP configuration to decide if URL based sessions are supported.

As long as the session key is kept from other users the authentication is secure. Session keys are sent from the users webbrowser to the server on every page load. It is possible to sniff the TCP traffic to get access to this key. If the connection between the users webbrowser and the server is using SSL encryption it will be alot harder for the user to get access to the session key.

To get a more secure setup you can set the session timeout to a lower value.

If the user is not logged in he is authenticated as the anonymous user in the system. The Exponential administrator can restrict the access of the anonymous user at the same level as any other user. It serves the function of a default user.

TODO — Image not available in archive

Title:   Authentication Flow Diagram
File:    /doc/images/authentication.gif

What this image shows:
Diagram showing the Exponential CMS authentication process. Illustrates how a web request is matched against the site access configuration, how the anonymous user is resolved as the default when no session cookie is present, and how the login module authenticates named users and establishes a session. Shows the role of the anonymous user account in the user system.

Replacement instructions:
Redraw as a flow diagram based on sdk/doc/view/security_handling. Save as /doc/images/authentication.gif

See /sdk/missing.html for the full list of missing images.

Authorization

The authorization in Exponential is done by the role based permission system. This is a central component in Exponential and will automatically support new or 3rd pary plugin modules.

Exponential 3 is secure by default, i.e. you do not have access to do anything with the system unless directly specified.

Exponential will first check if the user is logged in (authenticated), then if the user has access to the current site access ( admin/user ). You can require that the user needs to be logged in, i.e. be authenticated as another user than the anonymous (default) user.

If the user has access to the current site access Exponential will check if the user has access to the current module. Users can have access to either the whole module or specific functions in that module. If the user has access to the whole module function level permission checks are skipped and access granted.

If the user has access to only some functions in the given module then Exponential will check if the current function matches one of the functions the user has access to. If the function matches access is granted.

It is also possible to limit the specific function with function limitations. This can e.g. be a limitation to only read articles in a specific section. When the limitation matches the current function, the given function is responsible for only returning the data which matches the limitation or return access denied.

This means that you have access control on both functional and data level.

It is possible to specify that the user has access to everything, then the permission check on module and function level is bypassed. This setting is normally used for administrators.

The diagram below shows an overview of the permission system.

TODO — Image not available in archive

Title:   Authorization / Permissions Overview Diagram
File:    /doc/images/authorization.gif

What this image shows:
Diagram showing the Exponential CMS permission/authorization system. Illustrates the check sequence: is the user an administrator (bypass all checks)? → module-level access check → function-level access check → optional limitation check (section, class, owner, etc.). Shows how roles and policies combine to grant or deny access to modules and functions.

Replacement instructions:
Redraw as a flow diagram based on sdk/doc/view/security_handling. Save as /doc/images/authorization.gif

See /sdk/missing.html for the full list of missing images.