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 :-( 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. 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) christian Andrea Aime writes: > Christian Müller ha scritto: >> Jody I have not a seen a page for project proposals for geoserver. >> (or should we use the one created for geotools). >> >> I am not sure at the moment, but I have an idea doing a GeoXACML >> implementation which could deployed in geoserer as a servlet filter. > > The idea of a GEOXAML driven security subsystem is certainly > a very good one, I would be interested in mentoring you in this one. > > However, I would rather suggest not to implement it as a servlet > filter. There are quite some good reasons to avoid it: > - it has to replicate part of the work GeoServer is already doing > (the request parsing) > - it is limited to the kind of request it can parse (say tomorrow > we add WPS, or a restful WFS, or just SOAP request types for > the existing services) > > You have two lower level options at your disposal: > - a dispatcher plugin, that receives the requests in a parsed > form already. Yet, that still requires you to know all the > possible kinds of requests (just skips the parsing machinery) > - a geoserver security subsystem plugin, replacing the current > DataAccessManager implementation with a custom one that is > driven by GEOXAML directives > > I cannot find much information about GEOXAML, and XAML itself > it huge, so it's likely that you'll find some limitations in > the current security subsystem extension points, but I can > work along with you and make the necessary changes to allow > a GEOXAML driven plugin to work at its full potential. > > Interested? > 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
