search

dCache / dcache

dCache - a system for storing and retrieving huge amounts of data, distributed among a large number of heterogenous server nodes, under a single virtual filesystem tree with a variety of standard access methods
https://dcache.org
291 stars 136 forks source link

WLCG token wlcg.groups claim ignores OP identity #6740

Open vokac opened 2 years ago

vokac commented 2 years ago

Similarly to the #5950 and as discussed recently in WLCG AuthZ mailing list same problem apply also to wlcg.groups or generally token group identity mapping. Nobody can guarantee that two different OP doesn't use same group name and that mean oidcgrp mapping is not sufficient with dCache that's used with tokens from multiple issuer.

Multimap plugin should allow to specify OP also for oidcgrp mapping, e.g.

oidcgrp:group_name@OP
paulmillar commented 2 years ago

There's a couple of different issues here.

First, clashes of group names.

What you describe is certainly a (potential) problem.

The solution (as proposed by AARC G002) is to introduce a namespace of groups; for example, if two OPs both have a group test then dCache may distinguish between them because these two test groups would use different namespaces.

Under AARC G002, what you describe as a problem (two OPs asserting the same groups) is seen as a feature -- provided the two groups are (in some sense) the same group; for example, you could think of two OPs that share the same underlying group-membership database. The concept of "the same group" is simply that the two OPs using the same group namespace. (To be honest, I'm sceptical whether this is really useful.)

The groups asserted via WLCG AuthZ do not have the concept of group namespace. Instead, there's a (tacit) assumption that the OP is the authority of those groups. Because of this, my proposed way of handling this is to put all WLCG AuthZ groups into their own namespace, which is derived from the OP's identity.

All of this is to say that I agree with updating dCache to support oidcgrp:group_name@OP, but for somewhat more complicated reasons.

The second problem is about authorisation.

Given the concept of group namespaces (introduced by G002), which group namespaces is the OP allowed to assert? My plan is to assume that the service (dCache) can trust the OP. The OP will only assert group membership it's allowed to assert.

It would be relatively easy to add support for restricting the namespaces; however, such configuration would be quite weird (partially trusting an OP) and I would like to see some concrete use-cases before implementing support.

vokac commented 2 years ago

Can we trust all OP not to accidentally add conflicting group name or become compromised? I don't like the idea that any other OP can potentially define access to our resources on shared RP. But if this is considered by EGI as a feature personally I can live with such behavior, because our storage sites will be explicitly configured not to allow any access to our storage via wlcg.groups / oidcgrp.