On Tue, Jul 15, 2008 at 8:57 AM, Benjamin Henne <[EMAIL PROTECTED]> wrote: > > in the German Grid Initiative we want to use attribute-based user-mapping > additionally to the currently used DN-based mapping. > The attribute mapping shall not replace the DN mapping. Every user has and > will have an own single account his DN is mapped to. This account has > standard rights and abilities on the resources. > Using attributes (groups, roles et cetera) we want to enable users to > activate additional special rights on demand by mapping to special accounts.
This is precisely the TeraGrid Science Gateway use case. The next major release of GridShib for GT (v0.7.0) will support this use case fully. The evolution of this feature is being tracked in bugzilla: http://bugzilla.globus.org/globus/show_bug.cgi?id=5882 Feel free to add your requirements to the bug or discuss your use case in the gridshib-user mailing list. To elaborate further, the current release of GridShib for GT (GS4GT) permits gridmap short-circuiting, but like yourself, we have found this to be inadequate. We require additive mapping, as illustrated in this diagram: http://dev.globus.org/images/7/7b/NewGridShibPDP.gif This is what will be implemented in GS4GT v0.7.0. > Some roles, for example a role "VO software admin", can be mapped to a > community account which for example has special rights to install > VO-specific software on compute resources. Yes, we can do that. Even the current version of GS4GT can do that. > But, for example another role we want to implement would be the role > "developer". A developer could have special rights on some resources, may > have access to special batch queues. Different "developers" shall not be > mapped to the same (community) account. This is where we want to use pool > accounts. The special rights shall have to be activated and shall only be > used for special purposes. Because we cannot have a single account for any > DN-attribute-combination our preferred solution is using pool accounts. In > the case of Globus this is what Dynamic Accounts with database or LCMAPS > back-end implements. I've never used pool accounts, but they need not be dynamic, right? If I'm understanding you correctly, you require *dynamic* pool accounts. This goes beyond what GS4GT alone can provide, I'm afraid. I'll have to look at the DA code and see what might be involved. By the way, the current version of GS4GT supports GT4.0.x only, but a framework to support both GT4.0.x and GT4.2.x (originally architected by Tim Freeman) is in place and will be activated in a future release, if not v0.7.0, in the version of GS4GT following that. Hope this helps a little bit. Let me know if you have questions about any of this. Cheers, Tom
