I am not sure at the moment where to place the different components of GeoXACML
1) Policy Decision Point
This component handles xml stuff and authorization decisions, I think geotools would be the right place.
The component could be used universally (like the gml stuff)
2) Policy Enforcment Point
I would put the base classes also into geotools, doing a special implementation in geoserver
3) Policy Administration Point
This is an application for the admin, if we do that, I think geoserver is the right place
I assume that we will need a role based authorization, so we need additionally
http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf
which in turn I would place into geotools
opinions ?
Christian Müller ha scritto:
I am not sure at the moment where to place the different components of GeoXACML
1) Policy Decision Point
This component handles xml stuff and authorization decisions, I think geotools would be the right place.
The component could be used universally (like the gml stuff)
2) Policy Enforcment Point
I would put the base classes also into geotools, doing a special implementation in geoserver
3) Policy Administration Point
This is an application for the admin, if we do that, I think geoserver is the right place
I assume that we will need a role based authorization, so we need additionally
http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf
which in turn I would place into geotools
opinions ?
For the time being I would put all of them into a geoxacml community
module in GeoServer, makes it easier to develop them, build them
in one shot, and does not prevent one to move them back into
GeoTools when you're done, provided you make it clear what their
license is. GeoServer has always tried to contribute back in GeoTools
as much as possible, so nobody will try to stop you if/when you
try to push them back into GeoTools (on the contrary, as I said,
it's a welcomed move).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Moving from geoserver to geotools implies
1) changing the license statement in all java files
(btw, I have a lot of xml files for testing. I will put them in a zip file before committing.
Is it necessary to copy the licence into each xml test file. Then I will get nervous)
2) changing the package name
3) moving the documentation from the geoserver to the geotools wiki. I have no idea how to do that in a fast way.
Another question:
Since I had to fix a bug in the sun xacml implementation and I will have to do some improvements (e. g. multivalued attributes)
I took again a look at the license.
http://sunxacml.sourceforge.net/license.txt
I think there are 3 possibilities
1) I am working on the SUN code and produce my own sun-xacml.jar, asking you or Justin to put it on a repository server (do not know how many times)
2) Integrate the source code into my GeoXACML source tree (restructuring it for a mvn build and commiting as usual).
3) Doing 2) and after the code is stable remove it and doing 1)
Possibility 2) Is of course the easiest way, but what is the best for the project and what are we allowed to do ?
christian
Andrea Aime writes:
Christian Müller ha scritto:
I am not sure at the moment where to place the different components of GeoXACML
1) Policy Decision Point
This component handles xml stuff and authorization decisions, I think geotools would be the right place.
The component could be used universally (like the gml stuff)
2) Policy Enforcment Point
I would put the base classes also into geotools, doing a special implementation in geoserver
3) Policy Administration Point
This is an application for the admin, if we do that, I think geoserver is the right place
I assume that we will need a role based authorization, so we need additionally
http://docs.oasis-open.org/xacml/cd-xacml-rbac-profile-01.pdf
which in turn I would place into geotools
opinions ?
For the time being I would put all of them into a geoxacml community
module in GeoServer, makes it easier to develop them, build them
in one shot, and does not prevent one to move them back into
GeoTools when you're done, provided you make it clear what their
license is. GeoServer has always tried to contribute back in GeoTools
as much as possible, so nobody will try to stop you if/when you
try to push them back into GeoTools (on the contrary, as I said,
it's a welcomed move).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Christian Müller ha scritto:
Moving from geoserver to geotools implies
1) changing the license statement in all java files
(btw, I have a lot of xml files for testing. I will put them in a zip file before committing.
Is it necessary to copy the licence into each xml test file. Then I will get nervous)
2) changing the package name
3) moving the documentation from the geoserver to the geotools wiki. I have no idea how to do that in a fast way.
Simple, build the files directly with the gt2 package names
and license headers, just keep them in the GeoServer community
section to avoid jumping back and forth each time you have to
build them.
I'm not trying to play politics here, I just know
it's easier to keep everything under the same source tree
for build purposes, and also for eclipse project generation
so that all the modules are linked to each other in the dev
env.
That's what I did for versioning WFS, I had to put the protocol in
GeoServer and the datastore in GeoTools, and at the beginning I just
put everything inside GeoServer.
Another question:
Since I had to fix a bug in the sun xacml implementation and I will have to do some improvements (e. g. multivalued attributes)
I took again a look at the license.
http://sunxacml.sourceforge.net/license.txt
I think there are 3 possibilities
1) I am working on the SUN code and produce my own sun-xacml.jar, asking you or Justin to put it on a repository server (do not know how many times)
2) Integrate the source code into my GeoXACML source tree (restructuring it for a mvn build and commiting as usual).
3) Doing 2) and after the code is stable remove it and doing 1)
Possibility 2) Is of course the easiest way, but what is the best for the project and what are we allowed to do ?
I would go for 2), as far as I can see you just have to keep the
license headers intact:
http://sunxacml.sourceforge.net/license.txt
But it's a good idea to open bug reports again Sun for each change
you make and attach a patch, maybe refer to it from a README file
inside your code clone.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.