greetings -
I am trying to create role-based configurations; i.e. certain folks like
to look at the world one way, others another, etc.
Is there a recommended way to bind a URL to a specific sld, and support
multiple concurrent sld's with the same Geoserver instance? (I can
hopefully then use 'realm'-based authentication groups, etc based on URL
patterns...)
thanks!
Chris
This is fast becoming one of the most requested features, so we should probably start thinking about the design.
Though it sounds like what you're asking for is a bit different, many people want different admin privileges, it sounds like you're just asking for per user.
But the short answer is no, we don't really support it.
You could likely do it with SLD I suppose. You can bind slds to urls completely outside of GeoServer, and then use the SLD= param to refer to the url location. Like SLDs can be completely remote to GeoServer. I think the problem with that would be that when that style is used GeoServer is the one doing the requests, and it won't have the user information. If you can match patterns then you could match it based on including that URL in the request url, or the named styles.
Are you using the same client for things? If so I might just put the logic there, with it using different slds.
Note that we do have a powerful security subsystem that could support most any of this, but it hasn't really been hooked up. There are some examples of how to get at users and roles though, which you can inject to a service that extends the existing services.
Chris
cgnicholas@anonymised.com wrote:
greetings -
I am trying to create role-based configurations; i.e. certain folks like
to look at the world one way, others another, etc.Is there a recommended way to bind a URL to a specific sld, and support
multiple concurrent sld's with the same Geoserver instance? (I can
hopefully then use 'realm'-based authentication groups, etc based on URL
patterns...)thanks!
Chris-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users!DSPAM:4005,47408c51129172090977483!
Though it sounds like what you're asking for is a bit different, many
people want different admin privileges, it sounds like you're just
asking for per user.
Actually, I'd prefer to assign access control by roles, not users. So
basically you couldn't even look at the stuff associated with an sld if
you weren't a member of that role.
You could likely do it with SLD I suppose. You can bind slds to urls
completely outside of GeoServer, and then use the SLD= param to refer to
the url location.
Like one does in Minn mapserver with 'map=param'
the problem with that would be that when that style is used and
GeoServer is the one doing the requests, it won't have the user
information.
chicken and egg...(and remember, chickens are an egg's way to get
around... 
If you tried to access a particular sld, and it were bound
to a realm, you would be challenged for credentials, and RFC 2617 or
something would kick in.
If you can match patterns then you could match it based on
including that URL in the request url, or the named styles.
I'm thinking you might have to so something crude like make a separate
Tomcat context for each sld ... something like:
/geoserver/sld1/
/geoserver/sld2/
/geoserver/sld3/
etc, and map each using realm auth, as per:
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html . Now, each of
these web.xml configs would all use the same class in their
servlet-config, only now the servlet would start paying attention to this
new "sld=param' item.
Are you using the same client for things? If so I might just put the
logic there, with it using different slds.
clients can be easily hacked...I definitely want the RFC2617 'digest'
stuff to kick in....
Note that we do have a powerful security subsystem that could support
most any of this, but it hasn't really been hooked up.
Is this on the wiki? tell me/point me at more!
Chris
cgnicholas@anonymised.com wrote:
Though it sounds like what you're asking for is a bit different, many
people want different admin privileges, it sounds like you're just
asking for per user.Actually, I'd prefer to assign access control by roles, not users. So
basically you couldn't even look at the stuff associated with an sld if
you weren't a member of that role.
Sorry, I just meant user in the sense of WMS/WFS/WCS services, instead of portions of the admin tool. Not so much talking role vs user
You could likely do it with SLD I suppose. You can bind slds to urls
completely outside of GeoServer, and then use the SLD= param to refer to
the url location.Like one does in Minn mapserver with 'map=param'
the problem with that would be that when that style is used and
GeoServer is the one doing the requests, it won't have the user
information.chicken and egg...(and remember, chickens are an egg's way to get
around...
to a realm, you would be challenged for credentials, and RFC 2617 or
something would kick in.
Yeah, so GeoServer would need to be the one supplying those credentials, which is beyond its current capabilities.
If you can match patterns then you could match it based on
including that URL in the request url, or the named styles.I'm thinking you might have to so something crude like make a separate
Tomcat context for each sld ... something like:/geoserver/sld1/
/geoserver/sld2/
/geoserver/sld3/etc, and map each using realm auth, as per:
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html . Now, each of
these web.xml configs would all use the same class in their
servlet-config, only now the servlet would start paying attention to this
new "sld=param' item.
Ok.
Are you using the same client for things? If so I might just put the
logic there, with it using different slds.clients can be easily hacked...I definitely want the RFC2617 'digest'
stuff to kick in....Note that we do have a powerful security subsystem that could support
most any of this, but it hasn't really been hooked up.Is this on the wiki? tell me/point me at more!
Yeah. http://docs.codehaus.org/display/GEOS/GSIP+16+-+Security+subsystem was the proposal.
http://docs.codehaus.org/display/GEOSDEV/Geoserver+authentication+and+authorization+subsystem is requirements and evaluation
http://docs.codehaus.org/display/GEOSDEV/Geoserver+security+implementation%2C+initial+version has notes on the initial implementation
There are also two community projects that make use of it in svn: http://svn.codehaus.org/geoserver/trunk/geoserver/community/
QueryUsers gives a rest interface to query and set role based user permissions. And openplans-authentication uses a different authentication mechanism. If you're interested in either we can probably get David to write up a wiki page about them.
So what I think I'd do if I were you is look in to Acegi (the security system we selected), and basically see if you can extend the WMS for remote SLDs to be able to pass through the logged in user password information. You should be able to get at that through the acegi security stuff. Or there are probably some other routes, but basically if you want to get dirty with the code it'll definitely get you digest authentication, and access to those user credentials / roles from anywhere within geoserver. And then you can either use the default geoserver user/password storage stuff, which is pretty weak, or use acegi to plug in to an existing system.
best regards,
Chris
Chris
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users!DSPAM:4005,4742333c176741431913854!