Fork me on GitHub

Authentication & authorization

During the installation the database seeder scripts created a few things to help get started:

  • The super user root.
  • The roles admins and users.
  • The permissions basic-authenticated, guest-only & open-to-all.

Additionally, on a development environment, a few more test users and permissions would have been created.

The relationship between users, roles & permissions is relatively simple: users are assigned roles (many-to-many) and roles are assigned permissions (many-to-many). This enables a simple role-based permission assignment system. For more information please refer to the documentation of the zizaco/entrust package. Also while not recommended by authorization best practices, user based permission assignment is supported. Permissions can be directly assigned to individual users if needed.

Where things get a little more interesting is the addition of the Route model. Not to be confused with the Route from Laravel, the Route model is still closely related to Laravel routes. In fact, all Routes can be automatically built by inspecting the Web site routing table. Initially, if you navigate to the Admin > Security > Routes page, you will be greeted with an empty table. To automatically load all routes defined within the Web site simply click on the load button. After a short delay, the page will reload and you will be able to assign any of the defined permission to each route.

Once Routes are assigned a single Permission each and permissions are assigned to Roles and finally, Users are granted Roles, then the matching AuthorizeRoute middleware can authorise or block access to all routes for both guest and authenticated users. This feature will probably not be used by any site user or even administrators, but by the site developer(s). In fact, one of the first things that I would recommend is to restrict all routes to the Route management pages to a permission given to developers only. What this feature does is make the authorization process very flexible, powerful and easy to change on the fly.

Some important hard-set rules to note are:

  • Except when specifically stated otherwise below, routes, permissions, roles and users can be disabled.
  • Routes
    • If a route is either not defined or not assigned any permission, it will not be accessible, except to the root user or any user granted the admins role.
    • Routes to the controllers AuthController and PasswordController are not restricted by the AuthorizeRoute middleware. Otherwise, users could not log in or reset their passwords.
    • A route assigned the permission open-to-all will be authorise for all users, authenticated or not.
    • A route assigned the permission guest-only will only be authorised for guest users, not for authenticated ones.
    • A route assigned the permission basic-authenticated will be authorised for any user that has logged into the system. No other permission will be required. But the same route will be denied for guest users.
    • Failure to be authorised to access a route will redirect to the error page 403 (access denied).
    • When loading Routes from the Web site routing table, all routes to the AuthController and PasswordController will be skipped over. Also, any route to the DebugBar will be skipped. If required they can be added by creating a route manually.
    • Disabling a route prevents the route from being accessible or authorised.
  • Permissions
    • The permissions guest-only and basic-authenticated cannot be edited or deleted.
    • A permission that is assigned to a Route or a Role cannot be deleted.
    • The permission guest-only cannot be assigned to any role. It is reserved for guest or un-authenticated users.
    • The permission basic-authenticated is forced onto every role.
    • The permission assignment for the role admins cannot be changed.
    • Disabling a permission prevents it from granting access to any route assigned to that permissions.
  • Roles
    • The roles admins and users cannot be edited or deleted
    • The role users is force onto every user.
    • Disabling a role prevent prevents the users assigned this role from getting the abilities of that role.
  • Users
    • The user root and any user with the admin role are not restricted by the AuthoriseRoute middleware. They can go anywhere they want, even to routes that are either disabled or not defined.
    • If a user is disabled while he is logged into and using the Web site, he will get automatically logged out the next time he tries to access a route protected by the AuthorizeRoute middleware.
    • The user root cannot be edited or deleted.
    • A user cannot disable or delete his own currently logged in user.