[Geoserver-devel] How to integrate customized security backends

GeoServer GeoServer Developer
1

This is a design question for my GSOC 2011 project, enhancing geoserver security.

I have to main interfaces, GeoserverUserGroupService and GeoserverGrantedAuthorityService for managing user/groups and role assignments.

I developed some implementations (in memory, xml and jdbc) which will be shipped with geoserver. Additionally, I want to offer the possibility to develop custom implementations and a mechanism to plug them in.

My idea is similar to the java protocol handlers as described here

http://download.oracle.com/javase/1.4.2/docs/api/java/net/URL.html

using a system property called java.protocol.handler.pkgs.

Description of this concept adapted to geoserver security:

1) Introduce a system property named
org.geoserver.security.pkgs
2) The value of the property is a list of package names delimited by "|"
3) The last component of the package name is the name for the customized implementation.

Example:

-Dorg.geoserver.security.pkgs=org.mycompany.security.test1 | org.mycompany.security.test2

At runtime, I will look into these two packages for classes named
GeoserverUserGroupServiceImpl or GeoserverGrantedAuthorityServiceImpl. If the classes are there (or at least one of them), I will check if the classes implement the interfaces mentioned above. On success, the runtime registers the new implementations (singletons) using test1 and test2 as names.

Opinions, better ideas ?

Cheers
Christian

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

2

Could it possibly work the same way that our datastores do? With a service provider interface that goes in META-INF? I think outputformats go the same way in GeoServer (though it’s been far too long since I’ve developed). Seems like it’d be best to match how we do things in the rest of GeoServer, and datastores and outputformats can both be plugged in by putting a jar in the right place.

On Wed, Jul 27, 2011 at 2:26 AM, <christian.mueller@anonymised.com> wrote:

This is a design question for my GSOC 2011 project, enhancing
geoserver security.

I have to main interfaces, GeoserverUserGroupService and
GeoserverGrantedAuthorityService for managing user/groups and role
assignments.

I developed some implementations (in memory, xml and jdbc) which will
be shipped with geoserver. Additionally, I want to offer the
possibility to develop custom implementations and a mechanism to plug
them in.

My idea is similar to the java protocol handlers as described here

http://download.oracle.com/javase/1.4.2/docs/api/java/net/URL.html

using a system property called java.protocol.handler.pkgs.

Description of this concept adapted to geoserver security:

  1. Introduce a system property named
    org.geoserver.security.pkgs
  2. The value of the property is a list of package names delimited by “|”
  3. The last component of the package name is the name for the
    customized implementation.

Example:

-Dorg.geoserver.security.pkgs=org.mycompany.security.test1 |
org.mycompany.security.test2

At runtime, I will look into these two packages for classes named
GeoserverUserGroupServiceImpl or GeoserverGrantedAuthorityServiceImpl.
If the classes are there (or at least one of them), I will check if
the classes implement the interfaces mentioned above. On success, the
runtime registers the new implementations (singletons) using test1 and
test2 as names.

Opinions, better ideas ?

Cheers
Christian

This message was sent using IMP, the Internet Messaging Program.

Got Input? Slashdot Needs You.
Take our quick survey online. Come on, we don’t ask for help often.
Plus, you’ll get a chance to win $100 to spend on ThinkGeek.
http://p.sf.net/sfu/slashdot-survey

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

3

On Wed, Jul 27, 2011 at 8:26 AM, <christian.mueller@anonymised.com> wrote:

Opinions, better ideas ?

The above would be quite uncharacteristic for GeoServer, I would like
to avoid having a third way to make plugins.

All Geotools plugins use the SPI subsystem that Chris is referring to.
All GeoServer plugins use Spring context scans instead based
on the GeoServerExtensions class.
All WMS/WFS output formats are found that way for example,
same goes for annotated WPS processes, OGC services,
KVP and XML parsers and so on.

In case you have to find a single implementation the pattern to
follow would be:
- check if there is an implementation of a certain interface in the
  Spring context using GeoServerExtensions.bean(Class type)
- if any is available, use that one
- if none is found programmatically instantiate a default one instead.

The authorization subsystem already works that way, it searches
for a resource access manager, if not found looks for the
old interface, DataAccessManager, if none is found it just builds
the default one instead (wrapping it in the LocalWorkspacesResourceAccessManager
to get the per workspace services behavior):

static ResourceAccessManager lookupResourceAccessManager() throws Exception {
        ResourceAccessManager manager =
GeoServerExtensions.bean(ResourceAccessManager.class);
        if (manager == null) {
            DataAccessManager daManager = lookupDataAccessManager();
            manager = new DataAccessManagerAdapter(daManager);
        }
        LocalWorkspaceResourceAccessManager lwManager = new
LocalWorkspaceResourceAccessManager();
        lwManager.setDelegate(manager);
        return lwManager;
    }

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------