Re: Authentication, Authorization

[Davi Leal]

Antenore Gatta wrote:
> > We can assume OpenID is less secure than local user/password, as it is.
> > So we can set the level of access/grant according to the log-in method
> > used, and ask for a higher level authentication if the user want to
> > realize a more critic operation as read-bank-status(medium),
> > transfer-money(critic), ...
>
> Yes, asking also for additional information to better trust the identity.
> It could be an optional second registration's step.
>
> By me a user can be:
>   * Logged (With or without OpenID)
>   * Registered (in the GNU Herds DB as an authorized and verified entity)
>   * Trusted (we know everything it's needed to trust him)

* Registration == email verification
    * Registration via email+password at GNU Herds.
    * Registration via OpenID (Automatic registration via OpenID).

* Log in == authentication
    * Log in via email+password at GNU Herds.
    * Log in via OpenID.

* Authorization == access control for each operation


> OpenID should provide access to all the (and only to) base functionality.

I agree.



> > So, maybe, we could authorize only some operation when users are logged
> > via OpenID. That is to say, we can have:
> >
> >  * several authentication mechanisms,
> >    and define the security level which each one offers, and
> >
> >  * an operation catalog,
> >    which lists the security level requirements to get authorization for
> >    realizing each operation.
>
> ACL based mechanism...
>
> The user log in with his preferred method, then each page has its own
> access level.
>
> So it means that we should add an access layer.

Fortunately the project is already using an ACL mechanism at 
Layer-4__DBManager_etc. If you download the source code [1] and go
to such directory you will see two files:

    * DB_Manager.php
        This file lists all the operations the webapp uses.

    * Access_Control_List.php
        This file has all operation types which requires special
        conditions to be allowed.

  [1] http://gnuherds.org/gnuherds-online.tar.gz


> > That is how my actual bank account works. My bank uses:
> >  * To log in: UserID + passphrase, and a card with a matrix of numbers,
> >    via HTTPS.
> >  * To transfer money: an additional special passphrase is required.
> > And even so, it is know it has been broken and lot of money lost. I think
> > the final solution is said to be something similar to GPG.
> >
> >
> > We could use the OpenID support to make it easier to register at GNU
> > Herds. Just a click and go avoiding the current process.
> >
> > We could define the OpenID security level to allow only:
> >    * create account
> >    * access account
> >    * modify account: job offers, pledges, etc.
> > and require the current gnuherds password, (and maybe other security
> > measures), to realize bank operations.
> >
> > Maybe we could add GPG keys to the authentication method pool.
>
> IMHO  GPG it's not easy to use for normal users and GPG (and similar
> technologies) are not so used (unlucky).
>
> About this I would prefer something like this:
>
> 1. Separation between static content and dynamic content.
>
>    Static content would be always accessible, no matter how, we don't
>    need to protect pages like "About GNU Herds", so everything we put
>    on the local file system will be accessible.
>
> 2. Access Layer and Access attributes
>
>    We would need a table with all the dynamic created pages with a
>    default attribute of "deny access". So if not differently set nobody
>    can access this page (URI or whatever we want).

The project has never protected the access to the home page [2], the
charter [3], or the faq [4], etc.

  [2] http://gnuherds.org/
  [3] http://gnuherds.org/charter
  [4] http://gnuherds.org/faq

All pages are dynamic due to they have to be dynamically translated. Do
not confuse dynamic page with page which requires authorization.


>    Each pages could have two different attributes, one for the kind
>    of access (deny, access, commit) and one with the level of access
>    (i.e. not logged, logged, registered, trusted).

There is not need to add complexity, that is to say, there is not need to
add attributes for pages.

Each page which _requires_ any kind of authorization execute some checks
at starting the processForm() method, at 
Layer-2__Business_logic/content/forms/*.php

For example:

  $error = "<p>Person: ".gettext("You can not access this section been
                       logged as")." '".$_SESSION['LoginType']."'.</p>";
  throw new Exception($error,true);


>    In this way we can have all the different possibilities and for
>    example to do a payment transaction a user must match the two
>    attributes, commit + trusted, of the requested page (the transaction one)

When the user log in, the webapp set several SESSION variables:

    $_SESSION['EntityId'] = $array[0];
    $_SESSION['LoginType'] = $array[1];
    $_SESSION['LoginEmail'] = $_POST['LoginEmail'];

    $_SESSION['SkillsAdmin'] = $array[2];
      // This set a flag to enable or disable the "Skill Administrator role"


Such variables are checked at starting of the processForm() method, at 
Layer-2__Business_logic/content/forms/*.php


We could set the new 'BankOperation' variable according to the authentication 
method used.

     $_SESSION['BankOperation'] = true or false;


Note: We could move some of the processForm() checks towards the 
Layer-4__DBManager_etc/Access_Control_List.php, but I am not sure yet if
it would be convenient, and besides it is not actually needed.

>
> It's just an idea... flames are welcome.


Nicodemo's QEMU virtual machine. It is handy to play with the development 
environment:

   http://www.leals.com/savane_and_gnuherds.dev-env.README
   http://www.leals.com/savane_and_gnuherds.dev-env.tar.gz