Yagsi: Yet Another Generic Security Infrastructure
Contents
Motivation and Use Case
One major reason for the lack of acceptance of Computational Grids in the industry are security concerns. Conventional Grid security architectures, such as GSI (
Globus Toolkit), focus on the service provider’s perspective and do not cover all concerns of the service user. For instance the management of user credentials is delegated to services which are not under full control of the user (e.g. MyProxy). Another drawback is that common Grid security systems do not cover the fine-grained authorization of services, taking into account the methods, their parameters, and the message flow in deciding whether a user or another service is authorized to access the service. This is particularly important for Grid workflow systems.
Therfore we developed a new Grid security architecture, called Yagsi. It uses fine-grained and role-based security mechanisms in combination with restricted delegation of privileges, in order to overcome the drawbacks of current implementations.
Fig. 1: Typical use case from the movie production industry that shows two roles, a portal and different web services.In order to illustrate security needs we choose a typical use case from the
movie production industry. Figure 1 shows two different roles,
simplified from a media VO: A freelancer who's job is to perform post
production on images with reduced resolution and a movie production manager
keeping control of the whole process. Beside a portal and a workflow service
there exists a movie archive service managing access to confidential movie
data. Depending on the role it makes restrictions on the scene and the
resolution of the images going to be checked out. Additionally there exists a
RenderMan service which can be used directly by company internal users,
whereas freelancers have to make their request through an accounting service.
Architecture
The design of the new security architecture provides a simple and convenient
integration of legacy Web Services. The fundamental idea of the Yagsi concept is the use of security components which are surrounding a Web Service and which perform authentication and authorization related tasks. In connection with the authorization a security token is used, which is generated on the side of the Grid-user, integrated into the message flow and signed on each delegation
step. The resulting trace of intermediate station may incorporate into the authorization decision. Additionally this token is presented to the Grid-User on a query for further credentials.
Fig. 2: Overview of the Yagsi Architecture which shows the User Keystore Service (UKS) and the security components PreSec, PostSec and TokenSec. Bold lines represent a secured SOAP communication. Dashed lines represent thread interaction.Figure 2 gives an brief overview of the Yagsi security
infrastructure. We use security components to protect web services and we
provide a User Keystore Service (UKS) for managing user credentials. The
WS-Security standard is applied to secure every communication between these
components on the message layer. Special of the Yagsi approach is the use of
security tokens which are attached to the SOAP messages and which are passed
through all intermediate stations.
Fig. 3: Exemplified structure of the Yagsi security token after its creation by the User Keystore Service and its passage through a Portal and a Web Service.A security token contains the user certificate and additional information
such as an ID, a Uniform Resource Identifier of the User Keystore Service and
attributes limiting the life time. Figure 3 illustrates a token
that is initially signed by the private key of the user. When it travels
through intermediate stations each station attaches its certificate and its
signature.
The concept of a security token is essential for various reasons. From the
service providers point of view it allows to perform an authorization
decision based on the user querying a resource, even if the request was
delegated by several intermediate stations. By collecting a trace of
intermediates it enables the provider to restrict access based on the
communication path. Finally it carries information from which entity user
credentials can be obtained.
Considering the users perspective the token is an instrument to place
restrictions regarding the lifetime of a request. Also it enables the user to
verify whether a request for credentials was triggered by a former query of
himself.
Documentation
Download and Contact
Please contact
andreas.hoheisel@first.fraunhofer.de if you would like to download and evaluate the software or if you have further questions.
Paper at the Cracow Grid Workshop 06 (pdf)
BPMN
b_bprimal