[Geoserver-devel] GeoServerRole.ADMIN_ROLE vs. GeoServerRoleService.getAdminRole()

GeoServer GeoServer Developer
1

Hi all, I’m looking into bringing GeoNode’s security extensions in line with the changes merged last week. Prior to the changes, GeoNode simply assigned ROLE_ADMINISTRATOR to users with admin privileges - but afterward this seems insufficient for a user to make changes in the REST API. When I spoke with Justin, he recommended using the following code to dynamically retrieve the administrative role from the current role service.

GeoServerSecurityManager manager = GeoServerExtensions.bean(GeoServerSecurityManager.class);
GeoServerRoleService roleService = manager.getActiveRoleService();
GeoServerRole effectiveAdmin = roleService.getAdminRole();

This didn’t quite do the trick and, after some digging, we ended up giving admin users both this effectiveAdminRole and GeoServerRole.ADMIN_ROLE. A debugger shows that this is what’s happening in the default configuration as well - if you log in as administrator in the default GeoServer configuration on trunk, you’ll be a user with both “ADMIN” (the default admin role for the default service) and “ROLE_ADMINISTRATOR” (the reserved system role.) I guess this means that AuthenticationProviders are responsible for the “mapping” between ADMIN_ROLE and the local admin role mentioned in http://jira.codehaus.org/browse/GEOS-5101 ? Is that appropriate/intended?

–
David Winslow
OpenGeo - http://opengeo.org/

2

Hey David,

I think Christian is going to have to weigh in here but yes, as it stands right now it seems the authentication provider has the responsibility of adding both the “psuedo” ROLE_ADMINISTATOR and whatever the active role service has the admin role.

Looking at how this happens with the default authentication privider, the chain is basically this.

  1. UsernamePasswordAuthetnication provider authenticates by looking up the user in the local xml user group database
  2. XMLuserGroupService loads the user, and calculates the assigned role
  3. XMLuserGroupService delegates to the RoleCalculator class to basically check for the local admin role, and when present addes in the pseudo role as well

So I guess authentication providers could/should make use of RoleCalculator to do the same. It would however be nice if this was more explicit.

An alternative for the geonode security plugin could be to implement a custom user group service rather than a custom authentication provider… or perhaps both.

On Wed, Jun 27, 2012 at 4:43 PM, David Winslow <dwinslow@anonymised.com> wrote:

Hi all, I’m looking into bringing GeoNode’s security extensions in line with the changes merged last week. Prior to the changes, GeoNode simply assigned ROLE_ADMINISTRATOR to users with admin privileges - but afterward this seems insufficient for a user to make changes in the REST API. When I spoke with Justin, he recommended using the following code to dynamically retrieve the administrative role from the current role service.

GeoServerSecurityManager manager = GeoServerExtensions.bean(GeoServerSecurityManager.class);
GeoServerRoleService roleService = manager.getActiveRoleService();
GeoServerRole effectiveAdmin = roleService.getAdminRole();

This didn’t quite do the trick and, after some digging, we ended up giving admin users both this effectiveAdminRole and GeoServerRole.ADMIN_ROLE. A debugger shows that this is what’s happening in the default configuration as well - if you log in as administrator in the default GeoServer configuration on trunk, you’ll be a user with both “ADMIN” (the default admin role for the default service) and “ROLE_ADMINISTRATOR” (the reserved system role.) I guess this means that AuthenticationProviders are responsible for the “mapping” between ADMIN_ROLE and the local admin role mentioned in http://jira.codehaus.org/browse/GEOS-5101 ? Is that appropriate/intended?

–
David Winslow
OpenGeo - http://opengeo.org/

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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

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

3

Hi David, Justin

Unfortunately, I never worked with “GeoNode” and I have no idea about the architecture. I fear I am not able to understand the problem exactly. Anyways, some ideas.

  1. For the default (XML) role service, it should be sufficient to assign the local administrator role “ADMIN”. Since it is possible to have more role services, you have the possibility to map one role of each role service to ROLE_ADMINISTRATOR. During role calculation in class RoleCalculator, ROLE_ADMINISTRATOR is injected for users having such a mapped role like “ADMIN”.

  2. There is a special user called “root” which has always assigned ROLE_ADMINISTRATOR. The default password (master password) is “geoserver”. For Geoserver, there is no need to have a special admin account, simply use the “root” users.

Again, I am not sure if this helps, if not, I need some further details.

  1. The RoleCalculator class is responsible for calculating the roles.

2012/6/29 Justin Deoliveira <jdeolive@anonymised.com>

Hey David,

I think Christian is going to have to weigh in here but yes, as it stands right now it seems the authentication provider has the responsibility of adding both the “psuedo” ROLE_ADMINISTATOR and whatever the active role service has the admin role.

Looking at how this happens with the default authentication privider, the chain is basically this.

  1. UsernamePasswordAuthetnication provider authenticates by looking up the user in the local xml user group database
  2. XMLuserGroupService loads the user, and calculates the assigned role
  3. XMLuserGroupService delegates to the RoleCalculator class to basically check for the local admin role, and when present addes in the pseudo role as well

So I guess authentication providers could/should make use of RoleCalculator to do the same. It would however be nice if this was more explicit.

An alternative for the geonode security plugin could be to implement a custom user group service rather than a custom authentication provider… or perhaps both.

On Wed, Jun 27, 2012 at 4:43 PM, David Winslow <dwinslow@anonymised.com> wrote:

Hi all, I’m looking into bringing GeoNode’s security extensions in line with the changes merged last week. Prior to the changes, GeoNode simply assigned ROLE_ADMINISTRATOR to users with admin privileges - but afterward this seems insufficient for a user to make changes in the REST API. When I spoke with Justin, he recommended using the following code to dynamically retrieve the administrative role from the current role service.

GeoServerSecurityManager manager = GeoServerExtensions.bean(GeoServerSecurityManager.class);
GeoServerRoleService roleService = manager.getActiveRoleService();
GeoServerRole effectiveAdmin = roleService.getAdminRole();

This didn’t quite do the trick and, after some digging, we ended up giving admin users both this effectiveAdminRole and GeoServerRole.ADMIN_ROLE. A debugger shows that this is what’s happening in the default configuration as well - if you log in as administrator in the default GeoServer configuration on trunk, you’ll be a user with both “ADMIN” (the default admin role for the default service) and “ROLE_ADMINISTRATOR” (the reserved system role.) I guess this means that AuthenticationProviders are responsible for the “mapping” between ADMIN_ROLE and the local admin role mentioned in http://jira.codehaus.org/browse/GEOS-5101 ? Is that appropriate/intended?

–
David Winslow
OpenGeo - http://opengeo.org/

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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.

Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

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