Designing a security architecture that manages all the security workflows is a problem that all projects related to GRID infrastructure, sooner or later, will have to face. For this reason, OASIS  proposes a specification to solve all the steps necessary to setup and manage an AAI (Authentication Authorization Infrastructure) architecture. Mainly, this solution that we presented is formed by:
- WS-Security . The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as SAML , Kerberos , and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.
- WS-Trust . This specification provides extensions to WS-Security, specifically dealing with the issuing, renewing, and validating of security tokens, as well as with ways to establish, assess the presence of, and broker trust relationships between participants in a secure message exchange.
Each specification deals with different issues to set up this AAI architecture. As a practical use case, we can explain a use case of the Mantychore FP7 project  (It could be generic for the most projects which need a GRID infrastructure with security). The use case has three main roles:
- End user or client (C). It is a client which sends requests to a web service (WS) (In this case Service provider).
- Service Provider (SP). It is a server which contains web services to be accessed from end users.
- Security Token Service (STS). It contains a credential repository. This server will send security tokens to implement the authentication process.
In this picture is possible to see how a client (for example, an application) sends a request to the Service Provider (SP). In this point, the WS-Security is the responsible to guarantee the secure communication among web services, it specifies a protocol that encrypts and signs the messages to provide a secure end-to-end communication.
Then, SP gets the client’s certificate which it will use to get a token from STS. This token (from the WS-Trust specification) provides a set of parameters for a resource (institution, interval of time, owner, resources id…), which the SP uses to apply the necessary policies (WS-Policy ). In this case, WS-Trust specifies this infrastructure where the STS provide tokens to ensure a correct authentication process among the Client and the Service Provider. WS-Security alone is not enough to guarantee a successful authentication between consumers and providers.
In addition, in more complex scenarios, the WS-Security specification can be insufficient. Because of these problems, Mantychore FP7 creates an infrastructure which will use the WS-Trust to create scenarios with multiple provides or resources where the tokens will provide authentication to each resource in the domain.
Apache Axis2 and Apache CXF, two of the most popular Java solutions for web services, support these specifications:
|Web Services Security||X(1)||X(4)|
Table 2: Support for WS-* Standards ( as of August 2010)
(1) Supported by the additional module Apache Rampart
(2) Supported by the additional module Apache Kandula2
(3) Supported by the additional module Apache Sandesha2
(4) By Apache WSS4J
Furthermore, it exists a set of solutions for implementing an STS that stores user credentials and creates the necessary tokens for the authentication process. For instance, Spring Security , Shibboleth  and OpenSSO .