[SAGA-RG] One final thing to agree upon for SD

[Sylvain Reynaud]

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 at ogf.org
>   http://www.ogf.org/mailman/listinfo/saga-rg