Hi,
here is a very quick summary of a mail exchange between me
and Christian on the GEOXACML security topic.
Christian -------------------------------------------------
Hi Andrea, I attached a picture, it shows the architecture simplified, without Policy Administration Point (PAP) and without Policy Information Point, PIP.
According to the standard, the communication between PEP and PDP are XACML requests and responses. Of course, if both components run within the same virtual machine,we can skip the xml encoding/decoding.
The idea is to have one PDP handling XACML request and responses and additionally, having a "fast" communication using java objects.
The XACML specifications say nothing about the transport bindings between PDP and PEP, so we can use http, tcpip and also main memory.
Relying on one PDP, there will be many PEPs (for WMS,WFS,....). These PEPs will be encoded optimized for Geosever.
The PDP should be universal and not tied to geoserver.
To give an example. A J2EE Containter allows you to write JAAS plugins. (Some time ago, I had to develop such plugins).
For a web container, its like a servlet filter, but it works also for an ejb container. Implementing a proper PEP should be possible. Or image, another OS project written in PERL or PYTHON would like to use the PDP. Implementing a PDP encoded in PERL producing proper XACML requests should be possible.
Andrea ----------------------------------------------------
If you want to go down this road I won't stop you, but I believe making
a PEP per service is a mistake in terms of maintenance and
evolution. It does not seem to offer anything better that what is
already provided by existing security proxies, such as the 52n and
the DeeGree ones:
http://52north.org/maven/project-sites/security/
https://wiki.deegree.org/deegreeWiki/iGeoSecurity
(beyond the usage of XACML, that is)
These services have the significant downside that they can only
protect what they know about. Say you have implemented a WMS and
a WFS PEP, and they work for you. Then someone adds a WPS service...
and to secure it, you have to write you own new PEP (and WPS requests
can be stupidly long and complex, as you can nest them at your leisure,
calling 100 processes in chain with a single request).
The next day you realize that you want to use versioning WFS, and
guess what, it has new operations and new transaction elements.
You have to write another PEP.
Then some other summer of code student writes a RESTful WFS. Wanna
secure it? Sure, write another PEP, easy no?
Then someone finds out he needs to use WMS POST requests, or
WMS requests that take a remote SLD. Too bad your WMS PEP does not
know how to parse an SLD, so it either refuses those calls, or
it lets them go without securing them. Solution? Go and add the
necessary code to the WMS PEP!
It's all very doable, but all very expensive too. Why do we have
to take such pain? And what do we really want to do when securing data?
If all you want to is say, is, for example:
"if the user has role X then it can access only properties A and B
and records that match accessLevel < 3"
well, then, you're expressing yourself in terms of pure data access,
there is no need to understand 10 different protocol, all you have to
do is to place the PEP at the data access level instead of at the
protocol level, and as a consequence, all protocols will be secured,
with a single, reusable, heavily tested security system (another
issue with duplication of PEP is testing, the more you have around,
the more likely some PEP will have some issues in less common
request types).
So why would one need a service level PEP? Well, you actually _need_
one if your security requirements are expressed in terms of service
access:
"if the user has role X then he cannot ask WMS images bigger than
500x500"
or
"if the user does not have role Y then he cannot call the GetLog
request of the versioning WFS protocol"
Operational reality is a little more complex. For example, I had
users that expressed the need to limit the number of people that
can access certain featureType from WFS GetFeature, or from
WMS GetFeatureInfo, while still allow WFS GetMap to access every
attribute for symbolization purposes. The idea is, WMS uses
the attribute to make a thematic map, that returns colors based
on classes, but does not allow to infer the actual value of the
depicted attribute.
So this is a case in which both service concerns and data access
concerns have to be expressed at the same time. I thought about
handling this, and the idea is that the GeoServer code can
actually access, at any time, the parsed request, as it's stored
inside a thread local variable.
So I told myself, well, we can use that to provide "context" to
the data access security subsystem and constraint rules based
on both data and service points of view. If we consider RESTful
calls, the context can simply be the URL of the requested
resource. If we consider OGC services, the context can be service,
version and request type, something like /wfs/1.0.0/GetFeature.
A data access rule could then be:
/wfs/1.0.0/GetFeature + typeName=xxx + filter=att<3 ->
UserRoles.include(ROLE_XYZ)
to make sure GetFeature on type xxx allows access to records
with att<3 only to users wtih ROLE_XYZ.
The take out of this is that in my opinion the main PEP should not
be placed around the services, but around the data access itself.
Per service PEP could still be implemented to:
- handle service specific constraints
- cook the service request into a "context" that the catalog
level PEP can use to mix togheter service and data access
concerns (or if you want, to enhance the context in which
it makes the decisions, which is currently based only on
user roles and data accessed)
This would avoid you to check WMS data access taking into
consideration the 4 possible ways in which users can build their
own filters:
- accept the built in SLD with filtering rules
- user provided SLD via the &sld=http://url/to/my/sld
- custom filters specified with &filter, &cql_filter, &feature_id
(these are GeoServer vendor extensions)
- user provided SLD in a POST WMS request
To be fair, you can avoid this mess also by implementing the PEP
as a dispatcher plugin, so that you inspect the requests only
after parsing occurred. But I guess it makes it clear why I
believe pure proxy implementations such as the DeeGree or 52N
ones are quite a failure. I follow a few customers of OpenGeo,
none of them is actually using _only_ the standard parts of
the protocols, each of them is actually using one or more
vendor extensions that we do provide on top of the existing
protocols, or one of the RESTFul services we are slowly including
in GeoServer lately.
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
(attachments)
