Modular Decomposition of ANGEL Components

Rather than proliferating configuration files, it is suggested that these be command line parameters to the SB program. Further configuration, if needed, should be provided via the central configuration file, which would then have sections for each protocol being used.

The internal structure of these components will to a large extent depend on the protocol involved. It is possible, though, to tabulate the inputs and outputs of each module.

This takes the XRR response message and turns it into a protocol response. The protocol name from the SB configuration will be used to obtain the appropriate XSLT stylesheet, and this will be used to transform the response message into the appropriate protocol message. The work required for this has already been done by other projects, and it should be simple to reuse the software that has been developed elsewhere to do this.

The client broker (CB) will operate in essentially the same way as the server broker, except that the flow of data is reversed. A new CB will be started for each transaction. (I am not sure that the CB needs to be a separate part of the system; it may be conceptually distinct from the ANGEL components, but would probably work best computationally as a library called by the component.)

However, it would probably be useful for the light blue components to be the same pieces of software as their equivalents in the SB. The only difference will be that they are processing messages received as a client rather than as a server, and it should be possible for this to be made a configuration issue rather than a programming one.

The CB configuration file will contain the following pieces of information:

• Port number to use if running as a socket service
• Directory containing XSLT style sheets

3.1 Background

3.2 User Manager Model

The User Manager will act to authenticate users against existing local infrastrusture and obtain locally produced directory information about the user. It will support a variety of local protocols, which will include LDAP, SQL, X.509 certificate validation, SMB, ATHENS, IPX, HTTP htaccess and UNIX passwd files as well as a null service which returns no directory information and a simple IP based validation.

The UM configuration file will list a series of authentication targets, each of which is associated with a directory information service. Authentication credentials will be tried against each target in turn, until one matches, at which point the appropriate directory information service will be queried.

The architecture is based on the one used for the Decomate2 authentication broker, but it would also be possible to spawn a child for each authentication service listed in the configuration file rather than running through them in turn, responding to the client as soon as a positive result is obtained. There will certainly be authentication architectures where this is faster in most cases, but that may or may not be true for the majority of institutional infrastructures. It should be a relatively simple matter to set up the UM so that this is a configuration issues, which can then be altered for the best performance in local circumstances.

The UM in this example is installed at De Montfort University (DMU), to service the DMU Angel system for DMU users. The UM recognises two types of external service: Authentication Services (such as LDAP, SQL) which check the credentials of a user, and Directory Services (such as LDAP, or any SQL-compliant relational database system) which return information about a user.

LDAP may also be used (as is the case at DMU) for authentication – using the e-mail system to determine whether or not a user belongs to the institution. Each authentication service has a corresponding directory service, which contains further information about the users that the authentication service trusts. In the example above, the appropriate directory service is the DMU Student Record System (QLS) which returns information about courses and modules a user is enrolled on.

The UM 'knows' about the authentication and directory services it can use from a configuration file which specifies where and how to communicate with them. Multiple authentication regimes may be available, so they are checked in sequence (in the order specified by the configuration file) until one returns a positive match. The configuration for the example UM tells it to look first in an SQL database (containing records for some non-DMU users), and then in the DMU LDAP directory service. It fails to find the student in the SQL database, but finds her name and a matching e-mail and password for her login in the LDAP system.

When this happens, the directory service that corresponds to this authentication service is queried for the information it has about the user, using the appropriate protocol (specified in the configuration file). The results that come from this directory service are parsed, based on the configuration file entries for the directory service, to complete the list of fields that Angel uses. The configuration can specify for each service how the 'native' data fields it returns should be mapped into standard elements and, if necessary, regular expressions to be applied to non-standard field contents to transform them to the appropriate format.

This collection of fields is then parsed using the configuration parameters of the authentication service, to make a list of groups to which the user is to be assigned, thus determining the rights a user has from their directory information held by the institution.

The collection of fields and the list of groups are returned to the socket in an XRR logonResponse message, indicating either a successful or a failed login, which was not matched by any available service. Currently, the backend service types that the UM will connect to are SQL databases, LDAP servers, QLS (Microcompass) Student Record Systems. New backend service handlers can be created when needed, provided that enough information is available about an API to the service.

Since an institution might want to use different services for different users (for example, different LDAP servers for staff and students, SQL databases containing privileged users or external library users), the UM will go through the list of services in its configuration file until one accepts the user. Thus multiple sources can be supported (at an expense of overall response speed). An identified user is given a collection of rights-groups, derived from the authentication method through which they successfully accessed the system and on the directory information retrieved. These groups can then be used to determine the access rights granted to the user.

The UM is run as a Unix 'socket' service, currently exchanging request and response messages with applications in plain text. This is not as insecure as it might sound, because this transmission will normally occur between two processes on the same physical server, or at least within an institutional network (and so can be firewall protected). Transmission of passwords between the end-user and the application (i.e. potentially over open Internet connections) can be easily secured by the application of SSL to the web server running the application.

4.1 Background

The Resource Manager has several functions centred around the external resources which are to be accessible via the Angel system. These are:

• mediation of connection to resources permitting the maintainance of persistent URLs and deep linking as well as arranging authorisation credentials
• mediated searching of resources using a variety of protocols
• access to administer the metadata and obtain usage statistics

4.2 Resource Manager Model

The Angel RM is based around a central metadata relational database, containing the information required to mediate the different kinds of access to external systems. This access is through the server and client brokers; the metadata determines which brokers to use and the parameters for connection, in the case of searching; for authorisation, the metadata specifies the mechanism for generating credentials to allow an end user to access the resource. The RM is intended to be run for the benefit of users at a single institution, though some form of metadata sharing is likely to be built in at a later date.

The RM is run as a Unix 'socket' service, currently exchanging request and response messages with applications in plain text. This is not as insecure as it might sound, because this transmission will normally occur between two processes on the same physical server, or at least within an institutional network (and so can be firewall protected). Transmission of passwords between the user (which is typically another service and not an end user) and the application (i.e. potentially over open Internet connections) can be easily secured by the application of SSL.

The RM configuration file will be in XML format and will contain the following pieces of information:

• RM log file location
• Resource database location and database type/version
• Certificate location

4.3 Authorisation Data Flow

4.4 Database Management Data Flow

4.5 Resource Searching Data Flow

4.6 Request Parser

This will run at a configurable interval (likely to be no more frequently than once per hour). It will connect to the database, get a list of tasks to be performed, connect to the server broker to carry out the tasks, update the database and email the user involved. (It would be possible for clients to set other email addresses than end user ones, and to intercept the emails so that data can be updated without involving the end user.) The email generator will consist of another instance of the XSLT transformer.