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