7.1. Introduction

Usually, you will want to be able to identify the users of your application, and restrict their access to certain parts of the system based on the individual user and/or that user's roles within the system.

When talking about users and access control, we need to remember that the topic is composed of three different aspects:

  • User authentication: identifying the user via a login or sign-in process (or, alternatively, noting that the user is unidentified or anonymous).

  • User roles: the groups or roles that user plays within the system.

  • User access: what parts of the system the user is allowed to work with, based on his identity and/or roles within the system.

In Solar, each of those aspects is represented by a separate set of adapter-based classes:

  • Solar_Auth provides adapters that allow users to authenticate against various identity storage backends: SQL tables, LDAP servers, email servers, etc. The authentication system is completely automated and does not require a controller to activate or maintain it.

  • Solar_Role provides adapters that, given a username (i.e., a user's "handle"), will find out the groups (i.e., "roles") to which a user belongs. The adapters include file-based and SQL-table-based storage backends.

  • Solar_Access provides adapters that look up what controllers and actions a user is allowed to access, based on that user's handle and roles. Access control backends include files and SQL tables.

Because all three of those aspects are related to each other, Solar provides a Solar_User class to compose an instance of each adapter into a single object. This provides a collection point for information about the current user: the user's authentication status and authenticated identity (if any), the user's roles, and the access controls on the user.



Local