Sylvain, I am happy with all your suggestions :-) Steve 2008/10/29 Sylvain Reynaud <Sylvain.Reynaud@in2p3.fr>:
Steve Fisher a écrit :
Hi,
Hi,
I attach notes extracted from various emails between Akos Frohner, Stephen Burke and myself. Please read them before continuing ...
I trust you have now read them
I find that the set of use cases and other arguments in "thoughts on authz" convinces me that we do need to be able to specify the authz information explicitly.
They convince me that the authorization filter is not only useful for middleware use-cases; it is also needed when information contained in session object is not enough to enable authorization filtering.
Nevertheless, most security contexts (including password and SSH security contexts) are used through a local SAGA object and have a UserID attribute, and I think the Service Discovery implementation should extract or deduce the authorization information understood by the discovery system from the session object when possible.
However I do think that in order to ensure that the API remains easy to use we should continue to allow the authz information to be taken from the security context - with the caveat that this may actually not make much sense with some authz schemes.
Yes, I think we should. The authorization filter should be needed only when information contained in session object is not enough (and for middleware use-cases also).
If this is accepted then the only problem is how to represent this information. The draft spec says that you match against a "VO" however it says that the "VO" may in fact be any string and anticipates that a common use will be with the IN operator for eaxmple VO in 'CMS, 'ATLAS'). So I suggest simply changing the name of the field from VO to Authz and "VO Filter" to "Authz Filter".
Yes, and please also change the sentence about the default behaviour ("attributes of the context" instead of "VOs of the context" on page 11).
To map it onto the GLUE tree structure we could take all concatenations (perhaps separated by a "." of the name fields in the hierarchy of "User Domain" names. In practice I think it will be somewhat implementation dependent because different grids will use these fields in different ways. This set of concatenations would be the set of valid Authz values. It will not guarantee that you can use the service but can we do better and still keep it simple?
I think we don't need to guarantee that we can use the service when the authorization filter is set. However, it would be fine to guarantee this when using the default behaviour.
To enable this, the specification could tell that an exception MUST be thrown when the authorization filter is not set and the session object does not contain enough information to filter the services accessible to the user. The user will still be able to deactivate authorization filtering by providing an empty authorization filter, and then he will be aware that he may not be able to use the discovered services.
Sylvain
Steve ------------------------------------------------------------------------
-- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
-- Steve Please note my new e-mail: <Dr.S.M.Fisher@gmail.com>