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

[Steve Fisher]

Sylvain,

I am happy with all your suggestions :-)

Steve

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



-- 
Steve

Please note my new e-mail: <Dr.S.M.Fisher at gmail.com>