1 Yagsi: Yet Another Generic Security Infrastructure 1.1 Contents {snip-tree:Yagsi} 1.1 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. {image:yagsi-use-case.png} __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. 1.1 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. {image:yagsi.png} __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. {image:yagsi-sectoken.png} __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. 1.1 Documentation - {link:Paper at the Cracow Grid Workshop 06 (pdf)|space/Yagsi/Hoheisel_and_Mueller_et_al_2006_YAGSI-paper.pdf} - {link:Presentation at the Cracow Grid Workshop 06 (pdf)|space/Yagsi/Hoheisel_and_Mueller_et_al_2006_YAGSI-lecture.pdf} - {link:Diploma Thesis (pdf - in German)|space/Yagsi/Mueller_2007_YAGSI-diploma.pdf} 1.1 Download and Contact Please contact {mailto:oleh.khovalko@first.fraunhofer.de} if you would like to download and evaluate the software or if you have further questions. 2011-07-21 11:36:44.0 2007-06-24 15:41:32.92 Hoheisel_and_Mueller_et_al_2006_YAGSI-lecture.pdf Thu Jul 05 14:01:05 UTC 2007 Hoheisel_and_Mueller_et_al_2006_YAGSI-paper.pdf Thu Jul 05 13:59:56 UTC 2007 Thu Jul 05 13:53:04 UTC 2007 Thu Jul 05 14:18:17 UTC 2007 Thu Jul 05 14:18:10 UTC 2007 Thu Jul 05 14:18:00 UTC 2007