The IdM system is designed to reduce as much as possible the end-user intervention.
Figure 6 shows that the end user is initially authenticated by the network (and authorized to access it), then the request passes through the UA and SA within the OpVO domain (the behaviour is similar in the BVO) that authorizes the end-user to use the requested service, finally, the request is forwarded to the actual services in the SP domain that will authorize the OpVO/BVO to access their internal resources in order to satisfy the end user request.
The following subsections will explain in more detail how the different components interact to accomplish the end-to-end communications.
Access to the network
Network access is the first task than is performed in the Akogrimo bootstrap process. During this phase, the user is authenticated by the AAA Server of his ‘home’ domain and an ID token is issued. The authentication performed during network login is based on a username and password and is encapsulated in EAP (Extensible Authentication Protocol) (EAP 1998). For the transport between the mobile end-system and the network authentication server, PANA (PANA 2008) is used. For the transport between the network authentication server and the AAA server, the Diameter protocol is used. The following figure shows the network access procedure in detail (Fig. 7).
The mobile terminal (MT) acts as a PANA Client that communicates with the Access Router (AR) via the PANA protocol. The AR communicates with the A4C server via the Diameter protocol. The communication starts with the PANA-PAA-Discover message sent by the MT to find available ARs. The AR sends a PANA-Start-Request containing information about the network provider. In turn, the MT selects a network provider from the list and sends its selection back to the AR in the PANA-Start-Answer.
The AR forwards the user’s identity to the A4C server in the Diameter-EAP-Request (DEAR) message. The A4C server replies with a Diameter-EAP-Answer (DEA). The challenge is forwarded to the MT in the PANA-Auth-Request. The MT replies to the challenge in the PANA-Auth-Request. The AR forwards the message with the answer to the challenge to the A4C server, which verifies the identity of the user.
If the authentication is successful, the A4C server requests the generation of an IDToken from the SAML Authority. Then, the A4C Server sends the IDToken, the user’s public identities and VO parameters to the AR encapsulated in the DEA. The information is forwarded to the MT that finally replies with a PANA-Bind-Answer, which closes the authentication process.
Access to the MDVO
Figure 8 shows the AA process related to the invocation of a UA instance.
The SOAP Filter (SF) receives the incoming SOAP message (SM) and parses it to extract the SAMLID token and the claimed digital identity (1). These parameters are passed to the VOM (2).
Then, the VOM asks (3) the A4C within the OpVO domain to authenticate the identity. This is done checking the signature of SAMLID token and invoking the trusted A4C server to check the validity of the issued token.
The response (6) of this validation authenticates the principal identity of the user and guarantees that this user is the owner of the claimed digital identity (notice that there is a one-to-many relation between principal identity and digital identity).
The VOM retrieves (11) the profile associated with this identity from the PR and uses such a profile to receive (13) from the Policy Manager the policies (defined using WS-Policy specifications) to be applied for authorizing the request.
According to the decision taken (15) by the VOM, the SF allows the request to be processed by the UA instance (19) or blocks it (18).
Figure 9 shows the AA process between two generic services inside the VO. These interactions are still valid if the generic services are replaced by UA and SA. On creation, these services are associated with a VO token signed by VOM. It is assumed that VOService1 invokes Method() on VOService2.
Figure 9 highlights that the authorization sequence is similar to that shown in Fig. 8, the only difference being the authentication process (2). In fact, in this case, the A4C server is not involved because communications are among entities within the same VO domain and the VOM operates as a certification authority that issues the credentials to be conveyed by the requestors in their messages to be authenticated.
Invoking a service
For the development of the SAs and the SP’s Grid Services, two of the most popular platforms in the development of Grid Services were used: GT4 and WSRF.NET (WSRF.NET 2006), both of which are a full implementation of WSRF specifications.
The SA was a WSRF.NET client to the EMS Core service that acted as a gateway service in front of the SP Infrastructure and their communications were made using SOAP over the HTTP protocol. In order to establish secure SOAP communications between the SA and the SP domain, WSRF was linked to the WS-Security specifications and GT4’s Security Infrastructure (GSI) was plugged into the Akogrimo security mechanisms.
Authentication
In more detail, the security header of the SOAP request coming from the SAs contained an SAML security token. This SAML token was presented to the EMS Core service. Next, the authentication decision was delegated to the A4C Server that in turn contacted an OGSA-compliant SAML server.
Authorization
Having authenticated against the SAML server, the EMS Core service checked the request against its gridMap. If the SA was listed in the gridMap, i.e. the SA was mapped to an account; the EMS Core Service proceeded with the invocation of the specific EMS sub-service. As already explained, the gridMap is used as an access control list. In more detail, during the reservation of the required resources, a persistent WS-Resource was created after each successful reservation inside which all the information that is needed in order to execute the reserved services was stored. For each reservation, an entry was added in the EMS sub-service’s gridMap specifying the SA and the WS-resource that corresponded to the reservation. Upon receiving an execution request by an SA, the EMS sub-service checked its own gridMap in order to check if the client that is behind the SA is allowed to access the specific resources in the SP domain. In this way, all EMS services made sure that only the client, who had negotiated and reserved the resources, could actually access them. By doing so, other authenticated clients were prevented from tampering with another client’s reserved resources.
It should be noted that the usage and maintenance of gridMap files entries does not scale very well as the number of clients increases. In this direction, the EMS services were able to easily expand onto other nodes in the SP domain to accommodate the increased number of clients. In more detail, when the number of entries in the gridMap file of an EMS service exceeded a threshold, the EMS service was able to delegate its request to another available instance of the same EMS service running on another node or server with fewer clients.
The steps required to invoke a service in terms of authentication-authorization of the SA against the SP domain are depicted in the following sequence diagram (Fig. 10).