User Management

The standalone AMGA server comes with a powerful system to manage users as well as to control access to entries and metadata. If AMGA is run as an add on to a file catalogue, however, these features are not available and the access controls of the file catalogue is used instead.

To understand the user management of the AMGA server it is necessary to know that the server does not really manage users but only their authentication and authorization. When changing the owner of an entry for example, the server does not check that this owner exists. Users are only relevant for logging in. This allows to manage users outside of the server, e.g. in a VOMS.

IMPORTANT NOTE: When you use sessions or connections, then changes to the way a user is authenticated or how the authorization is done through the mapping to an AMGA user, will not affect active sessions or connections. You must restart the server to propagate changes to the user managment to active sessions or connections.

Configuration

To use the metadata service, a user must be authenticated and authorized. Authentication can be done via a certificate or a password, see Configuring the AMGA Server and the Replicatin Daemon . After the authenticity of a user is established in the handshaking of the client with the server, the client needs to be authorized to use the role of a certain user. Authorization is optional, if authorization is not enabled for the server, any authenticated user can assume any role he wishes. Authorization is controlled via the mdserver.config configuration file:

  # Authorization options, choose 0 or more
  # MapFile = /etc/grid-map-file       # Authorization based on certs
  # Authorization based on certifictes, put a list of VOMS URL and assigned users, here:
  VOMSGroups = https://lcg-voms.cern.ch:8443/voms/lhcb/services/VOMSAdmin?method^=listMembers, lhcb, \
               https://kuiken.nikhef.nl:8443/voms/picard/services/VOMSAdmin?method^=listMembers, picard
  UserDB = 1 # Authorization based on certs & passwords

Authorization can be done via certificates or passwords (password authentication actually includes authorization), both must be explicitely enabled. For authentication via certificates to work, both the server and the client must have SSL enabled (UseSSL). Four ways are foreseen to accessing the necessary information to match user names with their credentials, one or more must be enabled for the RequireUserAuthorization to work:

• A grid-map file mapping certificate subjects, that is distinguished names (DN of users) to users. This is a static setup and no new users can be added at runtime. No password authorization is possible via a grid map file. Option MapFile.
• A user database using the database backend. This allows creation of users and the management of their credential at runtime. This is the only option which allows password based login. Option UseDB.
• Authorization using a VOMS. All users registered with a VO will be assigned to the user specified here. You can give several VOMS-URL user pairs here. Option VOMSGroups.
• Authorization via VOMS certificates. All users connecting with a VO information-enriched certificate obtained via voms-proxy-init will be assigned to specific AMGA users depending on the role within the VO. Option VirtualOrganizations. Note that only the DB based user management module is able to make changes to the user setup. If you have several user management modules activated at the same time, then listing users and checking their credentials for authorization will go through the users in all of the modules. A user is authorized as soon as he has been found in any of the modules.

Management via a Grid Map file

You can give a location of a grid map file using the MapFile option for user authorization. This file contains pairs of distinguished names and user names. The DN must be enclosed in double quotes and must be in the form where its fields are seperated by commas on one line (output of openssl x509 -subject -in usercert.pem -nameopt oneline -noout):

    $ cat mapfile
  "/C=CH/O=CERN/OU=GRID/CN=Birger Koblitz 9904" koblitz

There are no wild cards currently allowed. The map file will be read only once at server startup. It is not possible to add or change users using the command line tool.

Management of Users using the database backend

To enable user management using your database backend, you need to enable this feature by setting UserDB = 1. If you have run the createInitial.sql script, to set up you database, the necessary tables have already been created. You can now manage users via the mdclient command line tool:

• user_list: Lists all users known to the authentication subsystem.
• user_listcred user: Lists the credentials with which the user can be authenticated. Returns first the user name, then whether there is a password and then the certificates which are mapped in a Grid-Mapfile and via the user database. Finally the different VO and VO roles which allow you to become that user are listed. Only root is allowed to see the credentials of other users.
• user_create user [password]: Creates a new user and assigns a password if give. This command is for the root user only. Only hashes of passwords are stored in the database backend. Charaters that should be avoided in the user name are ', ", \, :, |, and <space>
• user_remove user: Deletes a user. This command is for root only. It does not check whether there are still files or directories owned by that user.
• user_password_change user password: Changes the password of a user. Only root can change the password of any user. Non-priviliged users may only change their own passwords.
• user_subject_add user subject:Adds a certificate identified by its subject line to be used to authenticate a user. While every user can only have one password. Several certificates can point to the same user. Remember that in order to have spaces in the subject, you need to enclose it by single quotes (''). See Definition of the Client Server Protocol. The form of the subject needs to be the one where parts are separated by commas as in the output of e.g. openssl x509 -subject -in usercert.pem -nameopt oneline -noout.
• user_subject_remove user subject:Removes a certificate from the list of certificates which allow to login as a certain user.

Management via a VOMS

Giving pairs of VOMS member list URLs and user names in the VOMSGroups option, you can assign all members of a VO to a user (role would be the better word here).

Management via VO-Certificates

You can allow users to log in with VO-enabled certificates by using the VirtualOrganizations option and assigning it a list of VO(default_user) definitions. By enabling MyProxyHack this works also with certificates issued by a MyProxy server. The VOGroupMap and VOUserMap options allow to map VO groups to AMGA groups and special VO roles to AMGA users with the syntax used by VirtualOrganizations. You can also manage mapping between a user/group & a VOMS Role/group in the command line tools.

• user_voms_add - Allows user to log in with a certificate with the given VOMS Role
• user_voms_list - Lists all possible VOMS Role
• user_voms_remove - Removes VOMS Role allowed for user
• grp_voms_add - Creates mapping between a group and a VOMS group
• grp_voms_list - Lists all possible VOMS group mapping
• grp_voms_remove - Removes group mapping allowed for VOMS Group

---