Super Admin Configuration and Implementation

Introduction

Super Admin is a special administration mode of Agasti that allows the system administrator to bypass the standard authentication process to log in to the system. It is intended to be used during installation and initial configuration, troubleshooting, and recovery from a state where logging in with standard authentication is not possible.

Configuration

Super Admin is both configured and enabled in the @config/config.yml@ file. The @super_user@ and @super_pass@ values determine the username and password for the Super Admin account, while the @auth_method@ setting determines which authentication method is used. For Super Admin to be enabled, @auth_method@ must be set to @bypass@.

param:
  super_user: admin
  super_pass: secret
auth_method:
  value: bypass

Implementation

The Super Admin feature is implemented in the @agSudoUser@ class, which extends the @sfGuardSecurityUser@ class. Below is the documentation for the @agSudoUser@ class by Charles Wisniewski.

This document serves to briefly explain the purpose of the agSudoAuth class, the implementation behind it and the interface to it. The files affected and their paths are listed below:

Agasti/dev/apps/frontend/config/app.yml
Agasti/dev/apps/frontend/config/security.yml
Agasti/dev/apps/frontend/config/config.yml
Agasti/dev/apps/frontend/lib/agSudoSigninForm.class.php
Agasti/dev/apps/frontend/lib/myUser.class.php
Agasti/dev/apps/frontend/lib/agSudoUser.class.php
Agasti/dev/apps/frontend/lib/agSudoAuth.class.php
Agasti/dev/apps/frontend/lib/sfGuardValidatorCustomUser.class.php

What is the purpose?

The purpose of the Agasti Sudo Authentication class (agSudoAuth.class.php) is to extend the default authentication method (sfDoctrineGuard). It is done in such a way that would allow a system administrator or other interested user to log in as a super administrator when the normal authentication is broken for whatever reason. The Agasti Sudo Authentication method should only be used in emergency.

How is this implemented?

The implementation of the Agasti Sudo Authentication is a basic extension of the sfGuardSecurityUser. (@dev/Agasti/apps/frontend/config@)

In an application's config directory (@dev/Agasti/apps/frontend/config@) there exists an app.yml file. In the @app.yml@ file the @sf_guard_plugin@'s @check_password_callable@ method is modified, and the @signin_form@ that is called upon login:

  sf_guard_plugin:
    check_password_callable: [agSudoAuth, authenticate]
  sf_guard_plugin_signin_form: agSudoSigninForm

This is where authentication can be switched between @default@ and @agSudoAuth@.

The default @sfGuardSecurityUser@ class checks whether a user is valid prior to checking the password: if the user does not exist, the password is not checked.

@agSudoSigninForm.class.php@ extends the base signin form for sfDoctrineGuard. It then changes the validator to @sfGuardValidatorCustomUser.class.php@. The extension changes the authentication to check if a user exists, if it does not, creates a user and password as specified in @config.yml@ (upon installation).

How is this interfaced?

Since the default authentication method is extended, the same hooks are used in the Symfony framework to achieve security through the Agasti Sudo Authentication class. @security.yml@ should not be modified: it is the main place where security is enabled/disabled and some mode of authentication should always exist within Agasti.


QR Code
QR Code agasti:mayon:super_admin_configuration_and_implementation (generated for current page)