The Metadata Registry is comprised of both public and secure functionality. Access to the secure sections of the registry are controlled via roles and a set of alternative authentication processes. Users wishing to authenticate either need have a valid Australian Access Federation(AAF)account, or have a built in account configured directly in the registry. The Access Management System is an interface that enable RDA Registry users as well as users who are authenticated via the Discovery Portal to authenticate and gain access to additional functionality. The Access Management System supports Built In, LDAP, Australian Access Federation (AAF) authentication via Rapid Connect and Shibboleth and various Social Networks, such as Facebook and Twitter. Authenticated users can be granted additional functionality and affiliations with Organisation by an administrator role, via a User Management Interface. This authentication framework is also accessible from the Portal, allowing users to login to MyRDA.
Roles are used within the RDA Registry to grant and organise access permissions. A role administration manager titled ‘Roles’ has been integrated into the registry to allow registry administrators to manage roles and user access.
There are 3 types of roles used by the registry:
- User Role - A user role represents an individual user. User roles are assigned an ‘Authentication Type’ and are the only roles that can login/authenticate against the registry. A user role is necessary for any user who requires access to the secure functionality within the registry. Once a user role has been set up for a user, they can be assigned as members of functional and organisational roles.
- Organisational Role - An organisational role represents an organisational entity or group of people (company, division, department, school, faculty, etc). Organisational roles simplify access management by allowing registry administrators to group user roles (and sometimes other organisational roles). Administrators can then grant functional access to the organisational role instead of each individual user role.
- Functional Role - A functional role represents a collection of functionality permissions and is typically based on a registry user type (e.g. Registry Administrator, Registry user, etc.). Each secure piece of registry functionality essentially has its own Access Control List (ACL) that contains a listing of the functional roles which can access the secure functionality. When user and organisational roles are configured as members of functional roles, they inherit access to all the functionality permissions granted to the roles. Users will therefore only be able see and access functionality they have access to via their functional role membership(s). In many cases users will act as more than one type of registry user, and will be mapped to multiple functional roles. Functional roles can also be members of other functional roles. This enables a hierarchy of authorisation to be defined. Each of the registry functional roles and their associated permissions can be found in the RDA Registry Functionality Role Matrix.
ARDC Software comes with several authenticators located at
engine/models/authenticators and can be extended to allow more methods of authentication.
- Built In authenticator: authenticate users with built in account, created via the Roles Management with the default role and default password of
abc123, the user can change their default password upon logging in
- LDAP authenticator: authenticate users with an LDAP account tied to an LDAP domain. This domain is configured in the
engine/config/constants.phpfile, defaulted to
- Australian Access Federation: authenticate users with an AAF account, either via Rapid Connect or via installed Shibboleth instance on the server
- Social Networks: authenticate the users with social networks that supports the OAuth 2.0 authentication framework. Supports Facebook, Google, LinkedIn and Twitter and is configured via the
$ENV['oauth_config']configuration option in