This repository has been archived on 2023-02-21. You can view files and clone it, but cannot push or open issues or pull requests.
Go to file
Mikaël Ates 8e6725aa21 Update MANIFEST.in. 2012-06-20 15:48:15 +02:00
acs Modify version. 2012-06-20 15:35:54 +02:00
.gitignore Adding .gitignore file 2011-06-09 07:45:27 +02:00
AUTHORS.txt Add author file. 2012-06-20 15:28:52 +02:00
COPYING COPYING file updated. 2012-06-20 15:26:36 +02:00
MANIFEST.in Update MANIFEST.in. 2012-06-20 15:48:15 +02:00
README.rst Modify README. 2012-03-19 18:01:54 +01:00
__init__.py [veridic] Project initialization 2011-01-18 18:36:29 +01:00
ez_setup.py Add necessary files for distribution. 2012-06-20 15:28:39 +02:00
manage.py [veridic] Project initialization 2011-01-18 18:36:29 +01:00
setup.py Add necessary files for distribution. 2012-06-20 15:28:39 +02:00

README.rst

=====================================================
Veridic - Towards a centralized access control system
=====================================================

Veridic is a project containing for now a single application called A.C.S. or
ACS for Access Control System.

ACS is an application providing an access control decision point.
An access control policy configuration is done through a Web interface.
For now, request decisions can only be requested through the Web interface.
Until request can be made by PEP though another interface, ACS can onlt be
used to design policies and verify their conformance with the RBAC model.

This application aims at being a policy administration point (PAP) and a
policy decision point (PDP).


Features
--------

Policy administration:
- Define policies based on Identity-Based Access Control (IBAC), Role-BAC
  (RBAC) and Attributes-BAC (ABAC) permissions

ACS administration:
- The access control system possesses its access control system that governs
ACS and all the policies

Web interface:
- Web interface to define policies
- Web interface to administrate the system

Other:
- Define objects with regexp
- Permission delegations

The ROADMAP is coming soon.


Dependencies
------------

(Optional) For graph display of policies: networkx and matplotlib.


Quick Start
-----------

** Before running the ACS application, you must execute the initialization
script **

    Initialization script:
        - Initialize ACS.
        - Create a root user with all rights.
        - Inject the attribute definitions in the database.

    Run with:
        python manage.py initialize-acs <username> [--existing] \
        [--without-abac] [--reload-abac]

        --existing
            The user already exists in the database.
            Else, the user is created.

        --reload-abac
            Skip the initial configuration and update the
            attribute definitions.

            *** Be sure to use --reload-abac option if it is not the first
            time the script is run and it is not expected to reinitialize
            ACS ***

        --without-abac
            Only the initial configuration.

    Reinitialization:
        python manage.py sqlclear acs | python manage.py dbshell \
        && python manage.py syncdb \
        && python manage.py initialize-acs <username> [--existing] \
        [--without-abac] [--reload-abac]

    If you want to clear all the attribute definitions use
        python manage.py sqlclear abac

    WARNING: The reinitialization or rerunning the initialization script
    assume that you want to reset ACS and you will loose all policies.

To run the application with the django embedded server, launch the following
command:

    python manage.py runserver

You should see the following output:

  Validating models...
  0 errors found

  Django version 1.2, using settings 'authentic.settings'
  Development server is running at http://127.0.0.1:8000/
  Quit the server with CONTROL-C.

  You can access the running application on http://127.0.0.1:8000/


Overall explanations
--------------------

In ACS, a permission define an access control rule with the form
permission(who, what, how), with 'who' a user or a role, 'what' an object or a
view and 'how' an action or an activity.

Roles contain users, views contain objects, activities contain actions.
Users, roles, objects, views, actions, activities are entities.

A policy is a set of entities and permissions.

ACS is an application to design access control policies. Then, ACS can be
requested to deliver access control decisions on the access control policies
defined.

In ACS you can create as many policies as you want. Each policy define a
namespace where entities are unique. E.g. two actions with the same name can
be cerated in two different policies and are considered as completly different
entities.

One important point is that permissions are not set on the User objects but on
aliases of users. Then, a single Django user must have an alias declared in
each policy it is expected to grant it permissions. It is thus possible to
declare an alias in a policy without having a corresponding existing Django
user.

Helper functions on the Web interface help in declaring all the known django
users in a policy. These functions can be used each time new django users are
added.

Managing a user and aliases is an easy way to have a global representation of
a user in the whole policies. It is fast to see for a same user which are its
different identifiers in the different policies.

ACS is an application where an access control applies. It means that the
application contains a policy to define the access control permissions to
adminstrate the ACS application. This access control policy is named "Default"
with a namespace "Default". Every entity in that namespace is thus an entity
employed in the access control on adminstration of ACS. The management of this
policy is done through the web interface functions, in other words, the
default policy is not directly managed adding actions, users or objects.

In other words, the administration of the access control system is an
application by itself, the application, for the purpose of administration, is
also a PAP of the access control policy on the access control system, a PDP on
the access to modify the access control policy and a PEP to enforce these
decisions when modifying the access control policy.

The functions used are the following:

- manage root administrators : a root administrator can manage the whole
system. - manage user administrators : a user administrators can add and
remove users, can declare users in all policies (give a user an alias in the
policy), can create-modify-remove roles in any policies, can declare policy
user administrators, can add any user or role in any role inside any policy,
can set a permission on any role or user in any policy.

- manage policy root administrators : a policyroot administrator can manage a
whole policy.
- manage policy user administrators : a policy user administrators can declare
any users in the policy, can create-modify-remove roles in this policy, can
add any user or role in any role inside the policy, can set a permission on
any role or user in the policy.

- manage object and view creators : a object and view creator can
create-modify-remove objects and views in the policy, can add any object or
view in any view inside the policy, can set a permission on any object or view
in the policy.

- manage action and activity creators : a action and activity creator can
create-modify-remove actions and activities in the policy, can add any action
and activity in any view inside the policy, can set a permission on any action
and activity in the policy.

In comparison with a user with the role policy root administrator, a user that
has the three roles (policy user administrator, object and view creator,
action and activity creator) can administrate the whole policy but cannot add
users to these roles or to the policy root administrator role.

Moreover, inside each policy, it is feasible to define fined grained
permissions to administrate a subpart of the policy using administration
roles, wiews and permissions. Any user with at least an administration
permission is considered as a policy administrator.


Access control model
--------------------

All that is not authorized is denied.

A permission(WHO,WHAT,HOW) is the right of WHO on WHAT to perform HOW.

The access control model is role-based. With an RBAC system, WHO may be a user
or a role:
is_authorized(WHO,WHAT,HOW) :- permission(WHO,WHAT,HOW).
is_authorized(WHO,WHAT,HOW) :- permission(X,WHAT,HOW), has_role(X,WHO).

The role hierarchy is used for permission heritance.

Consider r1 'is a' r2 and 'is a' r3 (r2 and r3 are juniors of r1)
assigned_permissions(r1) :- assigned_permissions(r2).
assigned_permissions(r1) :- assigned_permissions(r3).
(All permissions assigned to r2 and r3 are also assigned to r1)

assigned_users(r2) :- assigned_users(r1).
assigned_users(r2) :- assigned_users(r1).
(All users assigned to r1 are also assigned to r2 and r3)

The heritage tree of r1 is then:
assigned_permissions(r1) = direct_permissions(r1) U_i assigned_permissions(ri)
ri being all the junior roles of r1.

Then, if the user has the role r1, it has the rights given by all the
permissions direclty assigned to r1 and all the permissions assigned to roles
below in the hirarchy.

We do not handle interdictions. Mainly due to conflict with permission
heritance.

We do not handle obligation for now. It is just a question of semantic and
what information can be retreived from the policy. An obligation is a
permission when a usage control is assumed to verify that some permissions are
really used, potentially with somme constraints.

We do not handle sessions and role activation, as we do not handle separation
of duty (SoD) nor information flow control.

The access control model also relies on abstractions of objects (WHAT) and
actions (HOW).

The abstraction for object is the view concept. A view may contain objects and
other views. It means that a view may contain any entity of the model.

A permission on a view gives the right of WHO to do HOW on all the objects
contained in this view, or in any view below in the hirarchy of views.

The abstraction for action is activity. An activity may contain actions and
other activities.

A permission on an activity gives the right of WHO on WHAT to do all the
actions contained in this activity or any activity below in the hirarchy of
activities.

The abstract entities and the heritance make often talk about the range of a
permision.


Copyright
---------

VERIDIC is copyrighted by Entr'ouvert and is licensed through the GNU Affero
General Public License as published by the Free Software Foundation, either
version 3 of the License, or (at your option) any later version. A copy of the
whole license text is available in the COPYING file.