Access control is a security method that regulates who can access resources in a software system. Within LuciadFusion, you can use access control to restrict access to geospatial data published by its services. LuciadFusion identifies users through authentication and authorizes them to get data through a set of access rules. This article discusses how LuciadFusion applies access control to its resources — data, products, services, styles — and how you can configure the access rules.

By default, access control is disabled in LuciadFusion. See Configuring access control for how to activate access control.

Role-based access control

Access control in LuciadFusion follows a role-based approach. You configure access to resources based on the roles that users hold within an organization.

Users and Roles aren’t managed by LuciadFusion. LuciadFusion uses Spring Security to fetch currently logged-in users and their roles. See Configuring security for more information about configuring Spring Security in LuciadFusion.

When you’re configuring access control, use the fusion.accessControl.adminRole configuration property to specify to which user-defined role you want to assign the administrator role. Users with the administrator role have full access to all resources and also to LuciadFusion Studio. For users with other roles, the configured access rules decide what access they have to LuciadFusion resources. In addition, they can’t log in to LuciadFusion Studio.

Access to Data

Configuring permissions

To configure access to Data resources, you grant permissions to a role for a certain Data resource. The permissions are:

READ

Read the actual data and metadata. Users also need this permission to see the data in a query result.

UPDATE

Update and re-crawl data, update metadata. UPDATE doesn’t allow for permission changes.

DELETE

Delete data.

MANAGE

Change permissions for data.

There’s no CREATE permission; only administrator users can add new data.

To configure access to Data, we use an access rule. It defines the permissions granted to a particular user role for a particular Data resource. For a user to access a Data resource, at least one access rule must grant the required permission to that user’s role. Only administrator users have access to Data resources without access rules.

An administrator user always has full access to a Data resource, regardless of the defined access rules.

Restricting access to scale ranges or spatial ranges

It’s possible to fine-tune access to a Data resource by restricting access to specific map scales or geographical areas. You can use this feature to prevent users from seeing the highest resolution of a raster Data resource, or to prevent them from seeing a specific area, a military base for example. These restrictions apply only to access rules with a READ permission. For example, a rule can have both READ and UPDATE permissions. In that case, the restriction applies only when a user reads the data, but not when a user updates the data.

Defining a scale range restriction

You define the scale restriction with a minimum scale denominator and a maximum scale denominator. You can use one of the two denominators, or both, to indicate between which scales you want to allow a user to consult the Data resource.

Display scale is often not uniform across a data set and is greatly affected by the chosen spatial reference system. For example, when you’re using a Mercator projection, the scales at the equator and at the poles differ significantly.

Defining a spatial restriction

You define a spatial range restriction with these parameters:

  • Area: the WKT representation of a polygon to which the spatial restriction applies. Only polygons are accepted as areas.

  • Spatial reference: the EPSG code of the spatial reference.

  • Accept: indicates with INSIDE or OUTSIDE whether the users are allowed to access the data inside or outside the area.

  • OverlappingShapes: INCLUDE, EXCLUDE or CLIP to indicate what users can see if the shape of a data item overlaps with the area bounds. This is relevant for VECTOR data only.

See the Spatial restrictions in LuciadFusion article for more information on this topic.

Not all services support scale and area restrictions. If a service doesn’t support those restrictions, it ignores them. See the access restrictions support table to find out which services support these restrictions.

Creating Data Access Rules

You can add, remove, or update the access rules through the LuciadFusion REST API only. The Studio web application doesn’t support configuring access rules. To manage the access rules for a Data resource, you need the MANAGE permission for that Data resource.

To set access rules for a Data resource, use the POST /api/data/{id}/access-rules endpoint.
To get access rules for a Data resource, use the GET /api/data/{id}/access-rules endpoint.

See the REST API Console and REST API documentation for more information on working with access rules. If a LuciadFusion instance is running, you can find the console at http://localhost:8081/api/console and the REST API documentation at http://localhost:8081/api/documentation.

Access to Products

It’s impossible to explicitly configure access permissions for Products. Instead, these permissions are derived from the permissions granted for the Data resources within a Product.

Users have read access to a Product only if they have read access to ALL Data items within a Product. Users may have access to the whole product from two distinct roles they both hold. It’s not required that the same user role grants access to each Data item in the Product. For instance, users can view a Product with two Data items if one of their roles gives them access to the first Data item and another role to the second Data item.

Only administrator users are allowed to add, update, or delete Products.

Access to Services

An authenticated user can always access a Service, but it won’t contain Products that the user doesn’t have access to. Only administrator users can add, update, or delete Services.

Only authenticated users can access all Services when enabling authentication for the service endpoints. Only allowing access to authenticated users is the recommended approach, since this is the most secure and user-friendly. It is secure because all access to Services requires the users to provide credentials. It is user-friendly because LuciadFusion will respond with a "401 Unauthorized" response if authorization is required. The client application can then handle this error by asking the user for credentials.

LuciadFusion can be configured to allow access to anonymous users, in that case it never returns a "401 Unauthorized" response when a user tries to access a service. If the service client doesn’t provide authorization credentials with the initial request, LuciadFusion treats the client as an anonymous one. To avoid being treated as an anonymous client, authenticated clients need to use preemptive authentication. Preemptive authentication means that the client provides authorization credentials with all requests, no matter if the server asks for them. For more information about allowing access to anonymous users and setting up preemptive authentication, see:

This table details how access control affects the different service types:

Service Request Description

WMS

GetCapabilities

Only contains the layers if the user has access to the corresponding product.

GetMap

Returns a NOT_FOUND status code for layers if the user has no access to the corresponding product.

GetFeatureInfo

GetLegendGraphic

WMTS

GetCapabilities

Only contains the layers if the user has access to the corresponding product.

GetTile

Returns a NOT_FOUND status code for layers if the user has no access to the corresponding product.

GetFeatureInfo

GetLegendGraphic

WFS

GetCapabilities

Only contains the features if the user has access to the corresponding product.

GetFeature

Returns a NOT_FOUND status code for features if the user has no access to the corresponding product.

WCS

GetCapabilities

Only contains the coverages if the user has access to the corresponding product.

GetCoverage

Returns a NOT_FOUND status code for coverages if the user has no access to the corresponding product.

DescribeCoverage

LTS

Query

Only contains the coverages if the user has access to the corresponding product.

GetTile

Returns a NOT_FOUND status code for coverages if the user has no access to the corresponding product.

GetResourceMetadata

CSW

All services show up in the results, but only the data that the user has access to.

FileServer

Returns a NOT_FOUND status code if the user has no access to the product the requested data item is part of.

HSPC

Returns a NOT_FOUND status code if the user has no access to the requested product for both the root file and associated files.

Panoramics

Returns a NOT_FOUND status code if the user has no access to the requested product for both the root file and associated files.

OGC 3D Tiles

Returns a NOT_FOUND status code if the user has no access to the requested product.

ECWP

Returns a NOT_FOUND status code if the user has no access to the requested product.

This table details if scale and spatial access control are supported by the various service types:

Service

Scale access control

Spatial access control

Accept

OverlappingShapes

Inside

Outside

Include

Exclude

Clip

WMS[1]

WMTS[1]

WFS[2]

WCS[3]

LTS

CSW

FileServer

HSPC

Panoramics

OGC 3D Tiles

ECWP

1. A WM(T)S service serving raster data always clips the result, regardless of the value of the 'OverlappingShapes' property.
2. A WFS service treats a 'Clip' value as 'Exclude'.
3. A WCS service always clips the result, regardless of the value of the 'OverlappingShapes' property.

Access to Styles

It’s impossible to configure access permissions for Styles. Every authenticated user can read or query the Style resources. Only administrator users can add, update, or delete Styles.

Built-in roles

In addition to the roles defined by your organization, LuciadFusion has a number of built-in roles. When the user logs in, LuciadFusion assigns one or more of the built-in roles to the user. You can use both the organization roles and the built-in roles to configure the access rules.

The built-in roles are:

LFN_ADMINISTRATOR

This role is assigned to administrator users.

LFN_AUTHENTICATED

This role is assigned to every successfully authenticated user.

LFN_ANONYMOUS

This role is assigned when the user didn’t log on.

LFN_ANY

This role is assigned to every authenticated or anonymous user.