On Thu, Jul 17, 2008 at 10:18 AM, Benjamin Henne <[EMAIL PROTECTED]> wrote: > Tom Scavo schrieb: >>> >>> 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. > > To what (kind of) accounts users with activated special rights are mapped to > at TeraGrid? Are they mapped to community accounts? Or do users have a > second/third/aso. account for those purposes.
Sorry, I misquoted your remarks earlier, which may have led to a misunderstanding. Let me try again. 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. 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. > 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. In TeraGrid, not all users have their own account. Gateway users, for example, implicitly use the gateway's community account. In that sense, the community account is a shared account. > Using attributes (groups, roles et cetera) we want to enable users to > activate additional special rights on demand by mapping to special accounts. Gateway requests are accompanied by attributes (by virtue of a SAML assertion bound to the gateway proxy). These attributes permit fine-grained auditing and incident response at the resource. Groups and roles may be asserted as well, but currently these are not used within TeraGrid. We are in the early stages of deployment, so the questions of attribute-based mapping and attribute-based access control have not come up. That said, the current version GridShib for GT permits both attribute-based mapping and attribute-based access control. What v0.7.0 adds is the ability to configure a single service for both identity-based mapping/authz (i.e., gridmap) and attribute-based mapping/authz. Among other things, this permits a gradual phase-in of attributes. > This is exactly where we think > about pool accounts, so that different users are not mapped to the same > account simultaneously. Well, the gateways based on the community account model handle the shared account at the resource so that users don't step on each other's toes. Other gateways have chosen to issue a grid credential to each user to avoid having to use a shared account (and for other reasons perhaps). The topic of dynamic accounts has come up once that I recall. The resource administrators that I've talked to do not feel comfortable with dynamic accounts, thinking they may pose a security risk. >> 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. > > If one has two users using the same role at the same time, we do not what > them to be mapped to the same account. First, it is difficult to differ > which action has been done by which user (auditing), second, users could > read/write the other's files. Understood. Currently, gateway developers handle the shared account at the resource in such a way that the work of one user does not clobber the work of another. > We think the use of pool accounts could solve this problem. Starting a job, > every user would get one of the accounts from an predefined pool (he leases > it for the needed time). After job termination the leased account would be > release for the use by another user (no persistent account leasing). In this > way two users would never use the same account simultaneously. Yes, that seems reasonable, but as I said, there are concerns within TeraGrid that dynamic accounts pose a security risk. I have not fully analyzed this risk, so I can't say offhand if it is real or not, but that's why we don't support dynamic accounts in GridShib at this time. Tom
