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).

Deployment Diagram

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:

Generic workflow Diagram


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:

The following diagram shows us the typical workflow for this case:

Automated Client workflow Diagram


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:

User behind a Client workflow Diagram


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:

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.

Client in a Web container workflow Diagram

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:

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:

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:

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:

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.

Workflow from a point of view of a pSR

At this time, there are some Authentication Services available:

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):

Personal tools