Add methods to ResourceAccessManager and CatalogFilter to allow them to build the filter currently built by SecureCatalogImpl.

Kevin Smith

2.6

Under Discussion

Catalog queries against large JDBCConfig backed catalogs can be severly impacted by the presence of filters that are not “well known”. Moving responsibility for building the security filter to the ResourceAccessManager which determines which objects need to be filtered, allows for well known filters to be used when it is possible to do so.

The following method would be added to ResourceAccessManager

Filter ResourceAccessManager.getSecurityFilter(Authentication user, Class<? extends CatalogInfo> clazz)

This would return a Filter which when applied to a CatalogInfo would remove it if the getAccessLimits would have hidden it by returning an AccessLimits that specified that the user can’t read it, and that non-readable should be hidden.

SecureCatalogImpl can then use that filter rather than building one which retreives the AccessLimits and checks whether it should hide the object based on that.

CatalogFilterAccessManager bases its filtering on CatalogFilter objects.  Extending that interface in the same way would allow CatalogFilterAccessManager to build well known filters if all of its CatalogFilters produce well known filters.

Filter CatalogFilter.getSecurityFilter(Class<? extends CatalogInfo> clazz)

This section should contain feedback provided by PSC members who may have a problem with the proposal.

• email discussion

AllowAllResourceAccessManager which just allows access to everything would have a getSecurityFilter like this

public Filter getSecurityFilter(Authentication user, Class clazz) {
    return Predicates.allowAll();
}

While WorkspaceCatalogFilter which hides one specific workspace might have a getSecurityFilter like this:

public Filter getSecurityFilter(Class clazz) {
    if(WorkspaceInfo.class.isAssignableFrom(clazz)) {
        return Predicates.not(Predicates.equals("id", workspace.getId()));      } else {
        return Predicates.not(Predicates.equals("workspace.id", workspace.getId()));    
    }
}

By implementing the methods on AbstractResourceAccessManager and AbstractCatalog the “old way” any class extending them will be automatically compatible, and if well known filters are only sometimes possible, implementations can use the default as a fallback as in this example from DataAccessManagerAdapter.

@SuppressWarnings("deprecation")
@Override
public Filter getSecurityFilter(Authentication user, Class clazz) {
    if(delegate.getMode()==CatalogMode.CHALLENGE)
    // If we're in CHALLENGE mode, everything should be visible           
        return Predicates.acceptAll();
    else
        return super.toFilter(user, clazz);
}

This adds new methods to interfaces used as public extension points.   GeoFence and GeoShield use these extension points.

Alessio Fabiani: +1 Andrea Aime: +1 Ben Caradoc Davies: Christian Mueller: Gabriel Roldan: +1 Jody Garnett: +1 Jukka Rahkonen: +0 Justin Deoliveira: +1 Phil Scadden: Simone Giannecchini:

GEOS–6430 Email Discussion