" There is in HPC BP an authentication model with implied authorization" This is not true. There's nothing "implied" about authorization in the HPC Profile WG effort. It's out of scope. In particular, the WG has decided that the proper scoping of the *Basic* Profile is to *not* make any statements regarding authorization, and I agree. It is a mistake to make any attempt to read into the Basic profile regarding "endorsed" or "implied" authorization models, frameworks, and/or messages. -- Marty -----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Andrew Grimshaw Sent: Wednesday, February 20, 2008 12:15 PM To: 'Piotr Domagalski'; 'Steven Newhouse' Cc: ogsa-bes-wg@ogf.org Subject: Re: [OGSA-BES-WG] The up-to-date specification? All, Authentication and authorization are orthogonal to each other and out of scope of BES. There is in HPC BP an authentication model with implied authorization, e.g., if I authenticate I am authorized (Steven correct me if I am wrong). There is also the more general authentication profiles in public comment - Secure Addressing profile and Secure communication profile. These were formerly known as the EAP - Express Authentication Profile. A
-----Original Message----- From: ogsa-bes-wg-bounces@ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Piotr Domagalski Sent: Wednesday, February 20, 2008 12:07 PM To: Steven Newhouse Cc: ogsa-bes-wg@ogf.org Subject: Re: [OGSA-BES-WG] The up-to-date specification?
1. The BES-Management port doesn't allow any faults to be throwed - so how should I notify the client that he is not authorized to perform this call?
Auithorization checks are generally (should) be done before any user operation enters the service. This why these operation are in a different port type. You should be able to specify in your hosting environment the access
On Feb 20, 2008 5:15 PM, Steven Newhouse <Steven.Newhouse@microsoft.com> wrote: policy for just the
management port type and hence these operations. So the service code never gets to make an authorization decision.
I don't think I got that.
No matter how I configure the service, there's always the possibility that an authenticated user (e.g. by means of WS-Security) connects to the BES-Management port but she should not be authorized to call the StopAcceptingNewActivities method. Putting the matter of who is throwing the fault aside (whether it's the environment or the service itself) there should be a SOAP fault returned that is specified in WSDL. Now, there's no such thing in BES-Management WSDL as far as I can see...
Or am I missing something here?
2. Generally, the fault semantics are unclear to me, i.e. when should I use the fault directly in SOAP response and when should I put it into the response message. My questions are almost exactly the same as in https://forge.gridforum.org/sf/go/artf6066?nav=1 Any chance on getting answers to that?
IMHO faults should be returned in the body of the response. This allows operations on multiple activities to be requested, and for some to fail or succeed.
That does sound reasonable.
In that case when should the SOAP fault UnknownActivityIdentifierFault be thrown (not the one put into the Response element) ? It is defined as WSDL operation fault for GetActivityStatuses, TerminateActivities and GetActivityDocument. Should that be the case, when all of the supplied identifiers are unknown (as required in 6.2, first bullet)?
Other related question - what error should be returned by TerminateActivity that is called on an already cancelled/failed activity? And what about the case of not authorized termination? The spec doesn't mention NotAuthorizedFault being possible here but does so in case of GetActivityDocument which is obviously less harmful.
This is the current draft. The comments that have emerged during the last 6 months of experience have not yet been resolved into a new document. This will take place on the basis of the experience document currently going through OGF and when the document is submitted as a full OGF standard.
OK, thanks. And when can we expect OGSA-BES to become a full OGF recommendation?
Thanks for your help!
-- Piotr Domagalski -- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg
-- ogsa-bes-wg mailing list ogsa-bes-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-bes-wg