WebAccess Admin Guide


1. Introduction, using roles
2. WebAccess admin interface
3. Example pages, illustrating snapshots
4. Managing accounts / Access policy
5. Managing login methods
6. Firewall-like role definitions


  WebAccess is a common RBAC, role based access control, for all of
  Invenio. This means that users are connected to roles that cover
  different areas of access. I.e administrator of the photo
  collection or system librarian. Users can be active in
  different areas and of course connected to as many roles as needed.

  The roles are connected to actions. An action identifies a task you
  can perform in Invenio. It can be defined to take any number of
  arguments in order to more clearly describe what you are allowing
  connected users to do.

  For example the system librarian can be allowed to run bibindex on
  the different indexes. To allow system librarians to run the
  bibindex indexing on the field author we connect role system
  librarian with action runbibindex using the argument

  Additionally, roles could have firewall-like role
  definitions. A definition is a formal description of which
  users are entitled to belong to the role. So you have two ways for
  connecting users to roles. Either linking explicitly a user with the
  role or describing the characteristics that makes users belong to
  the role.

  WebAccess is based on allowing users to perform actions. This means
  that only allowed actions are stored in the access control engine's


All the WebAccess Administration web pages have certain
features/design choices in common

- Divided into steps

  The process of adding new authorizations/information is
  stepwise. The subtitle contains information about wich step you are
  on and what you are supposed to do.

- Restart from any wanted step

  You can always start from an earlier step by simply clicking the
  wanted button. This is not a way to undo changes! No information
  about previous database is kept, so all changes are definite.

- Change or new entry must confirmed

  On all the pages you will be asked to confirm the change, with
  information about what kind of change you are about to perform.

- Links to other relevant admin areas on the right side

  To make it easier to perform your administration tasks, we have
  added a menu area on the right hand side of these pages. The menu
  contain links to other relevant admin pages and change according to
  the page you are on and the information you have selected.


I. Role area
II. Example - connecting role and user

I. Role area

  Administration tasks starts in one of the administration areas. The
  role area is the main area from where you can perform all your
  managing tasks. The other admin areas are just other ways of

Role Administration

administration with roles as access point
add or remove users from the access to a role and its priviliges.
these terms means almost the same, but an authorization is a
connection between a role and an action (possibly) containing arguments.
see all the information attached to a role and decide if you want to
delete it.
id name description definition users authorizations / actions role
2 photoadmin Photo collection administrator None add / delete add / modify / remove modify / delete show details
1 superadmin superuser with all rights allow email /.*@cern.ch/ add / delete add / modify / remove modify / delete show details
3 webaccessadmin WebAccess administrator allow nickname 'jekyll' add / delete add / modify / remove modify / delete show details
Create new role
go here to add a new role.
Create new action
go here to add a new action.

II. Example - connecting role and user

  One of the important tasks that can be handled via the WebAccess Admin Web Interface
  is the delegation of access rights to users. This is done by connecting them to the
  different roles offered.

  The task is divided into 5 simple and comprehensive steps. Below follows the pages from
  the different steps with comments on the ongoing procedure.

- step 1 - select a role

  You must first select the role you want to connect users to. All the available roles are
  listed alfabetically in a select box. Just find the wanted role and select it. Then click on
  the button saying "select role".

  If you start from the Role Area, this step is already done, and you start directly on step 2.

Connect user to role

step 1 - select a role
1. select role
Create new role
go here to add a new role.

- step 2 - search for users

  As you can see, the subtitle of the page has now changed. The subtitle always tells you
  which step you are on and what your current task is.

  There can be possibly thousands of users using your online library, therefore it is important
  to make it easier to identify the user you are looking for. Give part of, or the entire search
  string and all users with partly matching e-mails will be listed on the next step.

  You can also see that the right hand menu has changed. This area is always updated with links
  to related admin areas.

Connect user to role

step 2 - search for users
1. select role
2. search pattern
Create new role
go here to add a new role.
Remove users
remove users from role superadmin.
Connected users
show all users connected to role superadmin.
Add authorization
start adding new authorizations to role superadmin.

- step 3 - select a user.

  The select box contains all users with partly matching e-mail addresses. Select the one
  you want to connect to the role and continue.

  Notice the navigation trail that tells you were on the Administrator pages you are currently

Connect user to role

step 3 - select a user
1. select role
2. search pattern
3. select user
Create new role
go here to add a new role.
Remove users
remove users from role superadmin.
Connected users
show all users connected to role superadmin.
Add authorization
start adding new authorizations to role superadmin.

- step 4 - confirm to add user

  All WebAccess Administrator web pages display the action you are about to peform, this
  means explaining what kind of addition, change or update will be done to your access control

  If you are happy with your decision, simply confirm it.

Connect user to role

step 4 - confirm to add user
1. select role
2. search pattern
3. select user
add user mikael.vik@cern.ch to role superadmin?
Create new role
go here to add a new role.
Remove users
remove users from role superadmin.
Connected users
show all users connected to role superadmin.
Add authorization
start adding new authorizations to role superadmin.

- step 5 - confirm user added.

  The user has now been added to this role. You can easily continue adding more users to this
  role be restarting from step 2 or 3. You can also go directly to another area and keep working
  on the same role.

Connect user to role

step 5 - confirm user added
1. select role
2. search pattern
3. select user
add user mikael.vik@cern.ch to role superadmin?

confirm: user mikael.vik@cern.ch added to role superadmin.

Create new role
go here to add a new role.
Remove users
remove users from role superadmin.
Connected users
show all users connected to role superadmin.
Add authorization
start adding new authorizations to role superadmin.

- we are done

  This example is very similar to all the other pages where you administrate WebAccess. The pages
  are an easy gateway to maintaing access control rights and share a lot of features.
  - divided into steps
  - restart from any wanted step (not undo)
  - changes must be confirmed
  - link to other relevant areas
  - prevent unwanted input

  As an administrator with access to these pages you are free to manage the rights any way you want.

IV. Managing accounts and access policy

  Here you can administrate the accounts and the access policy for your Invenio installation.

  - Access policy:

    To change the access policy, the general config file (or
    access_control_config.py) must be edited manually in a text
    editor. The site can there be defined as opened or closed, you can
    edit the access policy level for guest accounts, registered
    accounts and decide when to warn the owner of the account when
    something happens with it, either when it is created, deleted or
    approved.  The Apache server must be restarted after modifying
    these settings.

    The two levels for guest account, are:
       0 - Allow guest accounts
       1 - Do not allow guest accounts
    The five levels for normal accounts, are:
       0 - Allow user to create account, automatically activate new accounts
       1 - Allow user to create account, administrator must activate account
       2 - Only administrators can create account. User cannot edit the email address.
       3 - Users cannot register or update account information (email/password)
       4 - User cannot change default login method
    You can configure Invenio to send an email:
       1. To an admin email-address when an account is created
       2. To the owner of an account when it is created
       3. To the owner of an account when it is activated
       4. To the owner of an account when it is deleted

    Define how open the site is:
      0 = normal operation of the site
      1 = read-only site, all write operations temporarily closed
      2 = site fully closed
      3 = database connections disabled
    Access policy for guests:
      0 = Allow guests to search,
      1 = Guests cannot search (all users must login)
    Access policy for accounts:
      0 = Users can register, automatically acticate accounts
      1 = Users can register, but admin must activate the accounts
      2 = Users cannot register or change email address, only admin can register accounts.
      3 = Users cannot register or update email address or password, only admin can register accounts.
      4 = Same as 3, but user cannot change login method.

    Limit email addresses available to use when register a new account (example: cern.ch):

    Send an email when a new account is created by an user:

    Send an email to the user notifying when the account is created:

    Send an email to the user notifying when the account is activated:

    Send an email to the user notifying when the account is deleted/rejected:

  - Account overview:
    Here you find an overview of the number of guest accounts, registered accounts and accounts
    awaiting activation, with a link to the activation page.

  - Create account:
    For creating new accounts, the email address must be unique. If configured to do so, an email
    will be sent to the given address when an account is created.

  - Edit accounts:
    For activating or rejecting accounts in addition to modifying them. An activated account can be
    inactivated for a short period of time, but this will not warn the account owner. To find accounts
    enter a part of the email address of the account and then search. This may take some time. If there
    are more than the selected number of accounts per page, you can use the next/prev links to switch
    pages. The accounts to search in can also be limited to only activated or not activated accounts.

  - Edit account:
    When editing one account, you can change the email address, password, delete the account, or modify
    the baskets or alerts belonging to one account. Which login method should be the default for this
    account can also be selected. To modify baskets or alerts, you need to login as the user, and
    modify the desired data as a normal user. Remember to log out as the user when you are finished
    Here you can also edit the user's REST API keys changing its status to the desired one. This status
    is specified by CFG_REST_API_KEY_STATUS (only the first three are mandatory):
      0 = OK
      1 = REMOVED
      2 = REVOKED
      3 = WARNING1
      4 = WARNING2
      5 = WARNING3

V. Managing login methods

   Invenio supports using external login systems to authenticate users.

   When a user wants to login, the username and password given by the user is checked against the selected
   system, if the user is authenticated by the external system, a valid email-address is returned to
   Invenio and used to recognize the user within Invenio.

   If a new user is trying to login without having an account, using an external login system, an account
   is automatically created in Invenio to recognize and store the users settings. The password for the
   local account is randomly generated.

   If you want the user to be unable to change login method and account username / password, forcing use
   of certain external systems, set CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS to 4 as mentioned in the last paragraph.

   If a user is changing login method from an external one to the internal, he also need to either change the
   password before logging out, or set the password via the lost password email service.

   If you are using CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS with a value greater than 1 note
   that, even if the first login of a user through an external authentication technically means registering
   the user into the system, this is not the semantic expected behaviour by the user. The user is already
   registered at an authority that we trust, so there's no need to prevent the user from being imported
   into the system. That's why for external authentication CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS is not
   considered apart from what said above.

   If a external login system is used, you may want to protect the users username / password using HTTPS.

   To add new system, two changes must be made (for the time being):
   - The name of the method, if it is default or not, and an instance of the class must be added to the variable
     CFG_EXTERNAL_AUTHENTICATION in access_control_config.py.

   - A class must be created derived from the class external_authentication inside file
     external_authentication.py. This class must include at least the
     function auth_user. This function returns a valid email-address in Invenio if the user
     is authenticated, not necessarily the same entered by the user as username. If the user
     is not authenticated, return None.
     The class could also provide five more methods: fetch_user_preferences, user_exists,
     fetch_user_groups_membership and fetch_all_users_groups_membership.
     The first should take an email and eventually a password and should return a dictionary of keys
     and value representing external preferences, infos or settings. If, for some reasons, you like
     to force some kind of hiding for some particular field you should export the related key
     prefixed by "HIDDEN_". Those fields won't be displayed in tables and pages regarding external
     The second method should check through the external system if a particular email exists. If you
     provide such a method then a user will be able to switch from and to this authorization method.
     The third method should take an email and (if necessary) a password
     and should return a dictionary of external_groups_names toghether with their description, for which
     the user has a membership. Those groups will be merged into the groups system.
     The user will be a member of those groups and will be able to use them in any place
     where groups are useful, but won't be able to unsubscribe or to administrate them.
     The fourth method should just return a dictionary of external groups as keys and tuples containing
     a group description and a list of email of users belonging to each groups. Those memberships
     will be merged into the database in the way done by the previous method, but could
     provide batch synchronization of groups.
     The fifth method should just return the nickname as is known by the external authentication
     system, given the usual email/username and the password.
     Note: if your system has more than one external login methods then incoherence in the groups
     memberships could happen when a user switch his login method. This will be fixed some times in the
     If you add as an attribute of your class the enforce_external_nicknames and set it to True, this will enforce
     the system to import external nicknames whenever the user login with the external login method for the
     first time. Since a nickname is not changable this will stay fixed forever. If this nickname is
     already registered in the system (suppose that is linked with a local account) then it will not be
     imported. If this variable doesn't exist or is set to False then no nickname will be
     imported and the user will be free to choose a nickname in the future (and then this will again
     stay forever).
     Note: every method will receive as last parameter the mod_python request object, that could
     be used for particular purposes.

     Example template:
     from invenio.webaccess.external_authentication import ExternalAuth, InvenioWebAccessExternalAuthError

     class ExternalAuthFoo(ExternalAuth):
         """External authentication template example."""

         def __init__ (self):
             """Initialize stuff here."""
             self.name = None
             self.enforce_external_nicknames = False

         def auth_user(self, username, password, req=None):
             """Authenticate user-supplied USERNAME and PASSWORD.
             Return None if authentication failed, or the email address of the
             person if the authentication was successful.  In order to do
             this you may perhaps have to keep a translation table between
             usernames and email addresses.
             Raise InvenioWebAccessExternalAuthError in case of external troubles.
             raise NotImplementedError

         def user_exists(self, email, req=None):
             """Checks against external_authentication for existance of email.
             @return True if the user exists, False otherwise
             raise NotImplementedError

         def fetch_user_groups_membership(self, username, password=None, req=None):
             """Given a username, returns a dictionary of groups
             and their description to which the user is subscribed.
             Raise InvenioWebAccessExternalAuthError in case of troubles.
             raise NotImplementedError

         def fetch_user_preferences(self, username, password=None, req=None):
             """Given a username and a password, returns a dictionary of keys and
             values, corresponding to external infos and settings.

             userprefs = {"telephone": "2392489",
             "address": "10th Downing Street"}
             raise NotImplementedError

         def fetch_all_users_groups_membership(self, req=None):
             """Fetch all the groups with a description, and users who belong to
             each groups.
             @return {'mygroup': ('description', ['email1', 'email2', ...]), ...}
             raise NotImplementedError

         def fetch_user_nickname(self, username, password, req=None):
             """Given a username and a password, returns the right nickname belonging
             to that user (username could be an email).
             raise NotImplementedError


The FireRole language description
    In the WebAccess RBAC system, roles are built up from their names,
    description and definition.

    A definition is the way to formally implicitly define which users belong
    to which roles.

    A definition is expressed in a firewall like rules language. It's built up
    by rows which are matched from top to bottom, in order to decide if the
    current user (wethever he/she is logged in or not) may belong to a role.

    Any row has this syntax:




        ALLOW/DENY [NOT] field {one or more values}

    The rows are parsed from top to bottom. If a row matches the user than the
    user belongs to the role if the rule is an ALLOW rule, otherwise, if the
    rule is a DENY one, the user doesn't belong to the role.

    A rule of the kind ALLOW|DENY ANY always matches, regardless of the user.

    Note, in place of ANY you can use the word ALL. The semantic is the same. The
    system support both to let the user comply with the English grammar.

    The second type of rule is interpreted as follows: given a date in the
    form "YYYY-MM-DD" (double-)quoted), the rule is matched if, when using FROM,
    the current date is either identical or 'bigger' than the given date, or if,
    when using UNTIL, the current date is either identical or 'smaller' than the
    given date. If the rule starts with ALLOW and is matched
    then the next row is evaluated. If it is not matched, then the whole FireRole
    will evaluate into a DENY ALL. If the rule starts with DENY and
    is matched then the whole FireRole while evaluate as a DENY ALL. If it is
    not matched then the next row is evaluated.

    The third type of rule is interpreted as follows: given a dictionary
    of keys:values describing a user (we will cover this below), the rule
    considers the value associated with the key named in field, and checks
    if it corresponds to at least one of the values in the "one or more values" list.
    This is a list of comma separated strings, which can be literal
    (double-)quoted strings or regexps (marked by `/' ... `/' signs). If at
    least a value matches (literally or through the regexp language), the
    whole rule is considered to match.
    If the optional NOT keyword is specified than if at least a value of the
    rule matches the rule is skipped, otherwise if all the value of the rules
    don't match the whole rule matches.

    A DENY ALL rule is implicitly added at the end of every definition. Note that
    this imply that, if you are using e.g. a temporal rule (FROM/UNTIL), you
    should explicitly add an additional row with value ALLOW ANY,
    if you actually want to allow users in the specified timeframe.

    Any field is valid, but only rules concerning fields which currently
    exist in the user describing dictionary are checked. All the rules
    with non existant fields are skipped.

    The user describing dictionary (user_info) is built at runtime with all the informations
    that can be gathered about the current user (and its session).
    Currently valid fields are: uid, email, nickname, remote_ip,
    remote_host, groups and all the external settings provided
    by the external authentication systems (e.g. CERN SSO provides:
    external_authmethod, external_building, external_department, external_email,
    external_external, external_firstname, external_fullname, external_homdir,
    external_homeinstitute, external_lastname, external_login, external_mobilenumber,

    Among those fields there are some special cases, which are remote_ip and
    (apache_)groups. Rules can refer to remote_ip either using a literal
    expression for specifing list of single ips, or a usual regexp (or list
    of regexps), or, also, using the common network group/mask notation
    (e.g. "") as a literal string, which is a mix between literal
    expressions and regexps. (apache_)groups are related to group memberships.
    Since a user will probably belong to more than a group, then the rule
    matches if there's at least one group to which the user belong, that matches
    at least one of the expressions (NOT rules behave as you can imagine).

    The dictionary is built using the current user session. If the user is
    authenticated in some way (apache, locally, externally, SSO...) then more
    infos could be provided to the firerole system in order to decide if the
    user should belong to a role or not.

    The default fields that are always there are:
  • uid: an integer representing the user id
  • nickname: the nickname of the user
  • email: the email of the user
  • group/groups: local or external group to which the user belong
  • guest: 1 if the user is a guest (not logged), 0 otherwise
plus all the external setting retrieved by an external authentication system. If the action to which the role defined is raised from the webinterface of Invenio, then you will have those additional fields:
  • remote_ip: the remote ip address of the user who is browsing
  • remote_host: the remote hostname of the user who is browsing
  • referer: the webpage from where the user is coming from
  • uri: the uri the user is visiting
  • agent: the agent string describing the user's browser
Note that you can specify either (apache_)group or (apache_)groups (with or without the trailing s). They are semantically equal and are supported just to let people comply with the English grammar. Every rule is case-insensitive (apart values which must match literally and regexp values which don't explicitly specify case-insesitive matches). Every rule may contain comments preceded by the '#' character. Any comment is discarded. When you set a definition for a role, it is actually compiled and stored in a binary compressed form inside the database. If the syntax isn't correct this will be stated and the definition won't be set or updated. Example of role definition: allow not email /.*@gmail.com/,/.*@hotmail.com/ deny group "badguys" allow remote_ip "" deny all This definition would match all users whose emails don't end with @gmail.com and @hotmail.com, or who don't belong to the group badguys and have remote_ip in the 24bit mask network of All the the other users don't belong to the role which is being defined. If you want to discover which keys are available on your system to build a FireRole rule, just login with your account in your installation and visit your account page, by activating verbose=9 variable. Under the tile you will se the available keys and values that you can use to build a FireRole rule. All but fields prefixed with precached_ are usuable.