Christian Müller ha scritto: > Yep, working with you would make fun. And btw, it would make sense :-) > First I have to say that I have looked for a proper OSS project. I > decided to use SUNs XACML implementation as a base. > Since GeoXACML fits to a proxy architecture, I contacted some guys from > the openSSO project, which is also driven by SUN. > Another reason was that openSSO has SAML support. > I had some EMail exchange with SUN guys and the result was > 1) openSSO supports only XACML request/response but no handling of XACML > policies > 2) They will integrate SUN XACML in the future > 3) After I described my expectations how SUN has to support me, there is > a big silence :-(
Well, I'm not surprised, they have their hands full already (Sun has been cutting jobs quite a bit lately). > I think it is better and faster to do the work for geoserver. > The architecture: > The 2 main components are the Policy Decision Point (PDP) and the Policy > Enforcement Point (PEP). > PDP > The PDP should be a stand alone component, based on SUNs XACML, using > JTS and CRS stuff from geotools (otherwise I would be my own enemy) > This is possible because the PDP gets (Geo)XACML reqeuests, uses > (Geo)XACML policies and responds with (Geo)XACML responses. It should be > further possible to deploy the PDP without geoserver. If I read this correctly, the PDP is the component that decides what you can and cannot do based on the current user roles and the resource he's trying to access. This is the DataAccessManager in GeoServer, see the DefaultDataAccessManager that is based on the simple layers.properties security file. > PEP > This one could be geoserver specific. Creating the XACML request, > querying the PDP and acting on the XACML response, that's it. > Later on, we can think about 2 important components. > 1) PAP (Policy Administration Point), where the user can define its > policies which is not so easy. > 2) Do a SAML integration (openSAML) Hmmm... looking at the spec it seems PDP and PEP can be two separate services talking with each other using XML requests? This seems overkill to me? Anyways, the closest equivalent of the PEP in GeoServer is the SecureCatalog, which in fact uses the DataAccessManager extension point to allow for a pluggable authorization mechanism. Your DataAccessManager implementation could talk to the standalone PDP if you like, but I would very much like the option of an integrated PDP, extra network requests make the system more fragile and slower. Ah, another thing, the way the security it's implemented is totally transparent to dispatching and to the services, but requires some extra work at the catalog level. Basically, to make a vector example, the secure catalog takes the raw feature sources and encapsulate them with secured wrappers that will eventually throw security exceptions if the service code tries to do something the user is not authorized to (say, for example, writing). So basically you either ask the PEP what the user can do in advance given a certain layer, or you'll be forced to make wrappers that made PDP requests each time a method is called. Scale this to a situation in which you're trying to control row level access and you have a very secure but mostly unusable system (think one PDP request per feature, oh my, the very idea makes me sick). If on the contrary the PDP is integrated you can inspect the rules and know that the user can do in advance (and turn that knowledge in a set of filters against data). Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
