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 |
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
orOUTSIDE
whether the users are allowed to access the data inside or outside the area. -
OverlappingShapes:
INCLUDE
,EXCLUDE
orCLIP
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. |
|
MBTiles |
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 |
✖ |
✖ |
✖ |
✖ |
✖ |
✖ |
MBTiles |
✖ |
✖ |
✖ |
✖ |
✖ |
✖ |
Panoramics |
✖ |
✖ |
✖ |
✖ |
✖ |
✖ |
OGC 3D Tiles |
✖ |
✖ |
✖ |
✖ |
✖ |
✖ |
ECWP |
✖ |
✖ |
✖ |
✖ |
✖ |
✖ |
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.