top of page

How to Secure GeoServer Layers with Role-Based Access and Token Authorization

Introduction

Imagine you're building a geospatial dashboard for city planners in Bengaluru. Your team publishes layers like traffic density, fiber cable layouts, and sensitive infrastructure. But without proper access control, these datasets are exposed to the public or could be edited by unauthorized users — a serious risk in urban planning.


In this blog, you'll learn how to secure your GeoServer layers using Role-Based Access Control (RBAC) and Token-Based Authentication. We'll walk through step-by-step configurations, including user and role setup, permission enforcement, and how to integrate modern token-based login systems like OAuth2 and JWT. Whether you're deploying public dashboards or internal analytics tools, this guide will help you build secure and scalable geospatial applications.


Step-by-Step Guide

1. Why GeoServer Layer Security is Critical

GeoServer is widely used to serve geospatial data through OGC standards like WMS (Web Map Service) and WFS (Web Feature Service). By default, these services are open and accessible to anyone with the URL — making them vulnerable to unauthorized use if not properly secured.

Open access might be acceptable during initial development or for public datasets. However, in most production environments, it poses serious risks.To prevent risks, it's essential to implement structured access control mechanisms that define who can access what, and under what conditions.

Securing your GeoServer environment helps ensure:

  • Data privacy — only authorized users view or interact with specific layers.

  • Controlled service usage — prevent abuse and manage traffic load.

  • Role-based data delivery — show different layers or resolutions based on user roles.

  • Compliance with internal IT and data governance policies — especially when working on governmental, infrastructure, or private projects.

2. GeoServer Security Architecture Overview

GeoServer comes with a flexible, role-based security framework that allows you to control access at various levels — from users and services to specific layers.

  • Users: These are individual login accounts used to identify and authenticate people accessing GeoServer. Each user can be assigned one or more roles to control their access rights.

  • Roles: Roles define sets of permissions (read, write, admin, etc.) and are assigned to users or groups. They determine what actions a user can perform on services and data layers.

  • Workspaces/Layers: Workspaces organize related layers and allow permissions to be set at a group level. Layers within a workspace inherit access rules unless overridden individually.

You can define permissions such as read-only or full access for each role. GeoServer then enforces these rules automatically — for example, a WMS request from a ROLE_VIEWER user will not be able to access layers restricted to ROLE_ADMIN.

3. Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC) allows you to manage who can access which datasets and what actions they can perform (read, write, admin). It’s one of the most effective ways to control access in GeoServer, especially when working with multiple users or exposing your services through a web GIS frontend.


Groups, Roles, and Users in GeoServer

To simplify and scale GeoServer access control, it's efficient to define roles at the group level first, then just assign users to those groups. This ensures consistent permissions and reduces manual overhead.


Path
Groups, Roles, and Users in GeoServer
Users and Groups Panel in GeoServer
Users and Groups Panel in GeoServer
Step 1: Create Groups

Start by creating user groups based on access levels. Later, roles will be assigned directly to these groups.

Create these groups:

  • group_reader – for read-only access

  • group_editor – for both read and edit access

Path
Step 1: Create Groups
  • Click Add new group

  • Enter group name (group_reader or group_editor)

  • Save

group_reader or group_editor
Step 2: Create Roles and Assign Them to Groups

Now define roles and map them to the corresponding groups.

Roles to create:

Role Name

Parent Role

Assigned Group

ROLE_READER

(None)

group_reader

ROLE_EDITOR

ROLE_READER

group_editor

Path
Step 2: Create Roles and Assign Them to Groups
  • Click Add new role

  • Define role name and optionally set a parent role (e.g., ROLE_READER for ROLE_EDITOR)

  • Assign the role to the appropriate group in the “Assign to Groups” section

Creating a Role with Inheritance in GeoServer
Creating a Role with Inheritance in GeoServer
Why role inheritance
Why role inheritance

This way, ROLE_EDITOR users also get all ROLE_READER capabilities without duplicating settings.

Step 3: Create Users and Assign to Groups

Finally, add users and assign them to the previously created groups. Users will automatically inherit roles based on their group membership.

Create these users:

Username

Group

Inherited Role

User 1

Group_Reader

Role_reader

User 2

Group_ Editor

Role_editor

Path:
Path
  • Click Add new user

  • Fill in username and password

  • Assign to appropriate group and role

Step 4: Apply Data Security Rules Based on Roles

Now define access rules for your GeoServer layers, using the roles that are automatically inherited via group membership.

Path:
Path
Granting Read Access to a Layer for role_reader
Granting Read Access to a Layer for role_reader
Example 1: Read Access for role_reader
  • Workspace: topp

  • Layer: tasmania_cities

  • Allowed Role: role_reader


Users with the role_reader role can view this layer on the map.

Other users (like editors) can still see it, but viewers are restricted to just this layer.

Example 2: Write Access for role_editor
  • Workspace: topp

  • Layer: tasmania_roads

  • Allowed Role: role_editor

Users with the role_editor role can edit this layer (such as updating roads).

View-only users (like those with role_reader) cannot make any changes.

Benefits of Using RBAC in GeoServer:
  • Granular control over who can view or modify data.

  • Easy scaling: New users can be assigned roles without editing every layer.

  • Organized access: Keep workspaces and permissions clean and manageable.

  • Auditability: You can trace access or misuse by user role and timestamp

4. Token-Based Authentication in GeoServer (JWT/OAuth2)

In modern web apps and dashboards, logging in with a username and password alone is not enough — especially when serving sensitive GIS data. This is where Token-Based Authentication helps.

A JWT (JSON Web Token) is a small digital key that a user receives after logging in. This token is added to every API request to GeoServer. GeoServer reads the token, checks the user’s role, and allows or denies access.

Why Use Token Authentication?
  • No need to maintain server-side sessions (stateless)

  • Ideal for frontends built with React, Dash, or mobile apps

  • Tokens include user roles, so GeoServer can enforce layer access rules

  • Works with identity providers like Google, Auth0, or Keycloak

Example: A React dashboard with Mapbox can send tokens with each WMS/WFS request to GeoServer — ensuring only the right users get the right data.

How Does GeoServer Handle Tokens?
Option A: GeoFence Plugin
  • Easy-to-use plugin with a UI to manage access policies

  • Supports rules based on user, role, layer, or even IP address

  • Stores rules in a database (e.g., PostgreSQL)

Use this if your team prefers a low-code solution with visual rule management.

Option B: Spring Security Extension
  • Allows GeoServer to validate JWT tokens at the backend

  • Needs developer setup (XML config + token filter)

  • Good for integrating with enterprise login systems (like Keycloak)

Recommended for advanced users with backend access.

5. Frontend Integration (React, Dash, etc.)

Once tokens are issued after login, they must be sent in the header of every GeoServer request.

Example using Axios (JavaScript):
Example using Axios (JavaScript)
Example using Fetch:
Example using Fetch
Storing Tokens Securely
  • Use sessionStorage so tokens clear when the browser is closed

  • Avoid localStorage (it’s less secure)

  • Use HttpOnly cookies if your token is handled by the server

sessionStorage.setItem("accessToken", token);

Bonus Tip: Show Layers Based on Role

You can also load different layers in the frontend depending on the user's role stored inside the token:

Show Layers Based on Role
6. Real-World Example: Bengaluru Fiber Network Dashboard

Let’s say you’re managing a fiber network map of Bengaluru using GeoServer. Different users need different levels of access:

Layer Name

Description

Access Role

public:fiber_coverage

Public service coverage area

ROLE_VIEWER

private:line_faults

Field faults reported by engineers

ROLE_EDITOR

admin:core_routes

Internal planning & backbone routes

ROLE_ADMIN

Role-Based Access in Action:
  • Public Users (ROLE_VIEWER):

Can view fiber_coverage to check service availability.

  • Field Engineers (ROLE_EDITOR):

Can update line_faults using WFS-T (editing service).

  • Admin Team (ROLE_ADMIN):

Can view and edit all layers, upload new files, and monitor API usage.

This setup uses both RBAC and token authentication to ensure each user only sees what they’re authorized to — protecting your infrastructure while enabling collaboration.


7. Best Practices
  • Always use HTTPS to protect tokens

  • Rotate JWT secrets regularly

  • Use short-lived tokens + refresh tokens

  • Audit role access monthly

  • Combine roles + tokens for layered security


Conclusion

GeoServer provides powerful tools for serving spatial data — but with great power comes great responsibility. By implementing Role-Based Access Control and Token-Based Authentication, you ensure that only the right users access the right data. This not only protects your infrastructure but also builds trust in the applications you develop.


AGSRT offers professional training on GeoServer and secure Web GIS deployment. Check out our advanced GIS development courses to upskill your team!

Bonus: Resources

- JWT Token Debugger: https://jwt.io/

Comments


bottom of page