I’m in the process of building solutions based on geoserver and geofence that also include other web-services I’m implementing in other webapps on the same servers.
It would seem that geofence is (in concept) well suited to managing security for web services in general, as long as those services choose to make appropriate access to geofence while processing a request – that being to access the geofence authenticator just as geoserver would, and then interrogate the rules in a similar manner as well.
What would be so great about that?
a) Users and user groups are defined in just one place.
b) Users can be granted access to multiple services and methods in one framework of rules.
Administratively, when I get a new user I can add that user to whatever groups are appropriate and then I’m done.
If geofence supported plugins, then it becomes possible to define rule-details that only the plugin knows about. For example you could have a rule-type and when that is “geoserver” the rule has the usual support for designating a layer and layer-details. But if you pick “myplugin” then perhaps you still name a service and method, but not the inapplicable layer-details (and perhaps other plugin-supplied details instead).
I realize the abstractions involved would significantly impact the U/I of geofence as well as the code.
Does anybody have thoughts on this? Does this seem appropriate as an enhancement of geofence? Does doing this make geofence too complex? Is it appropriate to expand scope to non-geoserver instances? Would it be possible for me to customize geofence for my own purposes instead? If I did this would I still be able to manage security this way in future releases of geoserver or would the core-geofence then become so embedded in geoserver as to make that impossible?
Thanks – Walter Stovall