WO2007090866A1

WO2007090866A1 - Collaborative access control in a computer network

Info

Publication number: WO2007090866A1
Application number: PCT/EP2007/051214
Authority: WO
Inventors: Peter De Waard; Adrian Waller
Original assignee: Thales Holdings Uk Plc
Priority date: 2006-02-09
Filing date: 2007-02-08
Publication date: 2007-08-16
Also published as: GB2435115A; GB0602642D0; GB2435115B

Abstract

Access control architecture is provided which manages control of facilities (data, applications) accessible across local networks. An authorisation function hosted on the network hosting the requesting computer firstly checks, in response to a request for access to a facility on another network, if the requesting computer has access rights to the network hosting the facility. The architecture then maps user role information used in the first network to corresponding role information in the facility hosting network. This is then used by a corresponding authorisation function in the facility hosting network to determine grant of access to all or part of the facility concerned.

Description

COLLABORATIVE ACCESS CONTROL IN A COMPUTER NETWORK

The invention relates to the provision of a secure networking environment. Particularly, but not exclusively, the invention relates to the provision of a secure networking environment to allow collaborative working using secure data.

The invention is particularly concerned with the establishment of virtual collaborations. A virtual collaboration is an ad hoc integration of resources, capabilities, people and information across organisational boundaries to support collaborations. Examples include virtual projects, crisis management and grid computing. Situations which may give rise to high-level security requirements for authentication and authorisation in virtual collaborations include the following:

• Resources within a virtual collaboration (including data, applications etc.) may be owned by many different organisations, each with their own access control policies for such resources;

• Each virtual collaboration may have its own access control policies that it wishes to apply on resources: in most cases, these need to be used to refine the access control policies of the organisations that own the resources, as they make the final determination of usage of such resources;

• Trust between the organisations involved in a virtual collaboration, and more specifically their users and resources, may be limited;

• There may be no central administrative point or common security architecture between the organisations: a distributed security mechanism will in this case be required in order to handle the access control; • Different organisations may use different security mechanisms for their access control: there will thus be a need to accommodate heterogeneity, rather than trying to enforce one technical solution;

• Virtual collaborations may be transient, and the membership of virtual collaborations as well as their access control policies may change at short notice. Therefore, any solution needs to be highly flexible and efficient.

Traditional, manual based, administration of access to resources clearly cannot meet these requirements. Therefore, there is a need to automate the administration of access to resources in a virtual shared environment.

Several prior arrangements have been published in the field of providing user access control to virtual collaborations. However, previous examples have not been designed for high security environments.

For example, "The Kerberos Network Authentication Service (V5)" (RFC 1510, IETF Network Working Group, September 1993) describes mere authentication and is not designed to operate across multiple local networks. It is further not capable of supporting multiple parallel virtual collaborations.

A "Secure European System for Applications in a Multi-vendor Environment" (SESAME) accessible at https://www. cosic.esat.kuleuven.ac.be provides a joint working environment but does not check the policy of the requestor's network..

Web Services Federated Identity Management

(http://msdn.microsoft.com/webservices/webservices/) provides Web Services Standards which are designed to provide the infrastructure for federated identity management. However, the Standards do not focus on defining how they are used. The Standards provide a suite of tools that Web Services can use, and define how requestors and services on heterogeneous networks communicate. "Dynamic Security Perimeters for Virtual Collaborative Networks" (DSPVCN)

(described in "Design and Implementation of Virtual Private Services,", Sotiris Ioannidis, Steven M. Bellovin, John loannidis, Angelos D. Keromytis, Jonathan M. Smith: wetice, p. 269, Twelfth International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises, 2003) enforces security with an agent on every user's computer. The architecture in this document enforces security with a combination of brokers, servers and agent wrappers for applications.

The agent on each computer in DSPVCN must interpret each action and compare it to all policies to see if it relates to any. In addition, the agent is unaware of the context of the action.

Further, DSPVCN does not separate policy from the users, and provides only basic implementations of delegation, revocation, variable granularity and the ability to work with multiple virtual collaborations. In addition, the DSPVCN security implementation is less than comprehensive as it is designed for a relatively benign threat environment.

The present invention is intended to meet one or more of the requirements set out above. In particular, an embodiment of the invention provides a high-level user access control architecture that is designed to protect electronic data, while promoting secure collaboration. An embodiment of the invention provides high security user access control that is compatible with heterogeneous networks, with existing operating systems and legacy applications, and with situations where there is limited trust between different local networks.

A first aspect of the invention provides access control architecture which manages control of facilities (data, applications) accessible across local networks. An authorisation function hosted on the network hosting the requesting computer firstly checks, in response to a request for access to a facility on another network, if the requesting computer has access rights to the facility hosting network. It then maps user role information used in the first network to corresponding role information in the facility hosting network. This is then used by a corresponding authorisation function in the facility hosting network to determine grant of access to all or part of the facility concerned.

A second aspect of the invention provides a method of managing, for a computer on a first local network, access to a facility hosted on a second local network in communication with said first local network, comprising the steps of: on receipt of a request from said computer for access to said second local network, determining at said first local network if said computer, configured by means of user account information, is authorised to gain access to said second local network and, if so authorised: determining at said second local network if said computer, configured by means of user account information, is authorised to gain access to said second local network and, if so authorised: determining, with regard to said user account information, second network user role information, said second network user role information being capable of being used in said second local network to govern the determination of authorisation of a computer, configured by means of said user account information, for access of a facility hosted on said second local network; and on receipt of a request from said computer for access to said facility, determining at said first local network if said computer, configured by means of user account information, is authorised to access said facility hosted on said second network, and, if so authorised: determining if said computer, configured by means of said user account information, is authorised to access said facility hosted on said second local network, with respect to said second network user role information.

The method thus provides assurance that the network access policies of the requestor's home network and that of the facility's home network are both followed. This can be used to prioritise requests for applications.

Since the home network makes the first determination as to the appropriate way to handle an application request, the home network is able to assert control over task distribution through defining where requested tasks are to be run. The process can be kept separate from requesting computers. In this way, policy information can be separated from users and applications.

Actions can be traced to individual users, and tokens to their issuers. This assists in the management of authorisation, and action request history.

The second network in the statement of invention set out above is, in one embodiment, thus able to enforce its own policy on access. Since authorisation is self contained, it can be delegated.

The invention provides the means to enable the establishment of multiple, parallel, virtual collaborations, possibly using different operating systems and different token formats. It allows for different role definitions on different networks, and support for legacy applications.

The step of determining at said first network if said computer, configured by means of user account information, is authorised to gain access to said second computer network may, if so authorised, be followed by a step of sending, to said requesting computer, a first local network authorisation token indicating permission by said first network for said computer, so configured, to access said second network.

The request may be signed by the requesting computer, and comprising the step of countersigning the token for receipt by the requesting computer.

The step of determining at said first network if said computer, configured by means of user account information, is authorised to gain access to said second computer network may comprise one or more of the following: considering the availability of a substantially equivalent facility in the first network to that requested; considering security implications related to the request for use of a facility on another network; considering a trust level assigned to the user corresponding to the user account information; and considering a trust level assigned to the second network by the first network.

In that way, the home network of the requesting computer may firstly determine if the request conflicts with network management policy, such as regarding use of the resources of other networks (which may be costly) or regarding data integrity.

The step of determining at said second network if said computer, configured by means of user account information, is authorised to gain access to said second computer network may, if so authorised, be followed by a step of sending, to said requesting computer, a second local network authorisation token indicating permission by said first network for said computer, so configured, to access said second network.

Again, the token may be countersigned before sending.

The method may further include the step of storing a list of local networks from which requests for access by a computer are to be granted, such that said step of determining at said second network if said computer is authorised to gain access to said second computer network comprises referring to said list in order to determine if said requesting computer is on a network listed in said stored list. The list of local networks may include storing information relating to individual computers, or groups of computers, on said local networks, and corresponding access right information. The list may include storing information defining groups of networks, each network within a group having the same authorisation profile with respect to said second network.

The step of determining if said computer, configured by means of said user account information, is authorised to access said facility hosted on said second network, may be followed by the step of sending a facility access token to said requesting computer for use by said computer in using said facility. Once again, the token may be countersigned. The method may further comprise the step of storing facility access policy information defining an access policy for rights of access by computers on other local networks to said facility such that said step of determining if said computer is authorised to access said facility hosted on said second network includes referring to said facility access policy information.

The facility access policy information may define access policy information for an individual computer on another network, with respect to an individual facility. The facility access policy information may define access policy information for a class of computers on another network, with respect to facilities. The facility access policy information may define access policy information with respect to classes of facilities.

In this way, access policy information can be defined on an object or data level, or at application level. The invention, in certain embodiments thereof, provides this flexibility. Individual actions can be controlled, or more general authorisations can be issued.

The step of determining if said computer, configured by means of user account information, is authorised to gain access to said second computer network may be preceded by a step of storing first network role information corresponding to said user, said first network role information being available for determination of access to facilities hosted on said first network. The step of determining said second network user role information may comprise mapping said first network role information for the user to corresponding information defining possible roles in said second network.

The facility may comprise data stored in a data storage location in said second network. The facility may comprise an application executable on said second network.

A further embodiment of the second aspect of the invention provides a method of executing an application hosted on a second network in response to a request by a computer on a first network, comprising managing access to said application in accordance with the preceding method and. on receipt of successful determination that said computer has authorisation to access said facility, further comprising the step of said requesting computer sending an application request to said second network, for execution of said application.

This embodiment of the invention may further comprise the step of checking, in said second network, that said authorisation remains valid and, if not, sending information indicating revocation of said authorisation.

On receipt of information indicating a revocation of said authorisation, the method may comprise sending a failure message to said requesting computer.

Revocation can be managed on an application by application basis, on an action basis, or on a universal basis. Revocation can be governed by detection of malicious activity, such as attempts to access unauthorised areas of a remote network.

A third aspect of the invention comprises access control apparatus for granting, to a computer on a first local network, access to a facility hosted on a second local network in communication with said first local network, comprising: first computer network access authorisation means in said first local network operable to receive a request from said computer for access to said second local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said second local network; second computer network access authorisation means in said second local network operable to receive a request from said computer for access to said second local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said second local network; second network role determining means for determining, on the basis of said user account information, second network user role information, said second network user role information being capable of being used in said second network to govern the determination of authorisation of a computer, configured by means of said user account information, for access of a facility hosted on said second network, said second network role determining means being operable on the basis of determination, at said second computer network access authorisation means, that said requesting computer is authorised to access said second network; first computer network access authorisation means in said first local network operable to receive a request from said computer for access to said facility hosted on said second local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said facility hosted on second local network; and facility access determining means for determining if said requesting computer, configured by means of said user account information, is authorised to access said facility hosted on said second network, with respect to said second network user role information.

A fourth aspect of the invention provides access control apparatus for use in a home local network and operable to cooperate in use with corresponding apparatus in one or more other local networks, the apparatus being for use in granting access to one or more facilities hosted on said home local network or said one or more other local networks in communication with said home local network, comprising: home network access authorisation means operable to receive a request from a computer in said home network for access to another local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said other local network; other network access authorisation means operable to receive a request from a computer in another local network for access to a facility hosted on said home network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said home local network; network role determining means for determining home network user role information, on the basis of user account information for a requesting computer on another network, said home network user role information being capable of being used in said home network to govern the determination of authorisation of said requesting computer for access to said facility hosted on said home network, said network role determining means being operable on the basis of determination that said requesting computer is authorised to access said home network; wherein said other network access authorisation means is further operable to receive a request from a computer in said other network for access to a facility in said home local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said facility in said home local network; and facility access determining means for determining if said requesting computer on said other network is authorised to access said facility hosted on said other network, on the basis of said home network user role information.

Embodiments of the present invention therefore provide advantages when compared with Kerberos including the provision of fast and efficient revocation, and the capability to work across multiple local networks (unlike Kerberos). In addition, embodiments of the present invention are designed to support multiple parallel virtual collaborations, whereas Kerberos is not designed to support them at all. Finally, comprehensive accounting and auditing can be built into embodiments of the present invention, whereas Kerberos lacks the same.

The present invention provides embodiments which are more secure than SESAME, in the sense that they are designed to work with different local networks with limited trust, whereas SESAME does not check the policy of the requestor's network. Embodiments of the present invention provide architecture which has explicit built in rapid revocation.

Whereas DSPVCN enforces security with an agent on every user's computer, embodiments of the present invention provide a simpler approach as each action is directly checked at a time when the requestor is explicit about their intended action. In contrast, the agent on each computer in DSPVCN must interpret each action and compare it to all policies to see if it relates to any. In addition, the DSPVCN agent is unaware of the context of the action. Embodiments of the present invention provide architecture which is potentially more secure as brokers and policy information can be kept on specially secured machines, rather than having to be placed in all machines.

There are a number of other areas where the implementation of DSPVCN may be less sophisticated. These include DSPVCN not separating policy from the users, and the provision of only basic implementations of delegation, revocation, variable granularity and the ability to work with multiple virtual collaborations. In addition, the DSPVCN implementation of security is less comprehensive as it is designed for a more benign threat environment.

Figure 1 illustrates a computer networking system enabling an application scenario involving collaboration work between multiple users that may be remote from each other, for short-term collaboration, such as a virtual meeting, as well as for longer term collaboration, such as a joint project.

It will be appreciated that a wide variety of devices can be used to participate in such a collaborative working environment, varying from large specialised fixed equipment to small mobile portable devices. Such a collaborative working scenario can involve the handling of highly sensitive data, such as commercial, personal or even government data. For this reason, providing security to this kind of data is a key issue.

Whereas the foregoing recites the invention in terms of a method and/or apparatus, the reader will appreciate that the invention can be implemented by means of computer executable instructions, for instance borne on a data carrier, readable by a computer to configure the computer to perform one of the methods in accordance with the invention or to configure the computer as apparatus in accordance with one of the foregoing aspects of the invention. The data carrier may be a data storage medium, or may be a signal.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 illustrates an example group of local networks running a video conference;

Figure 2 illustrates a local network implementing an access control architecture in accordance with an embodiment of the invention;

Figure 3 illustrates operation at a requestor's home local network, of the authorisation of a request; Figure 4 illustrates operation, on another network, of the authorisation of a request;

Figure 5 illustrates an example use of the access control architecture in accordance with the described specific embodiment;

Figure 6 illustrates operation of the access control architecture by a user seeking permission to view restricted data and metadata; and

Figure 7 illustrates operation of the access control architecture by a user seeking to initiate a video conference.

Figure 1 in particular shows an example scenario, with a number of different parties on a number of different local networks, participating in a secure video conference.

For the avoidance of doubt, the description of embodiments herein makes reference to various terms which may or may not be terms in the art, but which are given particular meanings in the context of the specific description:

A "local network" is a network under the control of the same administration. This is similar to an administrative domain. Examples include a company or university network.

The "home local network" is a particular local network from whose perspective the present description is written.

An "other local network" is any local network with which the home local network may communicate.

A "virtual collaboration" is a group of users or resources working over more than one local network, with the network appearing as a single network.

A "Requestor" is a user or process working on behalf of a user. A user is "pseudonymous" if he can act anonymously to all parties except his home local network.

The access control architecture assumes a number of separate local networks, all of which have their own policy, implementations and software. These may be owned by different organisations. The architecture consists of a number of access control mechanisms that are added to each local network. These enable the different local networks to operate together in a secure way. Figure 2 shows the access control architecture used within a single local network.

Tokens and certificates

This architecture makes use of Authentication Certificates, Requests and Authorisation tokens.

Authentication Certificates bind a public key with an identity, are securely created by the Root CA and are activated along with the corresponding private key on the user's computer by the user.

Requests request access to networks, access to applications and applications to run. The illustrative names of the requests used herein are RequestAccessLocalNetwork, ApplicationAccessRequest, ApplicationRequest, OLNNetworkAccessRequest, OLNLocalApplicationAccessRequest, OLNApplicationAccessRequestCore and OLNApplicationAccessRequest.

Authorisation Tokens bind a public key with roles or rights. The illustrative names of tokens used herein are LocalNetwork Access Authorisation Token, ApplicationAccessAuthorisation Token, OLNNetworkAccessAuthorisation Token, OLNLocalApplicationAccessAuthorisation Token and DelegationAuthorisation Token.

Overview of authorisation flow This section provides an overview of the authorisation flow. The authorisation flow is the sequence of requests (with Authorisation Tokens in response) that a requestor has to carry out to enable an action to be performed.

There are two main authorisation flows. These are:

• Authorisation by a requestor to perform an action on their home local network.

• Authorisation by a requestor to perform an action on another local network.

The authorisations go through a fixed flow of requests with Authorisation Tokens being returned in response to requests. The order of the requests is fixed by the information required in each request, since each request requires the Authorisation Token provided in response to a previous request.

Authorising a requestor to perform an action on their home local network consists of three transactions. These are shown in figure 3 and are:

• A requestor gaining an Authorisation Token authorising them to access to their home local network (this may also authorise them to access other local networks). This maps a user onto a set of roles (this is request 1 returning Authorisation Token 2 in figure 3).

• A requestor gaining an Authorisation Token to perform an action on their home local network. This authorises the action that is to be performed, ensuring it obeys local network policy (this is request 3 returning Authorisation Token 4 in figure 3).

• The requestor performing the action (this is request 5 in figure 3).

Authorising a requestor to perform an action on another local network consists of five transactions. These are shown in figure 4 and are:

• A requestor gaining an Authorisation Token authorising them to access their home local network and other local networks. This maps a user onto a set of roles (this is request 1 returning Authorisation Token 2 in figure 4). • A requestor gaining an Authorisation Token from another local network to access it. This maps the roles from the requestor's home local network to the roles used on the local network performing the action (this is request 3 returning Authorisation Token 4 in figure 4).

• A requestor gaining an Authorisation Token from their home local network, authorising the action that is to be performed on another local network. This authorises the action that is to be performed, ensuring it obeys the requestor's local network policy (this is request 5 returning Authorisation Token 6 in figure 4).

• A requestor gaining an Authorisation Token to perform an action on another local network. A broker on the other local network authorises the action that is to be performed, ensuring it obeys the policy of the other local network that the action is to be performed on (this is request 7 returning Authorisation Token 8 in figure 4).

• The requestor performing the action (this is request 9 in figure 4).

As the more general Authorisation Tokens can be re-used, it is possible to start part way through these sequences of transactions by re-using an Authorisation Token that was previously obtained.

Description of components

All components are intended to run on every local network. With the exception of the Root CA (described below) and the Activation Agent (also described below), the following components interact with a requestor by receiving requests from the requestor, and performing actions or returning Authentication Tokens.

Auditing information is generated for every request and accounting information is generated on completion of an application. This information is sent to the Accounting and Auditing Broker on the local network.

Root CA

The Root CA creates all Authentication Certificates for the local network and it helps to distribute copies of Authentication Certificates to any process that requests them. The second function of the Root CA is to provides a means of validating Authentication

Certificates from other local networks.

The Root CA can create Authentication Certificates as it has the private key related to the root CA certificate. It uses this to create all Authentication Certificates that are required by the local network. Public keys need to be securely transferred to the Root CA to ensure that the public key and identity placed in the Authentication Certificates are genuine. Creation of Authentication Certificates occurs when the public keys are initially created.

Activation Agent

When requestors log on to their own computer, they need to gain access to their credentials, including the private keys that are associated with their Authentication Certificates. This is achieved by the user authenticating themselves to an Activation Agent on their local computer. This may occur as part of the logging on process.

Network Access Server

The Network Access Server controls access to various local networks. It operates by receiving requests to use a local network and providing Authorisation Tokens to use the local network.

There are two main requests. These are:

• Requests from requestors on the Network Access Server's home local network to access the home local network and other local networks. This request is performed to enable a requestor from the Network Access Server's home local network to access any local network.

• Requests to access the Network Access Server's home local network, for requestors that have a different home local network to the Network Access Server. This request is performed by a requestor from another local network to get access to the Network Access Server's home local network.

The initial action that a requestor performs after having activated iheir Authentication Certificate on their computer is to connect to their local network by sending a RequestAccessLocalNetwork message to the Network Access Server on their home local network. This enables the requestor to get permission from their home local network to log onto a number of different local networks. To access other local networks, permission must also be sought to access the other local network from the Network Access Server on the other local network.

A requestor sends a RequestAccessLocalNetwork request to the Network Access Server. This uses the information from the requestor's Authentication Certificate to identify the requestor so that:

• The home local network can decide whether policy allows them to access the requested local networks.

• Appropriate roles can be assigned to the requestor. The roles that are requested will depend on the work that the requestor intends to perform during the current session.

A requestor sends an OLNRequestAccessLocalNetwork request to the Network Access Server on another local network. This contains an Authorisation Token that identifies the user's roles and network so that:

• the other local network can check whether its policy allows a requestor from the requestor's local network to access the other local network.

• the appropriate roles can be assigned to the requestor for use on the other local network. These roles will depend on the policy of the other local network.

The returned Authorisation Token identifying the user's roles may be pseudonymous if desired.

In support of the operations performed by brokers and servers, they maintain the following information as required:

• A list of all other local networks that can be accessed and the policy for users of the local network accessing them • A list of all other local networks whose requestors' can access the current local network together with the appropriate policy for their access rights.

For remote access, when requestors are connected to other local networks, they can request authorisation to access networks through requests to the Network Access Server on their home local network, as digital signatures protect requests made by the requestor and Authorisation Tokens supplied by the Network Access Server.

Requestors can choose to be pseudonymous when they access networks. This is achieved by including a pseudonymous requestor public key in the request to their Network Access Server and signing the request with the associated private key as well the private key associated with their Authentication Certificate. Pseudonymity is then achieved by the Network Access Server returning a token to access the network that only includes the requestor's pseudonymous public key. All requests and tokens that are issued subsequent to this are then pseudonymous.

While choosing to be pseudonymous is most effective when initially requesting to access the user's own local network, users could also choose to start to be pseudonymous during any request, by following the above procedure.

Brokers

Brokers are services that authorise requestors to perform actions, audit actions and enforce policy. Requestors communicate with brokers by making requests. On receiving requests, brokers make a decision and either carry out an action or return an Authorisation Token.

Every local network has copies of all brokers and servers. This is necessary as all requests are initially authorised by a broker on the requestor's home local network. Therefore, even if a particular application does^' not exist on a local network, the corresponding broker will have to be supported if it is to be accessed on another local network. If a requestor wants to access an application on another local network, then an

Authorisation Token, consisting of a signed request, from the requestor's local network is obtained and presented to a broker on the application's local network. This enables:

• The broker on the requester's local network to check the request obeys the policy of the requester's local network, and show it agrees with the request by signing it.

• The broker on the application's local network to check the request obeys the policy of the application's local network.

The broker on the application's local network provides an Authorisation Token to access the application.

Application Access Authorisation Broker

The Application Access Authorisation Broker is provided to control access to applications. This deals with three cases:

1. Requestors on the home local network requesting access to applications on the home local network. In this case the broker receives a request from a requestor on the home local network.

2. Requestors on the home local network requesting access to applications on another local network. In this case the role of the broker is to approve requests that are to be made to the broker on the other local network. Receiving signed requests that are to be made to the broker on the other local network and countersigning the request if it is approved, performs this.

3. Requestors from another local network requesting access to applications on the broker's home local network. In this case, the broker receives a request from a requestor on another local network.

The Application Access Authorisation Broker makes the decision as to whether the requestor is allowed to access the application. The broker makes this decision by checking the validity of the information supplied and the current policy on the local network. If the policy on the local network allows the requestor to access the application, then the requestor is provided with the appropriate Authorisation Token granting them access to the application.

Data Access Authorisation Broker

The Data Access Authorisation Broker is a special case of an Application Access Authorisation Broker and is provided to control access to data. The data access broker protects access to the following types of data:

• Encrypted data. In this case the Data Access Authorisation Broker authorises access to data synopses or groups of data synopses and provides keys to decrypt the data.

• Unencrypted data with restricted access. Requestors will need defined roles or combinations of roles to access this data.

Controlling access to data in this way allows fine granularity in access control to be applied, down to individual data objects.

Accounting and Auditing Broker

This broker maintains a record of activities in the current local network. This record is maintained through the broker being sent accounting information data packets and auditing information data packets. These arrive from the servers, brokers and applications on the local network. Accounting information and auditing information is always sent to the Accounting and Auditing Broker on the server's, broker's or application's local network. The auditing information may be signed if necessary.

The information that is sent to the Accounting and Auditing Broker is flexible and able to vary for each local network transaction. This enables a wide potential range of uses of the Accounting and Auditing Broker, which is helped by it being a central monitoring point that has a view of the whole local network. Examples of uses include performing checks on the current state of the local network, or analysing data for performance reasons or potential misuse.

Enforcement Broker When rapid revocation is required, the Enforcement Broker exists to provide the means to enforce immediate revocation of:

• Requestors that have been revoked.

• Activities initiated by requestors that have been revoked.

• Activities relating to privileges that have been revoked from a requestor.

The Enforcement Broker receives:

• Information on authenticated users, issued authorisations and applications that are in use. This is received from the Accounting and Auditing Broker.

• Information on current policy and changes in policy from the Policy Server.

The Enforcement Broker can use this information to efficiently:

• Revoke active processes that are against policy due to changes in policy.

• Revoke new processes that are being requested in response to Authorisation Tokens with revoked users or rights.

Revocation requires that all Authorisation Tokens issued to each requestor are uniquely identifiable to the Authorisation Token issuer's home local network.

The Enforcement Broker can optionally include software to monitor for abuse of the system and take action to stop the abuse or to make resource allocation fairer.

Policy Server

The Policy Server interfaces this access control architecture to policy management on the local network. The Policy Server serves two main purposes. These are:

• As a tool to enter policy into the local network.

• To communicate policy to all processes that need to know it.

There are two cases of changing policy:

• Changing policy on the local network.

• Changing policy on other local networks. While it is likely that the latter will not be possible for most local networks, as it may be considered insecure, it may be possible in limited circumstances. For example, a manager of a virtual collaboration may be allowed to add a new user from the current local network to the same virtual collaboration on another local network. This would prevent a virtual collaboration requiring a separate manager on every local network.

Applications

Applications is a general term covering a wide range of services provided by computer systems, including access to specific software packages, protected data and databases.

Applications are all started by sending a request to perform the required operation to the application. This request is signed by the requestor and includes an Authorisation Token issued by a broker from the application's local network.

In this architecture, the application can be represented by an agent that accepts and validates Authorisation Tokens, as well as running or acting as an interface to the actual application. This enables the architecture to work with legacy applications and applications that it is not possible to modify to accept Authorisation Tokens.

Applications need to be able to create signed requests on behalf of the requestor in order to access data and run other applications. This is known as delegation, and is covered below.

Running Applications

To run an application, a requestor sends a request for a service to the application. These requests include an Authorisation Token authorising the action and are signed by the requestor. When an application receives a request, it checks the associated Authorisation Token is appropriate, which includes a check with the help of the Enforcement Broker to see if the token has been revoked.

If the request is a valid request, the requested action is performed. If interactions between requestors and applications and interactions between different applications occur across a local network these may need to be secured, however, these are outside the scope of this architecture.

Content Provider

A Content Provider is a special case of an application and consists of a combination of a data store and an interface. The Content Provider acts as an interface to a wide variety of classes of data that are stored on the local network. It is primarily used to distribute data where access is controlled or where payment is required to access the data as appropriate. This ranges from data that is confidential to the organisation or projects, to libraries of copyrighted pay to view data (E.g. Videos, books, BSI Standards, IEEE publications etc). Data that can be accessed through the Content Provider can include:

• Encrypted data that may only be decrypted by some users (by obtaining an appropriate key from a broker).

• Encrypted data that requestors have to pay to be given access to. The summary of the data must include the cost if the data is charged for access. The cost needs to be included in the request to access the data in a special field, so that it is agreed between the owner and requestor.

• Unencrypted data with access rules.

• Unencrypted, generally available data.

Decryption Application

Access to encrypted data is achieved with the aid of a Decryption Application that is run by a requestor. The Decryption Application requires an Authorisation Token containing a key to decrypt data and requests the Authorisation Tokens containing the keys as required.

Validating Authentication Certificates from other local networks

To ensure the integrity of transactions between local networks so that all transactions can be made accountable, it is necessary for each local network to verify the signatures of requests and Authorisation Tokens that have been issued by other local networks.

Difficulties could arise because local networks may be setup independently with their own Certificate Authorities meaning that replacing all Authentication Certificates with Authentication Certificates issued by a single Root CA may be impractical. This can be solved by some means of cross certification following one of a number of standard methods.

This architecture has been designed to enable it to provide secure access control. This is achieved through all actions being traceable back to a requestor's Authentication Certificate, with all steps of an interaction being secure, in a fixed order and dependent on the previous step.

Interactions are made secure through:

1. Tokens and requests being signed so that they cannot be forged and the owner of the signature is checked to ensure that they have the rights to create the token.

2. Tokens contain the requestor's public keys so only the requestor that they are issued to can sign requests containing them.

3. It is enforced that the requests and returned tokens occur in a fixed order which ensures that the architecture is followed.

4. Nonces being used to stop replay of tokens when necessary.

Brokers check policy

In this architecture, policy is checked by the brokers and not by the applications. This separates policy information from the users and applications, making it less vulnerable.

Obeying policy in a heterogeneous network

Obeying policy can be a complex issue in a heterogeneous network consisting of many local networks, where each local network has its own policy and the policy of different local networks can conflict. The approach selected by this architecture, implement policy in a way that obeys the policy of the requestors and applications local networks. This is secure as it ensures the policy of the networks involved in each transaction are obeyed. This also simplifies policy as to enable an action, policy only needs to be made compatible between two networks, and not across all networks.

Minimising manual intervention Manual intervention is minimised for efficiency reasons and to minimise human error.

Some manual intervention is required, but has been kept to that which is unavoidable or required for security reasons. This mainly relates to segregation of duties to stop users being able to assign themselves privileges that they are not allowed to or they may abuse.

Compartmented mode

Compartmented mode can be supported by the architecture, and can be particularly useful for some government applications. This is an optional, more secure, implementation of virtual collaborations. Compartmented mode provides a higher degree of assurance in the separation of different groups of users. This can be achieved by encrypting each virtual collaboration within each local network (connections between local networks are already encrypted) or by using V-LANs for each virtual collaborations within each local network.

Granularity

The architecture is able to support from coarse to very fine granularity of access control. The granularity of this access control architecture is not defined by the architecture itself, but by the policy of the local networks involved. This enables this architecture to be flexible to many different requirements.

Authorisation Tokens can authorise:

• Access to single files.

• Use of a single application.

• Use of an application for a single operation.

• Use of a combination of many files and applications.

Combinations of files and applications may be associated in local networks using roles.

With the home local network extending authorisations, the home local network makes the compromise between efficiency and granularity of the control of a requestor's actions. The requestor's home local network makes this decision by deciding the scope of the Authorisation Tokens that it issues. For higher efficiency, the local network can issue single Authorisation Tokens that enable the requestor to perform a wide range of operations. For fine grained control of a requestor's actions, the local network can insist on a new Authorisation Token for every action.

Delegation of existing authorisations

Once a requestor has started an application, the application may need to access data from a content provider or make requests of other applications. If the ApplicationAccessAuthorisation Token that provided the authority to start the current application contains the rights to perform the new requests, then authority can be delegated to the application to make these requests. This is secure, since the rights contained in the ApplicationAccessAuthorisation Token have been approved by the requestor's and application's local network.

Delegation of authority is achieved by the requestor sending the application a DelegationAuthorisation Token in the ApplicationRequest that enables the application to use the ApplicationAccessAuthorisation Token in the ApplicationRequest to make ApplicationRequests on behalf of the requestor.

The DelegationAuthorisation Token ties the application's public key to the ApplicationAccessAuthorisation Token. This shows processes that are in receipt of a request from the application, that the requestor has given the application permission to use the rights in the ApplicationAccessAuthorisation Token.

Further delegation of rights by the application is not allowed using this architecture. This prevents applications from delegating a user's rights to other applications without the user's knowledge. Instead, the process described below must be used.

Delegation: Obtaining new authorisations

Authorisations are extended by getting the requestor's process to seek the new authorisations and forward the new Authorisation Tokens (called "emulated delegation" from here on). This is achieved by: • The application that requires increased authorisation sending a signed request to the requestor for authorisation for access to the new resources that it has not been given rights to access.

• The requestor's process requesting authorisation to access the resource, following the same procedures that it normally uses to gain authorisation to access the resource (the requestor's process has to first apply to a broker on the requestor's local network and then a broker on the Application's local network, if different).

• The requestor sends the new Authorisation Tokens to the application, in a signed request to access the resource, along with a DelegationAuthorisation Token so that the application can use the token to make the request.

Scalability of the access control architecture

This architecture has been designed to remain effective when using large numbers of local networks, with large numbers of users and large problems. Elements of the architecture that are aimed at making the architecture general and scalable include:

• Policy checked by brokers. This means that applications do not need to know about policy, and removes the need for complex policy dissemination to all applications.

• Agents to handle legacy applications.

• Small, simple, Authorisation Tokens, so transmission does not lead to a significant overhead.

• Flexible Authorisation Token granularity so Authorisation Tokens may provide access to one or many pieces of data or applications.

Virtual Collaborations

The previous sections describe the access control architecture. In this section we show how this architecture can be used to create virtual collaborations.

Virtual collaborations are initially made possihle through a number of onetime offline setup activities. These include making contractual arrangements, changing local network policies, exchanging Root CA certificates, installing the access control architecture and translating and creating appropriate policies. Once this setup is complete, virtual collaborations can be created. To create each new virtual collaboration, a number of activities are necessary on each local network that is involved, to make the virtual collaboration possible. These include identifying the scope of the operations that the virtual collaboration is intended to perform and defining roles for users and policies that enable them. Virtual collaborations also need to be assigned managers and users and they need to be assigned appropriate roles. Once this has been done and the policies distributed the virtual collaboration can be used. There are no explicit start or finish operations required.

To use a virtual collaboration, a requestor makes a request to join the virtual collaboration to the Network Access Server. In response, the Network Access Server checks if the requestor has been given permission to join the virtual collaboration and if so, provides the requestor with an Authorisation Token that includes the appropriate roles. These roles are usually specific to that collaboration, and are defined at the time the collaboration is created (see above). The Network Access Server also supports virtual collaborations by checking policy to ensure that the requestor has not requested a set of roles that provide them with access to conflicting combinations of virtual collaborations. This helps to enforce security between the different virtual collaborations.

Management of virtual collaborations is achieved in concert with the Policy Servers. System administrators or ordinary users, or a combination of both of them, depending on local network policy, perform this management, which includes dynamically adding and removing users as well as assigning roles to users. It is achieved by sending requests to the Policy Servers. Such requests must be sent to the Policy Servers on each local network that is involved in the collaboration. This may be achievable by one manager, who can perform management for the collaboration across multiple local networks, or policy may dictate that separate managers are required for each network.

This access control architecture makes use of several advanced techniques:

• It is designed to work with Policy Based Management.

• It is designed to work with Role Based Access Control.

• It supports Federated Identity Management.

• It supports pseudonymity for users. These, together with the other features of the architecture, are used to provide the following operational configurations and implementations.

Confidentiality

Policy information and software can be separated from users and applications. This means that there is limited visibility of roles and policy information to users and applications. In addition, all the complex policy decisions are made in the brokers, not by the applications or applications' agent wrappers, and the mapping between policy, roles and rights is performed by brokers. This improves security by reducing access to information that is used to make security related decisions, and concentrating its use in a few, highly trusted and dependable, places.

• The architecture ensures that the policy of the requestor's local network and an action's local network is followed.

• Relatively little information is passed between different local networks (domains). Just the roles that are required to gain the authorisations that the requestor requires need to be passed. In addition, users can act pseudonymously, which further reduces the information local networks can learn about each other.

• All actions can be traced back to a single user that has been authorised to use a defined local network. This can act as a deterrent against inappropriate release of data, and can also be used to detect and then prevent further inappropriate disclosures.

• Protection against man-in-the-middle attacks. All information is transferred securely, so it cannot be altered without detection. In addition, replay protection can be added where replay may cause damage.

• Protects data, applications and local networks from unauthorised use. The authorisation process for Authorisation Tokens ensures that the policy of the data, application and all local networks involved in an action are followed. In addition, Authentication Certificates are only provided to authorised users and Root CA certificates are manually distributed to ensure their authenticity.

• Support for Digital Rights Management. Data and applications can be supplied with rules that control their operation, which could then be enforced by Digital Rights Management software (although this software is outside of the scope of the architecture).

• Support included for rapid revocation. The access control architecture includes mechanisms to trace all tokens and activities that are occurring, so that all actions can be immediately revoked. This includes operations that have already been started.

• Protects the local networks against the actions of other local networks. The Network Access Server selects which other local networks are allowed to access the current local network.

Availability

• Parallel brokers can be used on each local network to improve availability and throughput.

• The architecture includes the ability to protect each local network against malicious activity. The enforcement broker can detect malicious activity and tokens from the responsible requestors or networks can be revoked.

• Parallel connections between local networks can be used to improve availability. The overall architecture does not specify the network architecture

Accountability

• The broker or service that issued all tokens can be traced.

• The requestor who made each request, can be traced by their home local network.

• All actions are traceable back to a requestor.

• Supports rapid revocation (see above).

• Delegation controlled by the requestor.

Scalability

• Support for grid applications. Applications can obtain new Authorisation Tokens from the requestor's process. These Authorisation Tokens or existing ones can be used to start new processes. This is controlled by the scope of the Authorisation Token. • Prioritisation information can be placed in tokens. This is currently not used in the architecture, but applications may use it as required.

• Supports optimisation of task distribution. The home local network of the requestor issues all tokens, and so knows all networks that are being used by all applications that are running simultaneously on its behalf. This information can be used to optimise placement of new tasks on resources, by, for instance, selecting resources that are not currently being used by the application.

• Supports multiple parallel secure virtual collaborations. The architecture places no restrictions on parallel virtual collaborations.

• Authorisation Tokens are relatively simple and small, as they only include roles relevant to permissions, making their transmission relatively easy. Authorisation Tokens do not generally include policy information.

Flexibility

The architecture is designed to work with:

• Different operating systems.

• Different policy software on different local networks with different token formats.

• Different role definitions on different local networks.

• Situations where requestors interact with applications and applications interact with applications.

• Legacy applications, through the use of agents.

• Different levels of granularity. The granularity of a solution using this method is flexible and multiple different granularities can be used simultaneously. (Granularity = the number of different operations that an Authorisation Token provides roles or rights to perform, and also the number of different actions a policy software decision covers).

By way of example, a practical case of use of a computer system in accordance with the specific embodiment of the invention will now be described. This section describes a user called Alice accessing data on another local network. This example shows how the access control architecture protects the data. This can be seen in figure 6. This example excludes auditing, accounting and revocation. This process consists of:

1. Alice attempts to access data that she has not yet obtained permission to access.

2. The browser identifies that the ApplicationAccessAuthorisation Token that it has been given is for the current network and that it does not have an ApplicationAccessAuthorisation Token the with rights to access the Other Local Network (OLN). The browser application then informs Alice's process that it needs an ApplicationAccessAuthorisation Token with rights to access the requested data on the OLN.

3. Alice requests permission to use the OLN with a set of roles that enable her to access the data that she is interested in. Alice may also provide a pseudonymous public key at this point so all further transactions stemming from this LocalNetworkAccessAuthorisation Token will be pseudonymous.

4. Alice's local Network Access Server checks if Alice is who she claims to be, if she is allowed to access the OLN and if she is allowed to have the roles that she requested. It returns an Authorisation Token with permission to access the OLN and the requested roles.

5. Alice requests permission to use the OLN from the OLN Network Access Server.

6. The OLN Network Access Server checks if Alice is allowed to access the OLN. It translates her Home network roles to OLN roles and checks that she is allowed to have the translated roles on the OLN. It then returns an

OLNNetwork Access Authorisation Token with permission to access OLN and her OLN roles.

7. Alice forms the request that is to be sent to the OLN to get permission to access the data (OLNApplicationAccessRequestCore) and places it in an OLNLocalApplicationAccessRequest. This is sent to the local Application Access Authorisation Broker. This enables the local Application Access Authorisation Broker to check that it approves the request that Alice is about to make to the OLN Application Access Authorisation Broker.

8. The Application Access Authorisation Broker checks if it approves Alice's request. If it does, it copies it into an OLNLocalApplicationAccessAuthorisation Token and signs the Authorisation Token to show that it approves the request that is to be made to the OLN. 9. Alice requests permission from the OLN Application Access Authorisation Broker to access the data she wishes to use. The request is embedded in an OLNLocalApplicationAccessAuthorisation Token.

10. The OLN Application Access Authorisation Broker checks the OLNLocalApplicationAccessAuthorisation Token and

OLNNetworkAccessAuthorisation Token are valid, and whether Alice has the roles to access the data that she has requested to see. An ApplicationAccessAuthorisation Token is returned allowing Alice to access the data.

11. Alice sends a signed request to access the data to the browser application. This includes a DelegationAuthorisation Token to enable the application to make requests to the local network, using the rights in the ApplicationAccessAuthorisation Token that was provided in the ApplicationRequest.

12. The browser creates an ApplicationRequest which is sent to the OLN file store access application, and requests data from the file store in response to Alice's requests. The ApplicationRequest is the same as the one sent by Alice to the application, but signed by the application instead of Alice.

13. The file store application provides the requested data to the browser application.

14. The browser application displays the information Alice requested.

Actions 2 to 1 1 are an example of emulated delegation, as described above.

A second example will now be described of a user (Alice) starting video conferencing software on another local network (OLN). This example assumes Alice has already been authorised to access both her home local network and the OLN by the Network Access Servers. This example is also applicable to a user joining a video conference that has been started on an OLN. The main difference would be that requests were to join rather than start a video conference. The process is shown in figure 7.

This process consists of:

1. Alice forms the request that is to be sent to the OLN to start the video conferencing application (OLNApplicationAccessRequestCore) and places it in an OLNLocalApplicationAccessRequest. This is sent to the local Application Access Authorisation Broker. This enables the local Application Access Authorisation

Broker to check that it approves the request that Alice is about to make to the OLN Application Access Authorisation Broker.

2. The Application Access Authorisation Broker checks if it approves Alice's request. If it does, it copies it into an OLNLocalApplicationAccessAuthorisation Token and signs the Authorisation Token to show that it approves the request that is to be made to the OLN.

3. The Application Access Authorisation Broker sends auditing information covering Alice's OLNLocalApplicationAccessRequest to the Home network Accounting and Auditing Broker.

4. Alice requests authorisation to start the video conferencing software from the OLN Application Access Authorisation Broker. The request is embedded in an OLNLocalApplicationAccessAuthorisation Token.

5. The OLN Application Access Authorisation Broker checks the OLNLocalApplicationAccessAuthorisation and OLNNetworkAccessAuthorisation Tokens are valid, and whether Alice has the right roles to run the video conferencing software. An ApplicationAccessAuthorisation Token is returned with the rights to start the video conferencing software.

6. The OLN Application Access Authorisation Broker sends auditing information covering Alice's OLNApplicationAccessRequest to the OLN Accounting and Auditing Broker.

7. Alice sends an ApplicationRequest request containing an ApplicationAccessAuthorisation Token to the video conferencing application, to request that it runs.

8. The agent in the video conferencing application sends Alice's ApplicationAccessAuthorisation Token to the OLN Enforcement Broker to see if it has been revoked.

9. The OLN Enforcement Broker checks if the ApplicationAccessAuthorisation Token has been revoked and acknowledges that the Authorisation Token is valid if it has not been revoked.

10. The video conferencing agent sends auditing information to the OLN Accounting and Auditing Broker, informing it that the video conferencing application has been started by Alice. 11. The Accounting and Auditing Broker sends auditing information to the Enforcement

Broker, informing it that the video conferencing application has been started by Alice. This can be used to support rapid dynamic revocation of Alice, by identifying the applications that Alice is currently using. This may be beyond the requirements of some systems.

12. The agent starts the video conference application.

13. Alice can interact with the video conference application through the agent.

Illustrative requests

Table 1: Requests : Other messages

Table 2: Other messages Illustrative token definitions

Authorisation Token Number/Name Authorisation Token contents.

Table 3: Authorisation Token types.

Claims

CLAIMS:

1. A method of managing, for a computer on a first local network, access to a facility hosted on a second local network in communication with said first local network, comprising the steps of: on receipt of a request from said computer for access to said second local network, determining at said first local network if said computer, configured by means of user account information, is authorised to gain access to said second local network and, if so authorised: determining at said second local network if said computer, configured by means of user account information, is authorised to gain access to said second local network and, if so authorised: determining, with regard to said user account information, second network user role information, said second network user role information being capable of being used in said second local network to govern the determination of authorisation of a computer, configured by means of said user account information, for access of a facility hosted on said second local network; and on receipt of a request from said computer for access to said facility, determining at said first local network if said computer, configured by means of user account information, is authorised to access said facility hosted on said second network, and, if so authorised: determining if said computer, configured by means of said user account information, is authorised to access said facility hosted on said second local network, with respect to said second network user role information.

2. A method in accordance with claim 1 wherein the step of determining at said first network if said computer, configured by means of user account information, is authorised to gain access to said second computer network is, if so authorised, followed by a step of sending, to said requesting computer, a first local network authorisation token indicating permission by said first network for said computer, so configured, to access said second network.

3. A method in accordance with claim 2 wherein the request is signed by the requesting computer, and comprising the step of signing the token for receipt by the requesting computer.

4. A method in accordance with any preceding claim wherein the step of determining at said first network if said computer, configured by means of user account information, is authorised to gain access to said facility hosted on said second computer network is, if so authorised, followed by a step of sending,- to said requesting computer, a token indicating permission by said first network for said computer, so configured, to access said facility hosted on second network.

5. A method in accordance with claim 4 wherein the request is signed by the requesting computer, and comprising the step of countersigning the request to form a token for receipt by the requesting computer.

6. A method in accordance with any preceding claim wherein the step of determining at said first network if said computer, configured by means of user account information, is authorised to gain access to said second computer network comprises one or more of the following: considering the availability of a substantially equivalent facility in the first network to that requested; considering security implications related to the request for use of a facility on another network; considering a trust level assigned to the user corresponding to the user account information; considering a trust level assigned to the second network by the first network; and considering the cost of use of the facility in the second network.

7. A method in accordance with any preceding claim wherein the step of determining at said second network if said computer, configured by means of user account information, is authorised to gain access to said second computer network is, if so authorised, followed by a step of sending, to said requesting computer, a second local network authorisation token indicating permission by said second network for said computer, so configured, to access said second network.

8. A method in accordance with any preceding claim and including the step of storing a list of local networks in respect of which requests for access by a computer are to be granted, wherein said step of determining at said first network if said computer is authorised to gain access to said second computer network comprises referring to said list in order to determine if said network is listed in said stored list for said requesting computer.

9. A method in accordance with any preceding claim and including the step of storing a list of local networks from which requests for access by a computer are to be granted, wherein said step of determining at said second network if said computer is authorised to gain access to said second computer network comprises referring to said list in order to determine if said requesting computer is on a network listed in said stored list.

10. A method in accordance with claim 9 wherein said step of storing a list of local networks includes storing information relating to individual computers, or groups of computers, on said local networks, and corresp.onding access right information.

11. A method in accordance with claim 9 or claim 10 wherein said step of storing a list of local networks includes storing information defining groups of networks, each network within a group having the same authorisation profile with respect to said second network.

12. A method in accordance with any preceding claim wherein the step of determining if said computer, configured by means of said user account information, is authorised to access said facility hosted on said second network, is followed by the step of sending a facility access token to said requesting computer for use by said computer in using said facility.

13. A method in accordance with any preceding claim and including the step of storing facility access policy information defining an access policy for rights of access by computers on other local networks to said facility and wherein said step of determining if said computer is authorised to access said facility hosted on said second network includes referring to said facility access policy information.

14. A method in accordance with claim 12 wherein said facility access policy information defines access policy information for an individual computer on another network, with respect to an individual facility.

15. A method in accordance with claim 12 wherein said facility access policy information defines access policy information for a class of computers on another network, with respect to facilities.

16. A method in accordance with claim 12 or claim 14 wherein said facility access policy information defines access policy information with respect to classes of facilities.

17. A method in accordance with any preceding claim wherein the step of determining if said computer, configured by means of user account information, is authorised to gain access to said second computer network is preceded by a step of storing first network role information corresponding to said user, said first network role information being available for determination of access to facilities hosted on said first network.

18. A method in accordance with claim 17 wherein the step of determining said second network user role information comprises mapping said first network role information for the user to corresponding information defining possible roles in said second network.

19. A method in accordance with any preceding claim wherein said facility comprises data stored in a data storage location in said second network.

20 . A method in accordance with claim 19 wherein said data is protected by encryption and, if said computer is so authorised to access said data, including the step of issuing a decryption key to said computer to enable access to said protected data.

21. A method in accordance with any preceding claim wherein said facility comprises an application executable on said second network.

22. A method of executing an application hosted on a second network in response to a request by a computer on a first network, comprising managing access to said application in accordance with the method of claim 21 and, on receipt of successful determination that said computer has authorisation to access said facility, further comprising the step of said requesting computer sending an application request to said second network, for execution of said application.

23. A method of executing an application in accordance with claim 22 and further comprising the step of checking, in said second network, that said authorisation remains valid and, if not, sending information indicating revocation of said authorisation.

24. A method in accordance with claim 23 and including, on receipt of information indicating a revocation of said authorisation, sending a failure message to said requesting computer.

25. Access control apparatus for granting, to a computer on a first local network, access to a facility hosted on a second local network in communication with said first local network, comprising: first computer network access authorisation means in said first local network operable to receive a request from said computer for access to said second local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said second local network; second computer network access authorisation means in said second local network operable to receive a request from said computer for access to said second local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said second local network; second network role determining means for determining, on the basis of said user account information, second network user role information, said second network user role information being capable of being used in said second network to govern the determination of authorisation of a computer, configured by means of said user account information, for access of a facility hosted on said second network, said second network role determining means being operable on the basis of determination, at said second computer network access authorisation means, that said requesting computer is authorised to access said second network; first computer network access authorisation means in said first local network operable to receive a request from said computer for access to said facility hosted on said second local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said facility hosted on second local network; and facility access determining means for determining if said requesting computer, configured by means of said user account information, is authorised to access said facility hosted on said second network, with respect to said second network user role information.

26. Access control apparatus for use in a home local network and operable to cooperate in use with corresponding apparatus in one or more other local networks, the apparatus being for use in granting access to one or more facilities hosted on said home local network or said one or more other local networks in communication with said home local network, comprising: home network access authorisation means operable to receive a request from a computer in said home network for access to another local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said other local network; other network access authorisation means operable to receive a request from a computer in another local network for access to a facility hosted on said home network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said home local network; network role determining means for determining home network user role information, on the basis of user account information for a requesting computer on another network, said home network user role information being capable of being used in said home network to govern the determination of authorisation of said requesting computer for access to said facility hosted on said home network, said network role determining means being operable on the basis of determination that said requesting computer is authorised to access said home network; wherein said other network access authorisation means is further operable to receive a request from a computer in said other network for access to a facility in said home local network and, on receipt, to determine if said computer, configured by means of user account information, is authorised to gain access to said facility in said home local network; and facility access determining means for determining if said requesting computer on said other network is authorised to access said facility hosted on said other network, on the basis of said home network user role information.

27. A data carrier bearing computer readable information defining computer executable instructions operable when loaded into a computer, to cause said computer to perform a method in accordance with any of claims 1 to 24.

28. A method substantially as described herein, with reference to the accompanying drawings.

29. Apparatus substantially as described herein, with reference to the accompanying drawings.