Hi Chris, I cc'd Martin and Andrea, the last time my postings to user/developer list got lost and I have no idea why
I will try to give you some short answers because this implementation is quite complex. 1) Yes, it is possible to define security constraints on geometries. All Access rules are defined in a set of xml files located in GEOSERVER_DATA_DIR/geoxacml. Geometries can be specified in GML2 and GML3 syntax. At the moment I support the BBOX parameter and there are some test cases with an restricted area expressed in GML3. GeoXACML is an extension of XACML (which is quite complex) introducing a "Geometry" Data type and all the functions you know from the JTS topology suite (intersects, intersect, union, overlapps ....). 2) A second possibility is to pass back a geometry as an obligation to geoserver. This means that the security sytem permits access but passes back geometry restrictions to GeoServer logic. Andrea had the great idea of using CQL expressions as obligations and passing back a Filter object to GeoServer instead of a simple permit or deny. This requires a change of the DataAccessManager interface and Adrea wants to defer this to a point in time after the GeoServer 2.0 release. 3) The XACML part itself is for securing all non geometriy data. A typical question would be: Has this user a role which allows him to issue a WMS GetMap request for a specific layer in a specific workspace in the requested area ? 4) If geoxaml is activated, all request should run through this security system. It is transparent for the client. 5) Roles itself are also a resource. As an example, you can specify that a role is valid only from 8:00 am to 17:00 pm. The role concept is hierarchical. Additionally you can specify needed role parameters, see 6) 6) Roles may have role parameters (I am still working on that). The acegi security system has the concept of a UserInfo objcet. This object stores user specific data like email address or eployee number. Needless to say that you can attach a geometry to this UserInfo object. (Restricting the area for a specific user). The properties of the userinfo object may be passed as role parameters to the XACML Engine if required. 7) I am still working on securing urls with means of XACML. Urls can be protected with wildcards or regular expressions. 8) Since XACML says nothing about the transport mechanism from client to server, 2 possibilities are offered. a) Local in memory without xml encoding/decoding b) using http post requests, meaning GeoServer is already an universal GeoXACML Engine. The url is http://.../geoserver/security/geoxaml. You can post a valid GeoXACML request and will get a valid Response. I am planning to finish the above issues (I am almost there), afterwards we should start a discussion about the future Geoserver security model. And yes, I think I will need some help here. And second big part is writing an admin GUI. GeoXACML is very powerfull but writing the policies is not simple at all and no user will do this. At the moment I have no capacity for creating a GUI, but without it, there will be no future for this security system :-( OK, this was not as short as announced at the beginning of the mail, but I think that it is important to know something about the main features. Chris Holmes writes: > Hey, does this mean it's now possible to define geometry security > constraints? How do you specify them? Like how's configuration done? > Does it have to go through geoxacml, or will direct requests also enforce > the geometry security constraints? (The last question may be ill-formed - > I don't quite understand what exactly geoxacml does) > > We should do a blog post when you're ready. Would be good to get nice > docs on it, we may be able to help with that. Sounds like it's gone quite > well though, it's exciting to see this capability in geoserver. > > Chris > > Christian Müller wrote: >> >> Passed all security test suites provided for the "old" security system. >> Adding tests for securing requests with geometries. >> Improved integration into the acegi (spring) security system. >> Starting geoserver with xacml successfully. >> _______________________________________________ >> SoC mailing list >> s...@lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/soc > > -- > Chris Holmes > OpenGeo - http://opengeo.org > Expert service straight from the developers. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
