[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Authentication, Authorization

From: Davi Leal
Subject: Re: Authentication, Authorization
Date: Fri, 18 Jul 2008 00:51:27 +0200
User-agent: KMail/1.9.7

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.


> > 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.


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 

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 

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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]