David Winslow ha scritto: > Hi all, > > I started writing this email before I realized how long it would be, so I > have > copied what I was originally going to say into > http://geoserver.org/display/GEOS/GSIP+25+-+Pluggable+Authentication+Mechanisms > > on the wiki. This is just me musing on bugs > (http://jira.codehaus.org/browse/GEOS-1579 and GEOS-2000) so there's not a > specific use case driving it, but I think now (with GS 2 coming up) is a good > time to give some serious forethought to security configuration.
I read the wiki page a few of times and I'm still a little confused, so sorry if my comments are off the mark. But here we go. > -David Winslow > > I have been doing some thinking about pluggable security systems in > GeoServer. > (inspired mostly by http://jira.codehaus.org/browse/GEOS-1579) This jira states: "Make it possible to use different authentication providers by leveraging a plugin mechanism plus some settings in web.xml so that people can choose to use geoserver built in authentication provider, or JAAS one (in the specific, Tomcat's version, since JAAS authorization setup is container dependent, sigh) or whatever other provider the user may fancy to develop as a module." It is not at all about the zones, but about being able to pick up the provider that will authenticate users and give back the roles list, so something that would act as a replacement for users properties. This seems to me the most important aspect of a pluggable authentication mechanism. Is it what you're talking about when you're showing the example relating to the web.xml configuration? In my opinion the choice of security authentication mechanism is something that should be stored into the data directory, not in web.xml, so that you can move it around along with the data dir, and so that you can change it even in containers that do not unpack the war. The only thing you have to change in web.xml, should you need to, is the removal of the Acegi filter altogether... that's something we could think of making configurable outside of web.xml as well, it's just a little harder than the rest. > Right now we > have at least two "sections" of GeoServer which are guarded by different > authentication mechanisms, but share a database for authorization. The authentication mechanism is one as far as I know, it's the authorization mechanism that's different depending on how you access GeoServer? > However, right now all that's available to users ("users" at the > moment being those willing to modify web.xml and some properties files by > hand) is the option to assign roles and passwords to users, and to restrict > either layers (if we include Andrea's recent work) or service methods to a > subset of those roles. That is, there are three configuration sections > relevant to security: > > <users.properties> > defines user, password, list of roles This is authentication, built in mechanism, something I would love to see as pluggable. > <layers.properties> > defines layer, read/write, list of allowed roles > > <service.properties> > defines service, operation, list of allowed roles > > <rest.properties> > defines URL, HTTP method, list of allowed roles This is authorization, decomposed in two orthogonal ways, data and services. This could (should) be made pluggable as well, thought it's probably a bit less important than making authentication pluggable. > What's not at all user-configurable right now is the authentication mechanism > used to find out what user is accessing GeoServer. We just have the > following > hardcoded: > for the admin console, use an HTTP cookie, redirecting to a form if the > cookie > is not found OR if the user is not in the required role (which is also > hardcoded). > for the OWS services, use HTTP basic auth, returning a 401 error when > permission is denied. > for rest stuff, no authentication is implemented. > > So we have GeoServer kind of divided into security 'zones;' the admin console > is one; the OWS services are another, and the REST stuff (or maybe just the > rest) constitutes a third. It might be nice for users to be able to define > these zones themselves, but right now they seem pretty radically different in > structure so that should probably wait until we have enough use cases to > better define them. Each zone has not only its own authentication mechanism, > but also its own type of restriction rules: > admin console: it's just 'you have to be in ROLE_ADMIN' > OWS service: layer+access or service+method -> list of allowed roles > REST API: URL+HTTP method -> list of allowed roles Admin console wise, seems like saying unix is not flexible enough because admins have to be in the ROOT group. What am I missing? ;) > For a first stab at pluggable authentication mechanisms, maybe it's > sufficient > to just let users set the mechanism for each of these zones individually; it > could be as simple as including a set of parameters in web.xml that are > expected to be class names of authentication plugins, something like > > <context-param> > <param-name>OWS_AUTHENTICATOR</param-name> > <param-value>org.geoserver.acegi.HttpBasicAuthenticator</param-value> > </context-param> > Bean names could work here as well. The default values would just emulate > the > current authentication system, and the current properties files would still > be > used for the authorization tasks. > > In the long run though, it may be that users would like to be able to define > their own zones (example use case: multiple REST plugins are provided that > need to provide access to different clients; so you want to allow two > different authentication mechanisms to clients using different subsets of the > REST API). Since a zone as I've defined it is just a subset of GeoServer's > functionality combined with an authentication mechanism and a type of rule, > we > could probably have just a file zones.properties that looks something like: > > <zones.properties> > #prefix[,prefix...]=authenticator,filter[config[,config]] > /config/=org.geoserver.acegi.FormAndCookieAuthenticator,org.geoserver.security.AdminOnlyFilter > /ows,/wfs,/wms,/wcs,/wfsv=org.geoserver.acegi.HttpBasicAuthenticator,org.geoserver.security.MethodAndLayerFilter(service.properties,layers.properties) > /rest/=org.geoserver.acegi.HttpBasicAuthenticator,org.geoserver.security.HttpMethodFilter(rest.properties) Here I'm loosing you. The authentication mechanism should be one for the whole server imho... do you want the console to use the built in mechanism and the services to use a LDAP server instead? In the long run I would also love to see the authentication mechanism configurable from the user interface, like a drop down listing "built-in", "JAAS", "CAS", "LDAP" and so on, but still be used "server wide". As for the path based approach above, hum, I'm uncertain. It seems inspired by the acegi ant based filters defined here in the Acegi configuration file: http://svn.codehaus.org/geoserver/trunk/geoserver/main/src/main/java/applicationSecurityContext.xml but they don't look like a replacement of all the structure that's being set in place. Usually with Spring you define the static part of your application, and there is code in the application that handles the dynamic part by using lookups. For example, if I were to create a pluggable authentication system, I would declare in the applicationSecurityContext.xml a GeoserverAuthenticationManager that would be just a router, and it would decide what actual authentication system to use by looking into the spring context (for pluggable authenticators) and in the configuration (to see which one the user chose to use). Failing the lookup, it would know how to fall back on the default authenticator. What I would see as doable is having pluggable authorization classes able to handle data, rest and ows authorizations, using the same approach as above (router class + lookup and default implementation), so that you can roll your own way to authorize calls as needed. But it seems to me each zone would retain its own peculiar way to do the authorization, OWS by parsing the request and coming up with a service and a method (eventually a version, the request params), REST by the resource path, what I see as pluggable is the way you use to associate those tokens to a list of roles. Doing the same for the actual filter chains that performs the cookie handling, sessions integration and such is harder thought, the Acegi list of filters is critical, you can make it not work at all by just listing the filters in the wrong order. Consider how many changes you'd have to do in order to use Digest authentication in place of the basic one, you'd have to declare new beans, wire them up in a different way. Do you really want to expose that to the user? Also, I don't easily see how the above zones configuration and the Acegi configuration could work together, do you already have a plan? Cheers Andrea ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
