Hello to all,
Unfortunately, because of intense work in this period (earthquake Abruzzo -
ITALY) I could not give my contribution in my module of the perLayer
security "web-security", and not know where I can contribute. I agree with
Andrea, I think a good idea to make at this time a simple interface for the
UI safety.
2009/4/17 Andrea Aime <[email protected]>
> 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
>
>
>
>
>
>
--
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software
C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia
phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: [email protected]
skype: neofx8080
web: http://geosdi.nsdi.it
------------------------------------------------------------------------------
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
