Hi Stephen, On Friday 19 December 2008 12:46:56 Burke, S (Stephen) wrote:
MappingPolicy objects that act as links between StorageShare objects and UserDomain objects [...]
One point I'd make is that the UserDomain objects are a bit of a red herring in all this, when thinking about authorisation it's better just to focus on the Policy objects.
Yes, publishing a MappingPolicy object certainly a minimum requirement and the "easy bit" :-)
Policies will generally refer to VOs and the UDs can publish information about VOs, but that's pretty much irrelevant to using the Policies.
Sure, one can publish a Policy object without linking it to a UD, but that may place additional burden on clients when they attempt to do service selection. Policy objects, in general, represent some form of access control that allows end-users it. Without linking the Policy object to a UserDomain, one forces the GLUE client to understand the authorisation schema to decide whether members of the UG are allowed to access it.
The main reason for having multiple Policy objects attached to the same Share is that they could declare policies in different authz *schemes*.
Ah, that makes sense.
For a single scheme (e.g. I expect to have a "glite" scheme for the EGEE standard use with VOMS) you would generally only expect a single policy object. In the CE discussion I raised the possibility of having multiple MappingPolicies within a single scheme to give the possibility to express an ordered priority between the Rules, since Rules within an object have no ordering, but I think that was rejected. So I think the answer is that for the normal case, e.g. an SE within EGEE/LCG, you will just have a single MP with a set of authz rules (unordered) looking much as it does now, e.g.
VO: cms VOMS: /atlas/Role=production
It would be nice to have this in the document. Perhaps something like: Multiple MappingPolicy objects MAY refer to the same Share object. If so, these MappingPolicy objects SHOULD have different authorisation schemata.
complication for the clients. We can remove it by changing either the Share: MappingPolicy.ID multiplicity to "optional" (0..1)
No, it needs to be * to support multiple schemes, but in general a client would only understand one scheme so it only needs to consider (at most) one of the MP objects. I think we explicitly don't define the expected behaviour if a client can understand more than one scheme.
OK.
Technically you could publish multiple objects with the same scheme, but in the absence of extra rules it would be semantically identical to having a single object, and probably the scheme definitions should normally say explicitly that there should only be one object.
Aye, see my suggestion above.
(Mapping)Policy: UserDomain.ID multiplicity to "required" (1).
There is no guarantee that UD objects are published at all, and in EGEE/LCG my expectation is that they won't be.
Ah, OK ... but see my other email and the (open) question of doing service selection without the client understanding the authorisation schema.
It might be worth adding another optional attribute, to allow accounting for (temporarily?) off-line storage. For example, adding:
UnavaliableSize UInt64 0..1 GB Size of storage extent that is [..]
Yes, I think we need to add something new to allow for this distinction between "installed" and "currently available", but we should probably have a dedicated phone meeting to discuss what's needed.
Yup. Cheers, Paul.