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

Piotr Domagalski szalik at szalik.net
Wed Feb 20 13:18:09 CST 2008


On Feb 20, 2008 6:58 PM, Christopher Smith <csmith at 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


More information about the ogsa-bes-wg mailing list