Hi, > Thanks for such useful information............ > I just went through one of your post in which you had said that you are > trying to develop an AAI for D-Grid that leverage both, Campus > Attributes from a GridShib and VO Attributes from VOMS.
The idea to develop an AAI for the German Grid Initiative D-Grid leveraging both was evaluated within the IVOM project (http://www.d-grid.de/index.php?id=314&L=1). Have a look at the documents behind the link and at * A concept for attribute-based authorization on D-Grid resources http://www.sciencedirect.com/science?_ob=MImg&_imagekey=B6V06-4SKK1Y2-1-N&_cdi=5638&_user=2148698&_orig=search&_coverDate=03%2F31%2F2009&_sk=999749996&view=c&wchp=dGLbVtb-zSkzV&md5=0723836ce0e54c85a60ca4a4c4bac406&ie=/sdarticle.pdf * Trust Issues in Shibboleth-Enabled Federated Grid Authentication and Authorization Infrastructures Supporting Multiple Grid Middleware http://www.rrzn.uni-hannover.de/fileadmin/ful/publikationen/Trust_Issues_eScience2007.pdf * Future concepts of authentication and authorization in grid computing http://gks08.fzk.de/Talks/2008_09_12_Friday/Future_concepts_of_authentication_and_authorization_in_grid_computing_Benjamin_Henne.pdf Currently the D-Grid infrastructure and it's reference installation still is based on identity-based authorization. Resource providers define which VOs may use their resources (at the so-called GRRS - grid resource registry service) and get a per-resource customized gridmap. Any user must be a member of at least one VO to use resources. Because we use different grid middleware (Globus, LCG/gLite, UNICORE) building a new AAI is a challenge, because it must fit to all of these. Currently we start to extend the infrastructure with the aim to add VOMS-attribute-based authorization to all resources/middleware. We keep an eye on campus attributes, but for the near future we concentrate on the integration of the VO attributes for D-Grid infrastructure. Some communities have more interest in the use of campus attributes using GridShib, SLCS and so on as it was researched during IVOM and maybe that will be further investigated in that context. > So may I know what approach do you follow (PUSH or PULL) and do you use > a service like (e.g.VASH) for PUSHING Gridshib attributes to VOMS Server? > Can you elaborate how exactly you combine both attributes and do a > authorization based on those attributes? Looking at the current setup and upcoming extension of our grid infrastructure we have * user attributes from VOMS * attributes as attribute certificates in proxy certificates for Globus and gLite, VOMS attributes as SAML assertions for UNICORE 6 * concerning Globus, it will be an attribute push via the proxies At the moment we will not use GridShib (CA/ST) because of the version mismatch: VOMS SAML asserting SAML2 vs. GridShib supporting SAML1. It would be nice to integrated VOMS and Shibboleth SAML assertions into the proxy and push them to the resources, but here again is the SAML version problem. Other tools like VASH are not considered to be used. Have a look at the quoted documents for further information. Regards, Benjamin
smime.p7s
Description: S/MIME Cryptographic Signature
