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