by Julia
During the summer of 2020/2021, I had the pleasure of being an intern at Catalyst IT as a software engineer in the GIS team. Initially having only a vague notion that “GIS” had something to do with spatial data, I was excited to learn more about it and how I could contribute to the open source community.
Keycloak Role Service integration for GeoServer
My first major task was to allow Keycloak to be used as a role service for GeoServer, such that when a user logs into GeoServer via Keycloak, their Keycloak roles are carried through and recognised. Keycloak is an open source application for identity and access management, which makes it well suited for implementing single sign-on. GeoServer is also open source and is a web server that enables the sharing, processing, and editing of geospatial data.
The first hurdle was to become familiar with GeoServer’s role system and develop an understanding of how roles integrate with authentication and authorisation. Being a large, complex, and thoroughly established codebase, it was quite daunting to begin trying to understand how role services worked. Fortunately, my previous experience with large codebases came into play, and I began to walk my way through the GeoServer authentication process, searching for similarities between existing role services. Once I had identified several key components within the system, it became easier to piece the puzzle together and determine what I would need to implement for a Keycloak role service.
Having no prior experience with GeoServer, I found it challenging at times to test whether my changes had the desired outcome. To verify that the Keycloak role service was giving users the correct set of permissions, I needed to create several layers with different viewing access restrictions. A layer in GeoServer is a data object which represents geographic features. As I was unfamiliar with how GeoServer works, on occasion I struggled to determine whether my Keycloak role service was not acting as intended, or I had simply not set up my environment correctly. Much of the layer creation contained technical jargon which I had not come across before, as I had not previously worked in the GIS area GeoServer is concerned with. Thankfully much of GeoServer has accompanying documentation, and as I became more familiar with GeoServer, it grew easier to recognise my changes as compared to a misconfiguration.
Keycloak Authentication with MapStore2 and GeoStore
My second task was to integrate Keycloak authentication into GeoStore, and thereafter MapStore2. MapStore2 is a modular web interface for creating, managing and sharing maps and dashboards. GeoStore acts as the back end for MapStore2, so any login attempts into MapStore2 will authenticate against GeoStore. As such, logging in via Keycloak would require handling within both systems.
To figure out what I would need to do for Keycloak authentication, I began by looking at the existing “alternate” methods of logging into GeoStore. From this, I deduced that my options were to implement either an authentication provider or a form of token-based authentication. Having researched both alternatives and drawn up a table of pros and cons, at the time I decided that an authentication provider was the way to go. However, this proved remarkably difficult to implement and would end up being far too closely knit with GeoStore’s existing code to be a simple extension. After exhausting all identified authentication provider options, I revisited the idea of token authentication from a different angle. This time around, I stumbled across GeoStore’s existing filter for token-based authentication, which looked remarkably promising! Using the existing code as a starting point, I was able to implement my own Keycloak token authentication filter and have it configurable from a file. I found it very challenging to change tack from trying to implement an authentication provider, to understanding token-based authentication. It was very easy to get stuck in the mindset that the current solution is the best option, especially with how much time I had invested. This experience has helped me to better recognise when it’s time to re-evaluate the situation, and whether the implementation I am pursuing is still viable. Additionally, writing out the pros and cons for each possible solution was (oddly) something I had never taken the time to do. I found it greatly helped me clarify within my mind the differences between the options, and in future, I will try to do it more often!
As I was tasked with enabling Keycloak login into MapStore2 and GeoStore, it was a new experience for me to work on both the front and back ends of a system. During my studies, it was quite typical for team members to become specialised in one side of the codebase, simply to lessen the up-front load of learning new tools and languages. Experiencing development for both MapStore2 and GeoStore has given me a greater appreciation for how the two sides communicate and collaborate.
Contributing to an upstream project
Once all my changes had been tested and reviewed within Catalyst, it was time to create a merge request to the upstream branches. As all my previous work had remained internal to where I worked or studied, proposing my changes for the open source community to review was incredibly intimidating! Not only was my code up for review by people I didn’t know; if my changes got approved the features I implemented may eventually be used by other people. Additionally, large, established codebases can have unwritten style rules and structures that can be difficult to pick up on, which doesn’t make contributing any less daunting. Thankfully everyone at Catalyst was highly supportive and helped to make the process as smooth as possible.
An invaluable learning experience
Having little prior domain knowledge, interning at Catalyst has opened my eyes to the world of GIS and open source software development. I’m glad to have learned they’re not as intimidating as they initially appear! My internship experience has bolstered my confidence in contributing to open source projects and has given me a wide range of new skills that I can use in future software development. Overall I’ve had a wonderful time at Catalyst, and I am looking forward to contributing to more open source software projects in the future.