> 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? > The interfaces sound good. About using the ServiceInfo or an extension to provide access to them, not sure, sort of seems hacky. I would prefer breaking out a top level interface for that and make it a first class citizen, basically the same pattern as what we do for logging config now on trunk.
> 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?). Yeah, my thought would be to leave things the way they are now, and wait to make this decision when we have a better idea of exactly what the GEOXACML implementation will look like. > > Cheers > Andrea > > > > > > > ------------------------------------------------------------------------------ > Stay on top of everything new and different, both inside and > around Java (TM) technology - register by April 22, and save > $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. > 300 plus technical and hands-on sessions. Register today. > Use priority code J9JMT32. http://p.sf.net/sfu/p > _______________________________________________ > Geoserver-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
