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 ------------------------------------------------------------------------------ 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
