WebAccess Admin Guide
Contents
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
index='author'.
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
database.
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
entering.
Role Administration
- Users:
- add or remove users from the access to a role and its priviliges.
- Authorizations/Actions:
- these terms means almost the same, but an authorization is a
connection between a role and an action (possibly) containing arguments.
- Roles:
- see all the information attached to a role and decide if you want to
delete it.
|
- 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.
- 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.
- 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
working.
- 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
data.
If you are happy with your decision, simply confirm it.
- 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.
- 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.
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
CFG_ACCESS_CONTROL_LEVEL_SITE = 0
Access policy for guests:
0 = Allow guests to search,
1 = Guests cannot search (all users must login)
CFG_ACCESS_CONTROL_LEVEL_GUESTS = 0
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.
CFG_ACCESS_CONTROL_LEVEL_ACCOUNTS = 0
Limit email addresses available to use when register a new account (example: cern.ch):
CFG_ACCESS_CONTROL_LIMIT_REGISTRATION_TO_DOMAIN = ""
Send an email when a new account is created by an user:
CFG_ACCESS_CONTROL_NOTIFY_ADMIN_ABOUT_NEW_ACCOUNTS = 0
Send an email to the user notifying when the account is created:
CFG_ACCESS_CONTROL_NOTIFY_USER_ABOUT_NEW_ACCOUNT = 0
Send an email to the user notifying when the account is activated:
CFG_ACCESS_CONTROL_NOTIFY_USER_ABOUT_ACTIVATION = 0
Send an email to the user notifying when the account is deleted/rejected:
CFG_ACCESS_CONTROL_NOTIFY_USER_ABOUT_DELETION = 0
- 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
editing.
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
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
settings.
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
future.
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.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
pass
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 ANY/ALL
ALLOW/DENY FROM/UNTIL "YYYY-MM-DD"
or
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,
external_phonenumber).
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. "127.0.0.0/24") 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 "127.0.0.0/24"
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 127.0.0.0. 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.
host ::