Authentication Service resources
From GEANT2-JRA1 Wiki
Contents |
Authentication and authorization Service
The Authentication and authorization Service (AS), shortly Authentication Service, is a perfSONAR service which provides authentication (AuthN) and authorization (authR) mechanisms for other perfSONAR services.
This service interacts with the eduGAIN infrastructure acting as a proxy between the user's Identity Provider and attribute store (accessible through the H-BE) and the perfSONAR services that provide resources (pSR). The AS interfaces with the H-BE through an eduGAIN interface, and is called Remote Bridging Element (R-BE).
perfSONAR services would use AS to get:
- Authentication of the client/user, who has sent the message to them.
- Authorization for the received message.
When a client sends a message to a service, this must decide if it is needed to authenticate the client/user or to authorize the received message. In both cases, the following diagram shows a generic workflow:
In this flow, perfSONAR services don't understand anything about authentication or authorization process. They only request to AS an authN or authR for the received message. The information needed by the AS for evaluating the received request is got through security tokens. At this time, due to interactions between perfSONAR components are based on SOAP 1.1, the Web Services Security using SOAP 1.1 is used for sending security tokens between clients and services, and, services and AS.
Also, it is recommended for developers to read the security considerations.
Messages
perfSONAR services can send the following messages to the AuthService:
If you need to know which error codes AS could send in messages, there is a list containing a useful description.
Download
The last release of the AS is 1.0. You can download it (or a previous release) here and there is an small document about how to install it.
Testing
There is a web page with useful information about the testing process of this service.
perfSONAR scenaries
In a perfSONAR environment, it has been identified three different scenaries:
- Automated Client (AC)
- User behind a Client (UbC)
- Client in Web containEr (WE)
Automated Client
In this case, the client has no direct interaction with a user or human. A typical example is a PERL o PHP script.
Clients must send a valid X.509 certificate in eduGAIN trust model to pSR when these need to authenticate them for processing their messages. In this way, clients must follow the X.509 token profile of the Web Services Security specification and developers can access to the following documentation:
- Specification of an interaction between an AC and a pSR following the X.509 token profile.
- Example of an AC using WS-SEC, developed in Java code.
- Example of an AC using the authentication library, developed in Java code.
- How to request a certificate in a eduGAIN sub-CA.
The following diagram shows us the typical workflow for this case:
User behind a Client
These clients are non Web Services (WS) entities acting directly upon requests coming from end users that they don't have Web redirect capabilities. An example is perfSONAR-UI that contacts several Measurement Archives to fetch data to be displayed to the user through a GUI.
The requirements of this case are very similar of the previous case. The main difference is this kind of clients must send a user's X.509 certificate which is obtained from his Identity Provider (IdP), a Home Bridge Element, through SASL. In the following diagram we see a typical workflow:
As we can see, when a user request any action to the client, this must authenticate him in a IdP of his domain. So, the client does some interactions with the Metadata Service (through a MDLookup message) of eduGAIN for getting to which organization he belongs to. When this information is obtained by the client, this has to get the user's credentials and certificate from his IdP through SASL protocol.
Developers which are in this scenary can read the following documentation:
- Specification of an interaction between an UbC and a pSR following the X.509 token profile.
- How to request a certificate in a eduGAIN sub-CA.
- Example of an interaction with the Metadata service in eduGAIN
- How to get a certificate from a SASL CA server
- Example of an AC using the authentication library, developed in Java code. At the moment a certificate is got from a SASL CA server, you have to send it in the same way as AC do.
SASL CA
There is a custom version of SASL-CA ready for use it with perfSONAR. You can download it or read how to install it.
Client in Web containEr
Basically, this clients within a Web container, that are web applications such as servlets or PHP scripts, can use its container to redirect users to their H-BE and make them authenticate there using their local federation procedures. This procedure is accomplished using the eduGAIN WebSSO profile.
Following the eduGAIN WebSSO profile, clients obtain user's assertion and use it as security token that is sent implementing the SAML Token profile of the Web Services Security specification. Developers of clients within a Web container can read the following documentation:
- eduGAIN WebSSO profile.
- Specification of an interaction between an WE and a pSR following the SAML token profile.
- Example of an WE using WS-SEC, developed in Java code.
There are some components or modules for protecting the web application, which implements the eduGAIN WebSSO profile, that it's needed to deploy in the container:
- Java-based
- Filter for Tomcat
WARNING!
There is an unsolved problem between Axis 1 library, OpenSAML library and XML signatures, and SAML assertions obtained from eduGAIN infrastructure cannot be validated. As perfSONAR Java services are using Axis 1 (AS included) it has been made a workaround until it could be change to another SOAP library.
The SAML assertion is sent using the X.509 Token profile of the Web Services Security standard using the pair of private and public keys and encapsulating into a binary security token. Developers must read the following links:
- Building the valid SAML assertion.
- Specification of an interaction between an WE and a pSR following the X.509 token profile.
ATTENTION: Developers who are using authN libraries and classes provided by perfSONAR base don't have to modify their code, but they SHOULD use perfSONAR-base or perfSONAR-base-ac_authn >= 20080114.
Implementing Authentication (AuthN)
As it said before, Web Services Security specification from OASIS is used for sending the information needed to obtain authentication of the client/user. This standard specifies that security tokens are included in the SOAP header. There are two different security tokens in perfSONAR environment:
- X.509 certificate, valid in eduGAIN trust model. At this time, an X.509 certificate is valid if it's issued by the eduGAIN root Certificate Authority (CA) or by one of the subordinate CAs defined in the eduGAIN trust model. Also, this and the associated certificate validation libraries (eduGAINval) are open to the introduction of CAs that are not subordinate to eduGAIN's root CA. This is implemented in perfSONAR using an specific case of the X.509 token profile of WS-SEC, so you must read how it's used this profile in perfSONAR.
- SAML assertion, issued by a H-BE in eduGAIN trust zone. This is implemented in perfSONAR using an specific case of the SAML Token profile of WS-SEC, so you must read how it's used this profile in perfSONAR.
perfSONAR clients must identify which scenario it belongs to.
perfSONAR services (pSR) can request an authentication to the AS at the time they need it, so there could be some actions in a pSR which need to be authenticated and some which don't. Services can do it in two ways:
- Programatically, using a set of classes that are located in the perfSONAR base.
- Using the Authentication Component.
From a point of view of a pSR, services don't have multiple scenarios but they only receive requests with a Security token, no matter which kind of token is.
At this time, there are some Authentication Services available:
- For testing purpose: http://homer.rediris.es:8080/perfSONAR-AS/services/AuthService
Implementing Authorization (AuthR)
Authorization mechanisms are going to be available by first quarter of 2008, so there is no much information on this topic.
Roadmap
The roadmap planned for Authentication and authorization Service and all its libraries is:
- AS
- First release is planned for late May of 2007. This version only supports Authentication (AuthN) mechanisms.
- Second release is planned for first quarter of 2008. This version supports both mechanisms: Authentication (AuthN) and Authorization (AuthR).
- Java Libraries for pSR developers
- First release is planned for middle April of 2007. This version only supports Authentication (AuthN) mechanisms.
- Second release is planned for first quarter of 2008. This version supports both mechanisms: Authentication (AuthN) and Authorization (AuthR).
- Java Libraries for client developers
- First release is planned for end of 2007.
Useful links
These are useful links around Authentication and authorization Service (AS):
- AS documents
- DJ124 "perfSONAR AA service specification"
- Meetings
- perfSONAR developers meeting (6th Technical Workshop GN2), Berlin (more or less) (GE), 23th-25th June of 2008
- perfSONAR developers meeting, Zagreb (HR), 7th-9th April of 2008
- JRA1 meeting, Seville (ES), 30th-31th October of 2007
- JRA1 meeting, Cambridge (UK), 7th-8th June of 2007
- perfSONAR developers meeting, 1st-4th May of 2007
- JRA1 meeting, Utrech (NL), 28th-29th March of 2007
- JRA1 and JRA5 held a joint meeting at the Cambridge Jan. 2006 GEANT2 workshop - Minutes here
- Implementations notes
- Old Stuff






