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