The up-to-date specification?
Hi all, I'm implementing an OGSA-BES service and I've encountered some requirements that are unfortunately not clear to me: 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? 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? 3. I'm willing to extend the state model. Where should I add appropriate operations then (e.g. to suspend an activity)? BES-Factory? Is there any guidelines on that? 4. Finally, where should I look for the most up-to-date specification? Is the GFD.108.pdf at ogf.org the only source of the latest specification? As far as I can see in the tracker, there were some changes scheduled, but it seems to me they haven't gone into the pdf doc. -- Piotr Domagalski
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.
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.
3. I'm willing to extend the state model. Where should I add appropriate operations then (e.g. to suspend an activity)? BES-Factory? Is there any guidelines on that?
The BES spec describes how you can extend the state model returned by the standard BES operations. If you want to add an extra operation into the port type to suspend an activity - then this moves beyond the scope of the current spec. I would suggest cloning the TerminateActivities operation.
4. Finally, where should I look for the most up-to-date specification? Is the GFD.108.pdf at ogf.org the only source of the latest specification? As far as I can see in the tracker, there were some changes scheduled, but it seems to me they haven't gone into the pdf doc.
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. Regards, Steven
On Feb 20, 2008 5:15 PM, Steven Newhouse <Steven.Newhouse@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
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
Authentication and authorization are orthogonal to each other and out of scope of BES.
This is what I was trying to get across earlier. It's a property of the container and the service hosting policy NOT something the service should have to enforce. Only authenticated and authorized requests should make it to the service implementation. That is why there is no NotAuthorizedFault in the BESManagement port type operations. WS-Security just authenticates you. Your container (should) perform an authorization decision before passing your message on to your service. Steven
On 20/2/08 09:39, "Steven Newhouse" <Steven.Newhouse@microsoft.com> wrote:
Authentication and authorization are orthogonal to each other and out of scope of BES.
This is what I was trying to get across earlier. It's a property of the container and the service hosting policy NOT something the service should have to enforce. Only authenticated and authorized requests should make it to the service implementation.
That is why there is no NotAuthorizedFault in the BESManagement port type operations.
WS-Security just authenticates you. Your container (should) perform an authorization decision before passing your message on to your service.
It's true that WS-Security already deals with the authentication fault, but authorization is the property of the container (can this authenticated user perform this management action?), so perhaps these operations should be able to thrown a NotAuthorizedFault. I'm a bit surprised it's not there, and given that many probably haven't implemented this port type, I'm not surprised it hasn't had more scrutiny. -- Chris
On Feb 20, 2008 6:58 PM, Christopher Smith <csmith@platform.com> wrote:
WS-Security just authenticates you. Your container (should) perform an authorization decision before passing your message on to your service.
It's true that WS-Security already deals with the authentication fault, but authorization is the property of the container (can this authenticated user perform this management action?), so perhaps these operations should be able to thrown a NotAuthorizedFault. I'm a bit surprised it's not there, and given that many probably haven't implemented this port type, I'm not surprised it hasn't had more scrutiny.
Exactly! This is my point. So I agree that authentication + authorization should be done by the container. Let's leave the authentication part, as this, preferably done by WS-Security, has its own faults (e.g. wsse:FailedCheck or wsse:FailedAuthentication). But after that comes the authorization which as far as I know doesn't have any well-known faults defined. Steven says authorization is up to the container. I agree with that - enforcing security is container's job. But as authorization failure is rather common (few of the users have administrative rights) I'd like to use something that all of the implementators agree on. So either: - I accept the if-authenticated-then-authorized policy as Andrew pointed before. - I simply use NotAuthorizedFault in BES-Management just as I would in BES-Factory (WSDL modification needed). - I use whatever fault I like but decrease the interoperability (still, WSDL modification needed) -- Piotr Domagalski
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.
- 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.
- I use whatever fault I like but decrease the interoperability (still, WSDL modification needed)
There's nothing stopping you doing this apart from interoperability! Steven
On Feb 20, 2008 9:05 PM, Steven Newhouse <Steven.Newhouse@microsoft.com> wrote:
If you fail authorization under the container's rule it is the container that sends the fault
And that is what I've been asking for - what the fault should look like. I have my own container (which does authentication and authorization) so I must choose the most suitable fault to return.
- I use whatever fault I like but decrease the interoperability (still, WSDL modification needed)
There's nothing stopping you doing this apart from interoperability!
That's what I surely don't want to do. Summing up, the only solution I can see now is to return standard SOAP fault with added human readable description saying that this general fault was thrown because of an authorization failure so that the client at the other side knows the reason her call was rejected. -- Piotr Domagalski
If you fail authorization under the container's rule it is the container that sends the fault
And that is what I've been asking for - what the fault should look like. I have my own container (which does authentication and authorization) so I must choose the most suitable fault to return.
By container I mean the web service hosting environment NOT the BES Container. It is therefore not a BES specific fault that gets sent.
Summing up, the only solution I can see now is to return standard SOAP fault with added human readable description saying that this general fault was thrown because of an authorization failure so that the client at the other side knows the reason her call was rejected.
If I'm not authorized to access a WCF service (as an example) the error message I get back as a client is very vague. Just knowing there is a service there that is rejecting you is very useful bit of information for a hostile client. Better to make it appear the message just failed to connect. Server side there should be clear logging to indicate why the connection was dropped - not authenticated and/or not authorized. Steven
On Wed, Feb 20, 2008 at 11:23 PM, Steven Newhouse <Steven.Newhouse@microsoft.com> wrote:
By container I mean the web service hosting environment NOT the BES Container. It is therefore not a BES specific fault that gets sent.
Yes, and what I meant was that we have our own hosting environment which happens not to have standard way of throwing SOAP faults in case of an authorization failure. It is up to the service developer to pass the fault to the external interface.
If I'm not authorized to access a WCF service (as an example) the error message I get back as a client is very vague.
OK, that does make sense. Thanks! -- Piotr Domagalski
On 20/2/08 12:05, "Steven Newhouse" <Steven.Newhouse@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
" 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
I don't think I got that.
Does the explanation given in the other email resolve this?
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)?
Exactly. If it does not apply to all then individual responses are needed in the response vector.
Other related question - what error should be returned by TerminateActivity that is called on an already cancelled/failed activity?
Implementation specific. Applying terminate to a terminated activity is no operation.
And what about the case of not authorized termination?
Implementation specific behavior at present.
The spec doesn't mention NotAuthorizedFault being possible here but does so in case of GetActivityDocument which is obviously less harmful.
Hmm. The text mentions NotAuthorizedFault but the list of faults (6.2.4.3) does not. This is something to raise when we review before going to full specification. Should all of these operations be throwing NotAuthorizedFaults or is the text in the paragraph a 'mistake'. I've raised a tracker for this. Good catch.
OK, thanks. And when can we expect OGSA-BES to become a full OGF recommendation?
I imagine before Barcelona. Steven
participants (5)
-
Andrew Grimshaw -
Christopher Smith -
Marty Humphrey -
Piotr Domagalski -
Steven Newhouse