[OGSA-BES-WG] The up-to-date specification?

Christopher Smith csmith at platform.com
Wed Feb 20 16:12:36 CST 2008


On 20/2/08 12:05, "Steven Newhouse" <Steven.Newhouse at microsoft.com> wrote:

>> So either:
>> - I accept the if-authenticated-then-authorized policy as Andrew
>> pointed before.
> 
> The purpose of the putting the BESManagement operations in a different port
> type was so that container policy regarding access could be applied regarding
> access. You need to be authenticated and authorized for an operation. I could
> be authenticated and authorised to submit and monitor jobs (BESFactory), and
> authenticated but not authorized to use manage the container (BESManagement).
> 
> If you fail authorization under the container's rule it is the container that
> sends the fault (or just drops your message - depending on implementation) not
> the service. The service code should NEVER see un authorized code IMHO.
> 
Not sure I agree ... see below.

>> - I simply use NotAuthorizedFault in BES-Management just as I would in
>> BES-Factory (WSDL modification needed).
> 
> IMHO no. This decision is not a property of the the service implementation as
> it can be done by the container. I think you are correct in the need to add
> NotAuthorizedFault to the GetActivityStatus, TerminateActivites &
> GetActivityDocuments operations. In there are actions that even someone who is
> authenticated and authorized to invoke the operation should not, by the
> service logic, be able to do.
> 
There is a similar need for a not authorized fault for the management
routines. Many implementations are dealing with a back end which might not
authorize the operation even if I am authorized to the container. This is
analogous to whether I can cancel an activity or not (the container might
not know whether I can or not).

-- Chris



More information about the ogsa-bes-wg mailing list