Hi,
given that basics of the new Wicket UI have been laid down I am
beginning to look into things that we did not provide a UI
for in the past.
One of them is users and security, in its current default
implementation.
As an aside, I'm aware of the GEOXACML work, and that it might
end up becoming a premier alternative to the existing simple
implementation. At the same time, GEOXACML is very general
and difficult to configure, so making a UI for it may
well take a lot of time. It's kind of making a UI for
editing GML files, if you know what I mean 
Soo, for the moment I don't have enough time for it, but
it would still be good to have a UI for the admiteddly
simplistic security system we have now, especially since
the UI would be similarly simple.
At the moment we have three security related files:
- users.properties, that contains user names, passwords,
and roles
- services.properties, that contains basic service security
- layers.properties, that makes up basic layer security
It would be nice to have a UI for them, a simple table
based approach would do. The UI will need to be backed
by some simple reader/writer classes and some model classes
that the UI can bind to. At the moment model classes
are missing and we're using Spring facilities to read the
files, the write side is not there at all.
For these, what about following the lead of the service
configuration and have UserInfo objects, as well as
LayerAccessRuleInfo and ServiceAccessRuleInfo, and have
some security service providing access to those?
Justin, can the service loading framework accomodate
something that is not really a OGC service?
UI wise, I would go for three table based pages.
The user one, would list users and roles, clicking
you'd get to a panel allowing to edit user name,
password (with confirmation) and roles using a
palette component (the same used for extra styles in
the layer configuration) listing the existing roles,
but also allowing to provide new ones.
While we're at it we can also introduce a toggle
in the user file that can be used to add a encrypted
password mode, that the UI would force by default:
when the flag is raised, the passwords in the file
would be encrypted (when missing, not encrypted,
to allow for backwards compatibility).
The service layer one, a table with fixed sorting
based on service and method and a list of roles,
and single row editing UI very similar to the user
one.
The per layer security one, again similar, forced
sorting based on workspace, layer, access mode,
simple editing form based on known workspaces,
layers and access modes.
Hmmm.... to be honest, without going into the complexity
of GEOXACML, I would prefer a rule system that did
bind layer and service security into one single rule,
something like:
namespace.layer.service.method.permission=ROLE_1[,ROLE_2][, ...]]
With the services we have atm, service and method
pretty much state if you're reading or writing
already, but for the sake of generality, let's
keep the mode around, most of the time it
would not be needed, but would still allow
for a rule like:
topp.*.WFS.*.w=ROLE_WRITER
that is, allow WFS to write on the namespace "topp"
only if you have the ROLE_WRITER role.
The temptation to also add filtering and column cherry
picking in the mix is strong, but that would make
things too complex for a property based configuration
system, but this one seems obvious enough to be
made on trunk and address a common and simple need.
Opinions? Should we just keep the security files
as they are instead and leave every non trivial
security setup to GEOXACML instead (even the mixing
of service and layer access in a single rule?).
Cheers
Andrea