Hi,
so we gathered some feedback on how the per layer
security was implemented and some changes are needed.
They do not change the contents of the proposal, but
the way it is implemented, in particular, the proposal
was not complete on
The current approach (let's call it HIDE) assumes the
user authenticated himself before doing any
business with the server, and the server in turn
lets her see only the layers that
she's authorized to see, and pretends layers that
she can only access read only to really be read only.
That is, capabilities don't list the layers that you
can't access to, direct access returns a service exception
stating the layer is not there, direct write on a layer
where you have no write access states the layer is not
writable. No where the server says you should authenticate
of change your authentication to perform the operation
that failed.
This works fine from a security point of view, you cannot
even infer the layers are there, but has quite some issues
with standard clients such as uDig, or Google Earth,
since they do not allow you to authenticate preventively
and assess your authentication went fine. They are made
to react to a 401, only then they will present an
authentication dialog.
So for those clients a different approach is needed,
one where the capabilities do contain all the layers,
and where you get a 401 when you try to use a layer
you don't have clearance for. Let's call this approach
CHALLENGE.
Unfortunately none of the above suits the needs of
the organisation sponsoring the "per layer security"
work. They need a half in between, which I'll call
MIXED, in which the capabilities do contain only
what you're supposed to see with the current authentication
(if any), but direct access to a layer (one that was
not in the capabilities) triggers a 401 and makes the
client (in their case, OL or Google Eearth) ask for
an authentication.
In this case they don't want the world to see the
list of layers actually available, but they do want
people with direct link be able to use them from
GE in a way that makes GE trigger an authentication
request.
So it seems that for various reasons I'll have to
implement all three behaviour. HIDE is already there,
CHALLENGE is needed for capabilities driven clients
to work, MIXED is what the sponsoring organisation needs.
Of course the code to handle the three options is
becoming quite a bit hairy but... I'm not seeing
any escape route.
I'm going to commit the changes as soon as I'm done
for you to look at, and I'm open to suggestions
and of course reviews.
Cheers
Andrea
