[Geoserver-devel] GeoXACML - 12th week report

GeoServer GeoServer Developer
1

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 :frowning:

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
SoC@anonymised.com
http://lists.osgeo.org/mailman/listinfo/soc

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

Christian Müller ha scritto:

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 ....).

Adding a tutorial with some common security setups would be very good and would also allow people to start playing with it and give you
feedback.

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.

Yeah, the changes required are not trivial, thought the result is going to be great. Think GetFeature whose results are filtered out by means
of the security constraints one specified, which can be geographic.
Can they be based on other feature attributes? I guess so, a CQL filter
is completely generic.
Row level security, woot!

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.

Mind this is true for the authorization part, GeoXacml does not deal with authentication afaik.
This means the authentication and role management is still done in
the property file (by default, one day we'll add LDAP plugins and whatnot) and using HTTP basic authentication.

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.

I believe that in order to support 5) and 6) we'll need a different
user database or a big improvement over the existing one, right?

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.

Which is something people have been asking for afaik, a way for a client
to know in advance what a user can do (before making the actual OGC request, that is).

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.

Atm I have no specific time dedicated, but I'll be available to help
and discuss with any core changes needed to open the road to a better
security subsytem

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 :frowning:

It will be harder for sure, but think about people that wrap GeoServer
in a bigger application. They are usually developers and I think some will be ready to hack some xml files if we give them enough docs and
some templates.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.