EFDA-Fed: European federation among fusion energy research laboratories

R. Castro1, J. Vega1, A. Portas1, A. Pereira1, S. Balme3, A. Duarte6, H. Fernandes6, J. Kadlecsik7, P.

Lebourg3, A. Neto6, F. Oliveira6, K. Purahoo4, F. Reis6, C. Rodriguez2, J. Signoret3, J. M. Theis3, K

Thomsen5,

1 Asociación EURATOM/CIEMAT para Fusión. Madrid. Spain 2 Departamento RedIRIS. Entidad pública empresarial Red.es. Madrid. Spain 3 Association EURATOM-CEA, CEA/DSM/ DRFC Département de Recherches sur la Fusion Contrôlée,

CEA-Cadarache, 13108, St Paul-Lez-Durance, France 4 EURATOM/UKAEA Fusion Association, Culham Science Centre, Abingdon OX14 3DB, UK 5 EFDA Close Support Unit Garching, Max Planck Institut für Plasmaphysik, Boltzmannstr. 2, D-85748

Garching, Germany 6 Centro de Fusão Nuclear, Associação EURATOM/IST, Lisboa, Portugal 7 KFKI Research Institute for Particle and Nuclear Physics of the Hungarian Academy of Sciences, and

the Association EURATOM/HAS, Budapest, Hungary

Abstract The fusion energy research in Europe is developed by a set of laboratories of different countries and organisations. EFDA is an organisation whose main objective is to promote and improve the coordination and collaboration among these laboratories. In this paper a working federation (EFDA-Fed) that gathers EFDA (as organisation) and a set of fusion research laboratories: EURATOM/CIEMAT (Spain), CEA (France), JET (UK), IST (Portugal) and KFKI/HAS (Hungary), is described, focusing on new solutions found in the integration process, and technical aspects of the federation as system architecture, integration of new services, and new types of client applications used in a distributed research environment.

Keywords federation, fusion, PAPI, authentication, authorization

1 Introduction Due to improvement in data communications and the integration of computer systems into Internet,

users have being developing their way of working from closed systems, where working stations, services and resources are isolated at communication level from other systems, to open systems where services and resources are available from any point of Internet. In this type of environment, users accesses to resources and services, which are distributed and located in different organizations, each of them, manages and specialises in a set of services. On the other hand, the concept of connection to Internet has developed very quickly, above all, with the generalization of WIFI technologies. Nowadays, it is very difficult to use exclusively a fix PC for connecting or to specify a fix source IP address for the connections. Users require mobility in their way of working. These new requirements have demanded new types of security solutions for computer systems, which must be able to work in multi-organisation environments, so they must be flexible enough to be integrated with installed systems and new developments, they must be able to scale independently the number of organisations and users, and they must enable mobility. These new necessities make solutions, which are valid for closed systems, very difficult to manage in this type of environments.

1.1 Description of the problem The fusion energy research in Europe is developed by a set of laboratories of different countries and

organisations. EFDAi is an organisation whose main objective is to promote and improve the coordination and collaboration among these laboratories. Every fusion research laboratory has to process and store data generated by the experiment. The researchers use intensively tools, usually developed locally, to access and analyse this data. As every fusion laboratory operates a different machine, regarding the type of investigation a scientist is focused on, he is usually more interested in particular experiments, being very common scientists travelling to other laboratories to complete their work. On the other hand, EFDA has working groups that develop different projects, and collaborative tools are essential for the coordination of the members who belong to the different European organisations. All these elements make EFDA organisations a perfect environment for the development of technologies to encourage collaborative work and to enable users to have access in a secure and simple way to resources and services distributed in different organisations. Some approaches are currently used in EFDA organizations to control the access to resources located in user-external organizations. One very extended solution is to use remote desktop technologies such as: Citrix or VNC. These solutions enable users to operate remotely tools and resources, which are located in an external organisation and which interact internally in the local network of that organisation. Another extended access control method is the source IP address filter. In both methods the management of all users who want to connect is centralized, and new users must be registered previously in a central repository.

With a similar philosophy, ITERii is designed with the idea of being a fusion centre open to researchers from different countries and laboratories, where will be necessary to enable remote access to data and applications. The installation of a real federation among EFDA organisations will allow doing real analyses about the convenience of secure multi-organization technologies applied to fusion research environment.

1.2 Main requirements From the problem previously described it is possible to get a set of requirements that must be

supported for any solution applied. From a functional point of view, the set of commonly used tools by researchers must be maximized. In this sense, web browsers such as: Mozilla, MS Explorer, Safari or Opera, are a good example and they are currently used for accessing to almost services and resources. Other important example is JAVA applications, and more specifically Java Web Startiii, which enable users to start and update multiplatform applications (because they are implemented in JAVA) with just one click in a web link. Other important functional requirement is mobility. Users and more specifically researchers, usually have to move to different organisations and connect to the network using different technologies, and in all cases their working environment and the set of resources they are allowed to access should be the same, independently of their location. Following this objective, during last years a very important enforces has been done, for example in TJIIiv, unifying data access from applications through HTTP protocol. To do it, a three layers model have been applied, and data access layer has been implemented using a HTTP applications server as front-end of the internal systems.

From a security point of view, access to services and resources must be restricted to users, which are authorized, and it must be able to implement sophisticated access control policies based on coherent fusion research properties. At the same time, it is necessary to minimize the number of passwords needed to access to all the resources and the number of times a user has to be authenticated into the same session. It is very wished solutions that use just one authentication (Single Sing On).

2 Federation In order to give a multi-organization solution to the problem previously described, a federation that

covers a set of EFDA organisations, as it can be seen in Fig. 1 has been started up. A federation is an organisational and technological solution, which involved a security technology and a set of common policies for providing a secure infrastructure to a multi-organisation environment. There is a set of properties that any federation must take into account, and a set of elements that any federation should have.

Fig. 1 Diagram that represents EFDA federation with all the organisations involved.

2.1 Federation properties Identity and privacy: This is a basic property in a federation. Must be possible to associate identities

to users, resources or components of the system. These identities must be valid for all the elements of the federation and must enable to univocally identify them. For example, an identity is associated to a user after he has been authenticated into the federation, and thanks to it the user will be identified in any service or resource of the federation. Into a federation, a organisation can play one of the following roles:

Identity provider: This is the case of an organisation that manages its users and it is responsible of their authentication. At the same time, this organisation can store and provide additional data about their users that can be useful for the evaluation of an access control rule into the federation.

Service provider: This is the case of an organisation that provides resources or services to users who belong to the federation. These resources usually have an access control policy, which is implemented using a set of rules.

Trust: This is other basic property of a federation. There must be trust relations at different levels: Among organisations: There must be trust about the veracity of data received (usually used for

evaluating a access control rule), and about the right uses of sent data in the destination organisation. Among system components: In the communication between two elements of the system, the receiver

must trust about the identity of the sender, about the veracity of the received data, and about the its integrity.

Attributes coherency: It must be coordination among the federated organisations for ensuring syntactic and semantic coordination between the user data stored in identity provider organisations and the attributes used by service providers in their access control rules. For example, if the is a access rule as "security_level > 3", there must be a coordination among organisations about the attribute "security_level" at syntactic and semantic level.

Good uses policy: It is wished to have a minimum set of rules among users, identity providers and service providers, about right uses into the federation. This will allow keeping trust among them. Typical examples of use rules are about authentication methods recommended, service uses, information that can be stored in logs, etc.

Joining process: It is important to have a criterion about who can join into the federation and a basic procedure for joining. This help to keep trust among organisations.

2.2 EFDA federation repository EFDA federation has a common repository that is implemented as a web zone:

"http://efdafed.fusion.ciemat.es". Inside this web information about different aspects of the federation can

be found, and is used by federation members as a central element where they can find updated information related with different aspects of the federation. The content of this repository is specific of EFDA federation, but information structure and elements that can be found inside are very common to any federation. In fact, a very similar repository could be applied to any federation just changing specific content.

Fig. 2 Web site of the central EFDA federation repository

At fist level the following sections can be found: Site home. In this section there is an introduction about EFDA federation, explaining its objectives,

structure, type of organizations involved, and the set of requirements that EFDA federation supports. Joining EFDA federation. In this section there is a description about the type of organisations that

can join to EFDA federation, and a description step by step of the process that a new organisation has to follow for joining. In few words, the joining policy.

Organisations. In this section there is a repository of all the organisations involved. For each of them, some relevant information can be found:

• Web site: Home web link of the organisation • Authentication Server: Important information about its authentication server, such as: its identity,

its URL for authenticating, type of applications supported by the authentication server for its users (depending on the technology or distribution, JAVA applications can be supported), and its public key file.

• Resources: List of available resources and services for the federation. More detailed information about each resource can be obtained in "Resources" section.

Resources. It contains a list of available resources into the federation. Important detailed information about each resource can be found:

• Organisation: Organisation owner of the resource. • URL: Web link to the resource. The home link if it is a web resource or service, and the launch

link if it is a JWS application. • Description: Short description about the resource. • Client: Type of client application required. Usually web browser or JAVA application. • Required attributes: List and description of attributes that has to be provided for accessing to this

resource.

Software. In this section updated necessary software is distributed, installation and configuration instructions are provided, and specific pieces of code and examples are shown for being used into client applications into EFDA federation.

Technology. In this section a general vision of the base technology used into the federation is shown. Currently, this section it is focused in the application of PAPI technology into the federation.

Documentation. Repository of documents, presentations, manuals and web links related with the federation and the different used technologies.

WAYF. "Where Are You From" service. This is a implementation of the service based on a list of web links to the registered authentication servers into the federation. This is a very typical service into any federation and it is used to identify the home organisation of a user, and then being authenticated.

2.3 Some examples of federated resources Web File System: Web File System for organisations belonging to EFDA Federation. It allows users

to manage a personal file system, to share personal folders, to send temporal links into mails, and to use the folder of his organisation. This service works with standard browsers and it is located at CIEMAT

EFDA wiki: Wiki service for remote participation groups belonging to EFDA. This service works with standard browsers and is located at CEA.

Visual SimilarWave: Visual tool for searching signals based on similar shape techniques. With this tool, you can visualize a signal and search for signals with similar shape. The result of the search will be a set of signals ordered by a similarity coefficient. This resource works with Java Web Start application and it is located at CIEMA.

TJ2 Signals Configuration: Application for monitoring the configuration of data acquisition signals for TJ2. This service works with standard browsers and is located at CIEMAT.

6th IAEA TM 2007 (Inuyama - Japan): Web page of 6th IAEA Technical Meeting on Control, Data Acquisition, and Remote Participation for Fusion Research that took place in Inuyama (Japan) in June 2007. From this it is possible to access to restricted resources such as electronic proceedings and presentations (audio, tv, and slides). This resource works with standard web browsers and it is provided by CIEMAT and located in IAEA.

3 Authentication and Authorization Infrastructure The most important element for starting up a federation is the authentication and authorization

infrastructure (AAI). In the case of EFDA federation, the AAI is currently implemented using PAPI. This situation doesn't exclude the integration of other technologies and technical solutions for getting compatibility among different technologies. From a first stage, PAPI and Shibbolethv were evaluated as real candidates for EFDA federation. In a first point, a short comparative between PAPI and Shibboleth is presented, showing the main reasons why PAPI was chosen. In the following points, different technical aspects related with the PAPI infrastructure that implements EFDA federation are presented. I am not going to give detailed information about elements and protocols of PAPIvi and Shibbolethvii, because they are very documented.

3.1 PAPI and Shibboleth There are many facilities that are common to PAPI and Shibboleth and make them available to

support a federation model, such as: • Both include mechanisms to identify different elements into the federation and they manage the

concept of user identity, which allows identifying users in any element of the federation. • Both are designed to work in a single sing on model. • Both are able to keep the users privacy in the resource accesses, because they manage dynamic

numeric handlers that anonyms users. Although, if it was necessary, it would be possible, joining logs from authentication and authorisation, to identify the user who did an action.

• Both solutions are valid for mobile users because their access control mechanisms are independent from IP source addresses.

• Both implement access control systems with rules that are based on user information (attributes), which enables resource and service owners to configure complex access rules.

• Both implement session management mechanisms based on encrypted cookies. • Both are compatible with main web browsers: MS IExplorer, Mozilla, Safari and Opera. • Both are compatible with web servers and application servers based on HTTP and HTTPs

protocols.

Apart from described similarities there are some important differences: User identity management: In the case of Shibboleth the identity of a user who tries to access to a

resource is requested by the remote site (owner of the resource) HS element to the SHIRE element in the home site of the user. It is a pure pull model. In the case of PAPI, the user identity is distributed after a successful authentication to GPoAs (Group Points of Access) elements. These elements can be hierarchically related and they are able to redistribute user identities when these are requested by other elements in the hierarchy. It is mixed push-pull model. In the case of shibboleth, the HS elements must know the SHIRE elements of the other organisations. In the case of PAPI, the possibility of configuring hierarchical relations among their elements simplifies management tasks into the federation. A central GPoA for all the federation or a GPoA for each organisation can be configured, and then new resource can be included with only a small modification in its local GPoA configuration, at organisation, laboratory, department or even server level.

Message protocols: The first one uses its own protocol of REST type. In this case the messages are built using URL parameters as fields. In the case of Shibboleth it uses an adapted SAML protocol, which works with XML structured messages. Due to these differences in the protocols, the redirection mechanisms of both systems are also different. In the case of PAPI uses GET style redirections, while Shibboleth uses POST style redirections. The advantage of Shibboleth is that its protocol is more standard; on the contrary the redirection mechanism is not supported in a native way by HTTP libraries, so the integration of applications is more difficult.

Trust infrastructure: Shibboleth needs to have, whether an operative PKI (Public Key Infrastructure) with a CA (certification authority), whether a central certificate repository, because any element of the federation have to be able pass messages to any other element, so in the first case both have a common root CA, in the second case a trusted repository of certificates to check is needed. In the case of PAPI the trust is based on public key technology but instead of using a CA or a central certificates repository, only some public key file exchange is needed, because the elements of the federation are organized in a hierarchical way, so each of them only have to communicate with its father or with their sons. In the same way, if a public key is compromised, only generating new pair of keys and redistributing the new public key among their peers and sons it is enough. No revocation lists are needed.

Attributes management: This information about users is used for the evaluation of access control rules to decide if a user has access to a resource. Shibboleth implements a pull mechanism, where the remote organisation (owner of the service) request for needed user attributes to the home organisation of the user. On the other hand, PAPI has the possibility of distributing attributes to GPoAs after a successful authentication (push mechanism), but it is also possible for a PoA (element which controls the access to resources in PAPI) to require attributes to a GPoA (pull mechanism). In the case of Shibboleth the request is made by direct connection between SHARE element (in the remote organisation) and the AA element (in the home organisation), so some firewall problems can appear. In the case of PAPI the communications are done using client redirections so firewall filter problems are avoided.

Supported clients: PAPI and Shibboleth are compatible with common web browsers. Additionally, when PAPI and Shibboleth alternatives were evaluated, PAPI was running on JAVA applications that were running in TJII, and then it was compatible with some important HTTP JAVA libraries. Currently, some important improvements in PAPI have gotten to do PAPI compatible with standard JAVA 1.5 and above HTTP libraries. More detailed information about it is presented in point 4.1.

At the end PAPI was used as AAI in EFDA federation. The main reasons for this decision were: • Easy management: PAPI requires simpler trust infrastructure, new services only requires local

configuration, and "PAPI proxy" element can work as a service front-end, and it can be installed as a application level firewall, which enable access control to services without modifying their configuration.

• JAVA applications support: This is due to PAPI implements simpler redirection mechanism and because it supports hierarchical organisation.

• Simple trust infrastructure: PAPI doesn't require a PKI with a CA for running. • Real experience of PAPI, since 2003, as security infrastructure for accessing data acquisition

services of TJ-IIviii fusion machine, located in EURATOM/CIEMAT laboratory.

3.2 PAPI structure into EFDA federation The elements of a PAPI system can be organized in a hierarchical way, and the way in which the

elements of the system are structured will define the flow of user identities through the federation, it will define the trust relations between peers or branches in the resultant tree, and of course it will define the management model of resources, authentication services and organisations. From the access control point

of view, a GPoA manages enough user information and credentials to access to all resources under this GPoA. In few words, a GPoA manages its own identity card, which is valid for all delegated resources.

In the case of EFDA federation there were two alternatives which are completely valid, but with important management differences. The first alternative consists on installing an organisational GPoA in each organisation and defining peer-to-peer relations between authentication servers (usually one per organisation) and all organisation level GPoAs. In this case, when a user is authenticated, he gets credentials from all the organisational GPoAs. The second alternative consists in a unique GPoA for all the federation, and then, any kind of GPoA or resource can be located under it as can be seen in Fig. 3. In this second alternative, when a user is authenticated, he gets credentials from only the federation GPoA. It is a kind of one identity card for all the federation.

Fig. 3 Diagram that represents the PAPI hierarchical structure of EFDA federation

The first alternative has important advantages. The first one is that no federation GPoA infrastructure

is needed being installed and managed, and the second advantage is that is less critical for failure. The second alternative, presents one important advantage that is the flexibility of the solution and its easy of management. In the first alternative, if a new organisation is included into the federation, a new GPoA would have to be configured in every authentication server of the federation. In the same way, every organisation GPoA would have to be configured with the new authentication server of the new organisation. In the second alternative, if a new organisation is included into the federation, only the federation GPoA has to be updated with the authentication server of the new organisation. As I have mentioned previously, no revocation list is necessary in this model.

The easy of management had more weight in the final decision, and the second model was installed. In both models, the inclusion of new resources only affect at the local configuration of the closer GPoA (server, department, organisation, etc).

Close to the federation GPoA and as part of central federation services, there is a WAYF service, which enable to an user who is unknown for the federation, to specify what is his home organisation, and consequently, what is the authentication server enabled to identify him into the federation. This service is currently implemented as a list of web links; each of them corresponds to the web link of a federated authentication server.

3.3 Organisation level architecture For simplify the installation of PAPI in federated organisations, PAPI proxy was used as kind central

access control system or a type of application level firewall. Thanks to this configuration, PAPI only has to be installed ones, and the organisation centralises access control policies to the different resources in just one point. Other advantage is that no service has to be reinstalled or reconfigured; if a new service of a organisation is included into the federation, only few configuration lines has to be added in the configuration of its PAPI proxy service. Thanks to the hierarchical structure of the federation, the process of including a new resource is really simple.

From the point of view of the authentication server, many plug-ins for connecting with different type of repositories are developed for PAPI. Additionally, thanks to authentication server templates, web interface related with authentication can be easily adapted to local web design.

3.4 Federation way of work Supposing a not authenticated user, if he tries to access to a federated resource has two ways to do it.

In the first one, the user tries to access directly to the federated resource, whether using resources web repository of the federation central repository, whether using other link. In the case this user was denied, as can be seen in the Fig 4, he would be redirected to corresponding GPoA until the user is redirected to the federation GPoA . As this GPoA is not going to know the user, he is going to be redirected to the WAYF service that will decide which is the home organisation of the user, redirecting him to the authentication server of its home organisation. Ones successfully authenticated, the user stores federation credentials, and he is automatically redirected to the first resource he tried to access, for the requested being completed in a transparent way. Successive access to federated resources will be solved in one of the corresponding GPoAs to that resource. In a final case, the user would be redirected to the federation GPoA that will identify the user, and he will be transparently redirected to the resources he was trying to access.

Fig. 4 Sequential diagram of a typical unauthenticated access to a resource in EFDA federation

4 New PAPI technologies As result of the adaptation of PAPI to EFDA federation requirements, new technical solutions have

been developed. In this point the two most important ones are described.

4.1 JAVA PAPI Runner This solution is the evolution of previous adaptation of some common JAVA HTTP libraries to PAPI

until getting a solution which enable PAPI compatibility to compiled JAVA applications without modifying or recompiling their code. In a first stage, JAVA standard HTTP library didn't support neither cookies, neither redirections, so alternative libraries with these skills where adapted for implementing HTTP connections in JAVA applications. The libraries adapted in this first stage were Ronald Tschalär HTTPClientix (RT-HTTPClient) library and Jakarta commons-httpclientx library. As an added value, ones adapted Jakarta commons-httpclient almost projects developed into Jakarta project were automatically

PAPI compatible. For example, Apache XML-RPCxi libraries, and by extension, all applications implemented using this technology.

The modifications did in the libraries are described next. In the case of RT-HTTPClient library, it keeps in local memory cookies until the JAVA application, which is using it, is closed. This is not compatible with the way of sharing GPoA credentials among different applications that access to resources that depend on the same GPoA. In other, words different applications need to use GPoA credential, but both keep on their local memory different copies of the credential. In PAPI, this means invalid copy of the credential and collision. In the case of common-httpclient, the cookies were managed only in local memory, so there wasn't any way of sharing credentials among JAVA applications. The solution, in bough cases (their classes structure is quite similar), was to modify their CookieModule class, modifying the way this module store cookies. The new class, as can be seen in Fig. 5, stores cookies in a local Berkeley's database, which is implemented using Oracle implementation of JAVA Berkeley databasexii.

Fig. 5 Simplified schema of the important classes in the adapted HTTP JAVA libraries

From version 1.5, standard JAVA HTTP implementation supports redirections (with some important errors) and CookieManager for cookie storage implementations. At the end, a unique core of classes has been developed for managing a unique cookie format and using the same repository. The commented libraries have been adapted to work with this repository, and distributions of them can be found in "Software" section of EFDA federation web zone.

A quick first approximation can be used to force, in a transparent way, a JAVA application to work with modified libraries. This is done by adding to java application call the execution property "-Djava.protocol.handler.pkgs=HTTPClient". The java virtual machine will change on running time the standard java http library by the especified in the property. The problem using this method is that JWS environment disable this property and it is no possibility for changing HTTP library just using execution parameters.

The final solution has been the development of a runner. Basically, this runner gets "Resources" property, as can be shown in the example JNLP file shown in Fig. 6, which can be defined in the execution environment (command or JWS). This property has a list of URLs of PAPI protected resources that are going to be used by the application. The runner resolves credentials loading for each of the URLs, then loads dynamically the CookieManager class compatible with PAPI and with standard JAVA HTTP client library, then registers the loaded CookieHandler as the default one, and finally runs the main application with their parameters, which correspond to arguments in the JNLP file. In the example showed in Fig 6, the main class and its arguments corresponds with arguments of the application to be launched with the JNLP file. In theory, previous credentials loading shouldn't be necessary because it should be able to be done dynamically the first time resources are accessed but redirection mechanism implemented, until now, in the standard HTTP library doesn't work properly; HTTP redirections doesn't manage cookies. Of course, source code and compiled JARs can be found in the "Software" section of EFDA federation web zone.

Fig. 6 Example JNLP file for JAVA PAPI Runner

4.2 New logout mechanism The way of working of distributed authentication and authorisation systems, and more specifically,

the mechanisms used by these systems for keeping sessions (usually encrypted cookies), does very difficult to implement a logout mechanism. A typical scenario is a web browser, which after a successful authentication, has been accessing to different protected resources. This browser would keep stored valid cookies for accessing to almost those resources. If the user logout in a specific web link or button, there is no way (for security reasons) of deleting those valid credentials, so the logout is not effective until the browser is exited. This strange effect gives bad feeling to users. In EFDA federation temporary valid cookies are used for keeping sessions. That means that short expiration times can be defined. The mechanism is described following:

1. Session cookie of the resource is automatically renewed using PAPI cookie rotation mechanism if the resource is accessed in a continuous way.

2. If the resource is accessed after a expiration time, the session cookie can't be rotated, and client is redirected to the corresponding GPoA for renewing.

3. If GPoA validates its session cookies (GPoAs keeps session cookies in the same way as PoAs), these are rotated and client is OK redirected to original resource and new session cookies are generated.

4. If GPoA doesn't validate its session cookies, redirect client to its GPoA, and process is repeated following the hierarchy.

5. Only GPoAs registered in Authentication Servers generate session cookies that don't expire. So only a logout process or a browser exit can close the session. On the contrary, if the authentication server processes a logout, the session cookies of registered GPoAs are deleted.

This new logout mechanism produces good feeling on users because they are able to close the sessions. In the case of JAVA applications this problem doesn't exist because the processes of loading and

deleting credentials are done using specific JAVA code with total control over the cookies repository.

5 Conclusions Since the summer of 2007, it is running the project for the development and installation of a stable

federation infrastructure among EFDA fusion laboratories. There are currently six fusion laboratories involved into the federation: CIEMAT (Spain), CEA (France), JETxiii (UK), IST (Portugal), HAS-KFKI (Hungry) and EFDA (Europe). All of them have PAPI as authentication and authorisation infrastructure, and all of them are using PAPI proxy as access control front-end to their resources. Since the federation start up, a set interesting resources have been integrated, since central services as the wiki site or the web

file system, passing through new prototypes of data analysing tools based on new data access paradigms, until community interesting resources located outside the federation and offered through the federation, and integrating video. Thanks to real environment working, some important technical solutions have been developed and can be a very important base for extending these functionalities to other systems such as Shibboleth, enabling the integration of other type of client tools.

PAPI has demonstrated in TJII acquisition systems its validity as technology for providing secure access to services and web resources, and it is currently a stable technology for providing and extending services into the federation. In fusion community, there are many services that currently demand federated solutions, above all considering the multi-organisations working groups that are currently working on different tasks and that require repositories and coordination tools with secure access. With a similar philosophy, ITER is designed with the idea of being a fusion centre open to researchers from different countries and laboratories, and EFDA federation is being a perfect testing environment for this type of technologies.

6 References

[i] "European Fusion Development Agreement". http://www.efda.org

[ii] "International Thermonuclear Experimental Reactor". http://www.iter.org

[iii] "JAVA Web Start Technology". http://java.sun.com/products/javawebstart/index.jsp

[iv] J. Vega, E. Sánchez, A. Portas, et al. " Overview of the TJ-II remote participation system". Fusion

Engineering and Design, Volume 81, Issues 15-17, July 2006, Pages 2045-2050.

[v] Mark Needleman. "The Shibboleth Authentication/Authorization System". Serials Review, Volume

30, Issue 3, 2004, Pages 252-253.

[vi] "PAPI home page". http://papi.rediris.es

[vii] "Shibboleth Internet2 Proyect". http://shibboleth.internet2.edu/

[viii] R. Castro, D.R. López and J. Vega. "An authentication and authorization infrastructure: The PAPI

system". Fusion Engineering and Design, Volume 81, Issues 15-17, July 2006, Pages 2057-2061.

[ix] "HTTPClient Library". http://www.innovation.ch/java/HTTPClient/

[x] "Jakerta commons-httpclient library". http://jakarta.apache.org/commons/httpclient/

[xi] "XML-RPC implementation" Apache project. http://ws.apache.org/xmlrpc/

[xii] "Berkeley DB". http://www.oracle.com/technology/products/berkeley-db/db/index.html

[xiii] "Joint European Torus". http://www.jet.efda.org/