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

[Marty Humphrey]

" 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 at ogf.org [mailto:ogsa-bes-wg-bounces at ogf.org] On
Behalf Of Andrew Grimshaw
Sent: Wednesday, February 20, 2008 12:15 PM
To: 'Piotr Domagalski'; 'Steven Newhouse'
Cc: ogsa-bes-wg at 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 at ogf.org [mailto:ogsa-bes-wg-bounces at ogf.org]
> On Behalf Of Piotr Domagalski
> Sent: Wednesday, February 20, 2008 12:07 PM
> To: Steven Newhouse
> Cc: ogsa-bes-wg at ogf.org
> Subject: Re: [OGSA-BES-WG] The up-to-date specification?
> 
> On Feb 20, 2008 5:15 PM, Steven Newhouse <Steven.Newhouse at microsoft.com>
> wrote:
> > > 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
> 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 at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-bes-wg


--
  ogsa-bes-wg mailing list
  ogsa-bes-wg at ogf.org
  http://www.ogf.org/mailman/listinfo/ogsa-bes-wg