[Geoserver-users] GSIP 41 - Promote perLayerSecurity UI to extension

GeoServer GeoServer User
1

Hi list,

I created this GSIP which explains my proposal and the development state.

The proposal is available here:

http://geoserver.org/display/GEOS/GSIP+41±+Promote+perLayerSecurity+UI+to+extension

For further information please reach me via mail or on the geoserver irc channel.

Cheers,

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

2

Ciao Francesco,

I took a quick look and quite impressive. Congrats to yourself and Andrea for developing a great new module.

However, is there any reason to keep this an extension and not a core module? I think it would make sense since the security subsystem itself is core.

Francesco Izzi wrote:

Hi list,

I created this GSIP which explains my proposal and the development state.

The proposal is available here:

http://geoserver.org/display/GEOS/GSIP+41+-+Promote+perLayerSecurity+UI+to+extension

For further information please reach me via mail or on the geoserver irc channel.

Cheers,

--
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com <mailto:francesco.izzi@anonymised.com>
skype: neofx8080

web: http://www.geosdi.org

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

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

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

3

Congrats from me too. +1 for the core.

Andrea: I think this would be a good starting point for the GeoXACML integration concerning the view of the usesr. Should be possible to switch from the authorization property files to a geoxacml repository in a transparent manner.

Justin Deoliveira writes:

Ciao Francesco,

I took a quick look and quite impressive. Congrats to yourself and Andrea for developing a great new module.

However, is there any reason to keep this an extension and not a core module? I think it would make sense since the security subsystem itself is core.

Francesco Izzi wrote:

Hi list,

I created this GSIP which explains my proposal and the development state.

The proposal is available here:

http://geoserver.org/display/GEOS/GSIP+41+-+Promote+perLayerSecurity+UI+to+extension

For further information please reach me via mail or on the geoserver irc channel.

Cheers,

--
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com <mailto:francesco.izzi@anonymised.com>
skype: neofx8080

web: http://www.geosdi.org

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

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

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

4

Justin Deoliveira ha scritto:

Ciao Francesco,

I took a quick look and quite impressive. Congrats to yourself and Andrea for developing a great new module.

However, is there any reason to keep this an extension and not a core module? I think it would make sense since the security subsystem itself is core.

The are two reason I can think of:
- the UI is not consistent with the rest of GeoServer. For example, we
   still have a per line deletion link and the action links are below the
   table.
- last time I checked editing the service level security will result
   in GeoServer failing to restart because we still rely on a
   Spring class mandating that roles do start with ROLE_
   and the UI does not actually impose that anywhere

The first issue is annoying but not a blocker imho, the second one is more serious and to solve it we'd have to replace that Spring class with
a home grown one that does not impose silly restrictions:
http://jira.codehaus.org/browse/GEOS-3446

Alternatively we'd have to review the UI so that all the restrictions
are respected and remove the * usage from the service security setup

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

5

Very nice and useful module … +1 here

Eng. Alessio Fabiani
Founder / CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584 980933
fax: +39 0584 983027
mob: +39 349 8227000

http://www.geo-solutions.it
http://geo-solutions.blogspot.com

On Tue, Sep 15, 2009 at 10:14 AM, Andrea Aime <aaime@anonymised.com71…> wrote:

Justin Deoliveira ha scritto:

Ciao Francesco,

I took a quick look and quite impressive. Congrats to yourself and
Andrea for developing a great new module.

However, is there any reason to keep this an extension and not a core
module? I think it would make sense since the security subsystem itself
is core.

The are two reason I can think of:

  • the UI is not consistent with the rest of GeoServer. For example, we
    still have a per line deletion link and the action links are below the
    table.
  • last time I checked editing the service level security will result
    in GeoServer failing to restart because we still rely on a
    Spring class mandating that roles do start with ROLE_
    and the UI does not actually impose that anywhere

The first issue is annoying but not a blocker imho, the second one is
more serious and to solve it we’d have to replace that Spring class with
a home grown one that does not impose silly restrictions:
http://jira.codehaus.org/browse/GEOS-3446

Alternatively we’d have to review the UI so that all the restrictions
are respected and remove the * usage from the service security setup

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf

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

6

Andrea Aime ha scritto:
  > The first issue is annoying but not a blocker imho, the second one is

more serious and to solve it we'd have to replace that Spring class with
a home grown one that does not impose silly restrictions:
http://jira.codehaus.org/browse/GEOS-3446

I've cooked up a patch at attached it to the jira, then tested it a bit
against the UI, it seems to work fine.
However we're in RC and the change, whilst not big (it actually makes
the code much easier to understand imho) is in a very core place.
So I would like someone else to check it out, and an opinion on
whether make the change or not to allow the security GUI to function
fine

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

7

Christian Müller ha scritto:

Congrats from me too. +1 for the core.

Andrea: I think this would be a good starting point for the GeoXACML integration concerning the view of the usesr. Should be possible to switch from the authorization property files to a geoxacml repository in a transparent manner.

Mumble, if you look at the UI it's using a set of simple DAO classes
that are masking the access to the property file.
I guess they could be made into interfaces and be backed by equivalent
GeoXACML files.

It feels a little bit reductive thought, for data and service access
rules GeoXACML should be able to do so much more. It would be
nice if a simplified GeoXACML GUI could still preserve some of that
power, e.g., writing a rule that limits access to features
satisfying a certain filter and only when called by a certain service.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

8

Hi all,
thanks all for +1 votes.

It would be nice for web-security in core module, obviously making necessary changes to align it to ui.

Thanks Andre for the http://jira.codehaus.org/browse/GEOS-3446 patch.

Cheers
Francesco.

2009/9/15 Andrea Aime <aaime@anonymised.com>

Christian Müller ha scritto:

Congrats from me too. +1 for the core.
Andrea: I think this would be a good starting point for the GeoXACML integration concerning the view of the usesr. Should be possible to switch from the authorization property files to a geoxacml repository in a transparent manner.

Mumble, if you look at the UI it’s using a set of simple DAO classes
that are masking the access to the property file.
I guess they could be made into interfaces and be backed by equivalent
GeoXACML files.

It feels a little bit reductive thought, for data and service access
rules GeoXACML should be able to do so much more. It would be
nice if a simplified GeoXACML GUI could still preserve some of that
power, e.g., writing a rule that limits access to features
satisfying a certain filter and only when called by a certain service.

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

9

Regarding the uniformity of the UI in the coming days the uniform.

Cheers,

2009/9/15 Francesco Izzi <francesco.izzi@anonymised.com.2650…>

Hi all,
thanks all for +1 votes.

It would be nice for web-security in core module, obviously making necessary changes to align it to ui.

Thanks Andre for the http://jira.codehaus.org/browse/GEOS-3446 patch.

Cheers
Francesco.

2009/9/15 Andrea Aime <aaime@anonymised.com>

Christian Müller ha scritto:

Congrats from me too. +1 for the core.
Andrea: I think this would be a good starting point for the GeoXACML integration concerning the view of the usesr. Should be possible to switch from the authorization property files to a geoxacml repository in a transparent manner.

Mumble, if you look at the UI it’s using a set of simple DAO classes
that are masking the access to the property file.
I guess they could be made into interfaces and be backed by equivalent
GeoXACML files.

It feels a little bit reductive thought, for data and service access
rules GeoXACML should be able to do so much more. It would be
nice if a simplified GeoXACML GUI could still preserve some of that
power, e.g., writing a rule that limits access to features
satisfying a certain filter and only when called by a certain service.

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com

skype: neofx8080

web: http://www.geosdi.org

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

10

Thanks for the nice clear proposal; this would remove one of the only excuses for a user to duck into the filesystem - providing a better out of the box experience.

One question; can I confirm that the user interface extension is plugged in along with the security system used. Thinking of the GeoXACML work; and situations such as the GeoServer / GeoNetwork combo.

Jody

On 15/09/2009, at 1:09 AM, Francesco Izzi wrote:

Hi list,

I created this GSIP which explains my proposal and the development state.

The proposal is available here:

http://geoserver.org/display/GEOS/GSIP+41±+Promote+perLayerSecurity+UI+to+extension

For further information please reach me via mail or on the geoserver irc channel.

Cheers,

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
geoserver-devel List Signup and Options

11

2009/9/15 Jody Garnett <jody.garnett@anonymised.com>

Thanks for the nice clear proposal; this would remove one of the only excuses for a user to duck into the filesystem - providing a better out of the box experience.

Thanks Jody.

One question; can I confirm that the user interface extension is plugged in along with the security system used. Thinking of the GeoXACML work; and situations such as the GeoServer / GeoNetwork combo.

Yes the actual security management user interface is plugged in along security sub system used.

Cheers,
Francesco

Jody

On 15/09/2009, at 1:09 AM, Francesco Izzi wrote:

Hi list,

I created this GSIP which explains my proposal and the development state.

The proposal is available here:

http://geoserver.org/display/GEOS/GSIP+41±+Promote+perLayerSecurity+UI+to+extension

For further information please reach me via mail or on the geoserver irc channel.

Cheers,

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with

Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________

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

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

12

+1, looks great. One suggestion - it'd be great if there was a way for any user to sign up for an account. As far as I can tell right now the only way to add a new user is the admin doing it. And the admin setting the password.

Ideally there'd be a 'sign up' link by 'login', where a user can enter their own username and password (and indeed a password the admin would not know). Then the admin can set the permissions of what a new user can view. Ideally you might even have a role that can set user permissions but not have full access to the geoserver config.

And it'd obviously be great if the user new account interface had things like emailing a forgotten password, email confirmation, captchas, etc. Another direction to consider is allowing openid - let people sign in with their open id account.

Anyways, just some food for thought, this is a really nice start.

best regards,

Chris

Francesco Izzi wrote:

Hi list,

I created this GSIP which explains my proposal and the development state.

The proposal is available here:

http://geoserver.org/display/GEOS/GSIP+41+-+Promote+perLayerSecurity+UI+to+extension

For further information please reach me via mail or on the geoserver irc channel.

Cheers,

--
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com <mailto:francesco.izzi@anonymised.com>
skype: neofx8080

web: http://www.geosdi.org

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

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

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

13

Thanks Chris,
Your suggestion is cool.

I think, but I dont see problems for implementation.

Cheers,
Francesco

2009/9/15 Chris Holmes <cholmes@anonymised.com>

+1, looks great. One suggestion - it’d be great if there was a way for any user to sign up for an account. As far as I can tell right now the only way to add a new user is the admin doing it. And the admin setting the password.

Ideally there’d be a ‘sign up’ link by ‘login’, where a user can enter their own username and password (and indeed a password the admin would not know). Then the admin can set the permissions of what a new user can view. Ideally you might even have a role that can set user permissions but not have full access to the geoserver config.

And it’d obviously be great if the user new account interface had things like emailing a forgotten password, email confirmation, captchas, etc. Another direction to consider is allowing openid - let people sign in with their open id account.

Anyways, just some food for thought, this is a really nice start.

best regards,

Chris

Francesco Izzi wrote:

Hi list,

I created this GSIP which explains my proposal and the development state.

The proposal is available here:

http://geoserver.org/display/GEOS/GSIP+41±+Promote+perLayerSecurity+UI+to+extension

For further information please reach me via mail or on the geoserver irc channel.

Cheers,

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314

mail: francesco.izzi@anonymised.com mailto:[francesco.izzi@anonymised.com](mailto:francesco.izzi@anonymised.com)

skype: neofx8080

web: http://www.geosdi.org

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what’s new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

–
Chris Holmes

OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org

14

Hmmm, because of my work of implementing and integrating GeoXACML into geoserver, I had to dig into the spring security concept and
how geoserver uses it.

Your proposal here is about authentication (which has nothing to do with GeoXACML) and is handled in the user properties file.
This file is also the base for role assignment. I feel not comfortable by offering a possibility that anybody can get an account. And if we offer this possibility, it will not be easy to revoke it later.

As far as I have seen, geoserver should rely on the spring framework for authentication issues. Spring Security offers a lot of possibilities like using JAAS or SAML Tokens. There are a many authentication concepts covered by Spring. It should also be possible to delegate the authentication part to the J2EE Container or using certificates. In my opinion, this is not an easy topic and for the moment, it ist not a good idea to have a dynamic user database.

Btw, there is no user group concept at the moment and assigning/modifying/removing roles for every user will make the admin unhappy. From my experience with J2EE Containers, roles are always assigned to groups, a user belongs to a set of groups. Makes live easier :slight_smile:

In the near future, Andrea and me will start a community discussion about authorization with GeoXACML. Perhaps we should also discuss the authentication issue.

Opinions ?

Chris Holmes writes:

+1, looks great. One suggestion - it'd be great if there was a way for any user to sign up for an account. As far as I can tell right now the only way to add a new user is the admin doing it. And the admin setting the password.

Ideally there'd be a 'sign up' link by 'login', where a user can enter their own username and password (and indeed a password the admin would not know). Then the admin can set the permissions of what a new user can view. Ideally you might even have a role that can set user permissions but not have full access to the geoserver config.

And it'd obviously be great if the user new account interface had things like emailing a forgotten password, email confirmation, captchas, etc. Another direction to consider is allowing openid - let people sign in with their open id account.

Anyways, just some food for thought, this is a really nice start.

best regards,

Chris

Francesco Izzi wrote:

Hi list,

I created this GSIP which explains my proposal and the development state.

The proposal is available here:

http://geoserver.org/display/GEOS/GSIP+41+-+Promote+perLayerSecurity+UI+to+extension

For further information please reach me via mail or on the geoserver irc channel.

Cheers,

--
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com <mailto:francesco.izzi@anonymised.com>
skype: neofx8080

web: http://www.geosdi.org

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

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july

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

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

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

15

Christian Müller ha scritto:

Hmmm, because of my work of implementing and integrating GeoXACML into geoserver, I had to dig into the spring security concept and
how geoserver uses it.

Your proposal here is about authentication (which has nothing to do with GeoXACML) and is handled in the user properties file.
This file is also the base for role assignment. I feel not comfortable by offering a possibility that anybody can get an account. And if we offer this possibility, it will not be easy to revoke it later.

I think you and Chris are seeing GeoServer from two very different
perspectives, both valid.

You see GS as a tool in a closed organisation where someone manages
the full access to the server in a centralized way.

Chris sees is as a collaboration tool the same way a wiki or a CMS
platform is. In both the ability to register and get a set of rights
is very important, none of these platforms would manage to live long
if everybody needing access had to go and ask permissions to some
admin.

I don't agree that offering this possibility will make it hard
to revoke later thought. We just need to make it a configuration
so that the administrator can turn it on and off.

As for having groups between users and roles, yeah, I agree it's
a good idea. When the user management was first created we had
very minimal needs and even shorter time allowed for a
container independent implementation.

However, for the future I would like to make things pluggable
also on the authentication front, which will open possibilities
to other ways of managing users.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

16

Andrea Aime wrote:

Christian Müller ha scritto:

Hmmm, because of my work of implementing and integrating GeoXACML into geoserver, I had to dig into the spring security concept and
how geoserver uses it.

Your proposal here is about authentication (which has nothing to do with GeoXACML) and is handled in the user properties file.
This file is also the base for role assignment. I feel not comfortable by offering a possibility that anybody can get an account. And if we offer this possibility, it will not be easy to revoke it later.

I think you and Chris are seeing GeoServer from two very different
perspectives, both valid.

You see GS as a tool in a closed organisation where someone manages
the full access to the server in a centralized way.

Chris sees is as a collaboration tool the same way a wiki or a CMS
platform is. In both the ability to register and get a set of rights
is very important, none of these platforms would manage to live long
if everybody needing access had to go and ask permissions to some
admin.

I don't agree that offering this possibility will make it hard
to revoke later thought. We just need to make it a configuration
so that the administrator can turn it on and off.

As for having groups between users and roles, yeah, I agree it's
a good idea. When the user management was first created we had
very minimal needs and even shorter time allowed for a
container independent implementation.

However, for the future I would like to make things pluggable
also on the authentication front, which will open possibilities
to other ways of managing users.

+1, I think you hit the nail on the head Andrea. I certainly don't want to say that anyone will always be able to sign up for an account. It should definitely be an option the admin controls.

Making things pluggable on the authentication front is key, and indeed we're likely going to write some code at some point in the future that manages users in Django, but has GeoServer use those same roles. So new users will sign up through Django.

Perhaps those types of use will be the dominant use case. But as I see things right now it seems like it be nice if GeoServer helped out and had a default for people who don't want to muck with other systems.

But I agree the big potential for our security system is to integrate in all kinds of different ways with other systems. And I think the GeoXACML stuff is great, and that it should perhaps migrate to be the default way of doing things.

And +1 on user groups.

Chris

Cheers
Andrea

--
Chris Holmes
OpenGeo - http://opengeo.org
Expert service straight from the developers.

17

Hi all,

I have standardized interfaces with the rest of GeoServer.

Andrea has fixed the problem “Replace OperationSecurityInterceptor dispatcher with a callback and remove the restriction on role naming” (http://jira.codehaus.org/browse/GEOS-3446).

well

Wonder if we can pass the web-security module in the core

Cheers,
Francesco

2009/9/18 Andrea Aime <aaime@anonymised.com>

Christian Müller ha scritto:

Hmmm, because of my work of implementing and integrating GeoXACML into geoserver, I had to dig into the spring security concept and
how geoserver uses it.
Your proposal here is about authentication (which has nothing to do with GeoXACML) and is handled in the user properties file.
This file is also the base for role assignment. I feel not comfortable by offering a possibility that anybody can get an account. And if we offer this possibility, it will not be easy to revoke it later.

I think you and Chris are seeing GeoServer from two very different
perspectives, both valid.

You see GS as a tool in a closed organisation where someone manages
the full access to the server in a centralized way.

Chris sees is as a collaboration tool the same way a wiki or a CMS
platform is. In both the ability to register and get a set of rights
is very important, none of these platforms would manage to live long
if everybody needing access had to go and ask permissions to some
admin.

I don’t agree that offering this possibility will make it hard
to revoke later thought. We just need to make it a configuration
so that the administrator can turn it on and off.

As for having groups between users and roles, yeah, I agree it’s
a good idea. When the user management was first created we had
very minimal needs and even shorter time allowed for a
container independent implementation.

However, for the future I would like to make things pluggable
also on the authentication front, which will open possibilities
to other ways of managing users.

Cheers
Andrea

–
Andrea Aime

OpenGeo - http://opengeo.org
Expert service straight from the developers.

–
Francesco Izzi
CNR - IMAA
geoSDI - NSDI
Responsabile Sviluppo Software

C.da S. Loja
85050 Tito Scalo - POTENZA (PZ)
Italia

phone: +39 0971427305
fax: +39 0971 427271
mob: +39 3402640314
mail: francesco.izzi@anonymised.com
skype: neofx8080

web: http://www.geosdi.org