MASARYK
U N I V E R S I T Y
FACULTY OF INFORMATICS
Design and implementation of a
unified user request system with
self-service and identity
consolidation
Master's Thesis
MARIO NOVAK
Brno, Fall 2025
MASARYK
U N I V E R S I T Y
FACULTY OF INFORMATICS
Design and implementation of a
unified user request system with
self-service and identity
consolidation
Master's Thesis
MÁRIO NOVÁK
Advisor: RNDr. Stanislav Špaček, Ph.D.
Department of Computer Systems and Communications
Brno, Fall 2025
Declaration
Hereby I declare that this paper is my original authorial work, which
I have worked out on my own. A l l sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.
AI Use Declaration
During the preparation of this thesis, I used the following AI tools:
• Grammarly for grammar check and text improvements,
• DeepL to translate and find synonyms,
• ChatGPT to search for relevant sources and documentation.
I declare that I used these tools in accordance with the principles of
academic integrity. I checked the content and took full responsibility
for it.
Mario Novák
Advisor: RNDr. Stanislav Špaček, Ph.D.
iii
Acknowledgements
I want to thank my advisor, RNDr. Stanislav Špaček, PhD, for continuous
guidance and time flexibility during the text's creation. I also
want to thank my consultant, RNDr. Daniel Tovarňák, PhD, for his
advice and support during the implementation process and in his
role as head of CSIRT. A special thanks is due to the technological
development group, especially to Mgr. Michal Čech, for creating an
environment with a high standard of work ethic, great fellowship, and
a constant willingness to help both at work and in life.
iv
Abstract
The goal of this thesis was to design and implement a set of proof-ofconcept
applications centred around the RT ticketing system, extending
its functionality to satisfy identified requirements on the unified
user request system. A secondary goal was to demonstrate the viability
of continued use of the RT as a preferred ticketing system.
The developed system and lessons learned during its implementation
will also serve as a basis for the future development of complete,
production-ready applications.
First, the main aspects of the user request handling and identity
access management are discussed, including the need for a service
desk and a unified user identity management system. Then, the identified
requirements are outlined, followed by a comparison of existing
tools and their shortcomings.
Next, the proposed solution is presented, followed by descriptions
of the technologies used. The individual parts of the delivered solution
are laid out subsequently, with brief use case examples provided at
the end. The final part outlines the entire implementation process,
detailing the delivered components in chronological order.
The developed solution includes a prepared Vagrantfile that creates
a virtual machine and provisions the RT and its dependencies using
an Ansible playbook. The playbook also includes multiple Python
services and automations that are deployed using the provided Docker
Compose file, along with all the necessary tools and services for the
demonstration.
Keywords
Request Tracker, Proof of Concept, Self-Service, Identity Consolidation,
Automation, Python
v
Contents
Introduction 1
1 Problem Statement 2
1.1 User Request Handling 2
1.1.1 Service Desk 2
1.2 Identity Access Management (IAM) 4
1.2.1 Existing Solution 4
1.3 Summary 4
2 Comparison of Existing Tools 6
2.1 Identified Requirements 6
2.2 Request Tracker (RT) 7
2.2.1 RT Strengths 7
2.2.2 RT Shortcomings 9
2.2.3 RT Summary 10
2.3 Jira Service Management 10
2.3.1 Jira Strengths 11
2.3.2 Jira Shortcomings 11
2.3.3 Jira Summary 13
2.4 GitLab Service Desk 13
2.4.1 GitLab Strengths 15
2.4.2 GitLab Shortcomings 15
2.4.3 GitLab Summary 16
2.5 Comparison Summary 16
3 Proposed solution 17
3.1 Self-Service UI 18
3.2 Email Parser 18
3.3 Second RT Instance 18
3.4 RT Automations 18
3.5 Supporting Infrastructure 19
4 Used Technology 20
4.1 Deployment Technologies 20
4.1.1 Docker 20
vi
4.1.2 Kubernetes 20
4.1.3 Kustomize 21
4.1.4 Vagrant 21
4.1.5 Ansible 21
4.2 Transaction/Message Passing 21
4.2.1 Vector 22
4.2.2 NATS 22
4.3 Work Orchestration/Automations 22
4.3.1 Temporal 22
4.4 User Authentication and Authorisation 23
4.4.1 OAuth2.0 23
4.4.2 JSON Web Token (JWT) 23
4.4.3 Open ID Connect (OIDC) 24
4.4.4 Perun 24
4.4.5 Keycloak 25
4.5 Asset Management 25
4.5.1 NetBox 25
4.6 Knowledge Base 26
4.6.1 Outline 26
4.7 Python Libraries 26
4.7.1 U V 26
4.7.2 Streamlit 26
4.7.3 MsgSpec 26
4.7.4 Starlette 27
4.7.5 SQLAlchemy 27
4.7.6 csirtmu-core-lib 27
4.8 Object Stores 27
4.8.1 Amazon Simple Storage Service (Amazon S3) . 28
4.8.2 MinIO 28
4.9 Cache 28
4.9.1 Redis 28
4.9.2 Dragonfly 28
4.10 Mail Transfer Agent (MTA) 29
4.10.1 Sendmail 29
5 Delivered Solution 30
5.1 Applications 30
5.1.1 Self-Service UI (csirtmu-self-service) 30
vii
5.1.2 Self-Service Backend (csirtmu-self-service-backend) 30
5.1.3 Perun User Synchronisation (csirtmu-perun-sync) 37
5.1.4 RT Email Parser (csirtmu-rt-email-parser) . . . 37
5.1.5 RT Automations (csirtmu-beta) 38
5.1.6 RT Ansible Deployment Playbook (rtir-deploy) 44
5.2 Infrastructure/External Tools 46
5.2.1 Unified Request System Deploy 46
5.2.2 Vector and NATS 46
5.2.3 PostgreSQL 46
5.2.4 Other Deployed Tools 46
5.3 System Description 48
5.3.1 Email Use Case 48
5.3.2 Self-Service Use Case 50
5.3.3 Perun User Data Flow 52
5.3.4 Summary 52
6 Implementation Process 54
6.1 csirtmu-beta 54
6.2 csirtmu-self-service and csirtmu-self-service-backend . 55
6.3 csirtmu-perun-sync 55
6.4 rtir-deploy 56
6.4.1 Local Virtual Machine Development 56
6.4.2 Remote Virtual Machine Development 58
6.4.3 Automatic Local Virtual Machine Demonstrator
Development 58
6.5 csirtmu-rt-email-parser 58
6.6 unified-request-system-deploy 59
6.7 csirtmu-auth-keycloak-fixtures 60
6.8 Final Testing 60
7 Conclusion 61
Bibliography 62
A Attachment File Structure 65
A . l /csirtmu-auth-keycloak-fixture-loader 66
A.2 /csirtmu-beta 66
A.3 /csirtmu-perun-sync 68
viii
A.4 /csirtmu-rt-email-parser 69
A.5 /csirtmu-self-service 69
A.6 /csirtmu-self-service-backend 70
A.7 /rtir-deploy 71
ix
List of Figures
1.1 Existing Jira Service Desk 3
2.1 Request Tracker (RT) 8
2.2 GitLab Service Desk 14
3.1 Proposed Solution 17
5.1 Self-Service UI Login Page 31
5.2 Self-Service UI Ticket Page 32
5.3 Self-Service UI Self-Service Page 33
5.4 A Class Diagram of Self-Service Backend Database Model 35
5.5 Delivered Solution 47
5.6 Email Use Case 49
5.7 Self-Service Use Case 51
5.8 Perun User Synchronisation 52
x
Introduction
For the optimal functioning of internal operations and user satisfaction
within modern organisations, efficient handling of requests, issue
reporting channels, and established service delivery is crucial. Maintaining
reliable, transparent, and effective communication between
users and support staff is a significant challenge as organisations grow
and their digital systems get more complicated. In such cases, it is
more important than ever to have a central system that unifies user
identities and access across an organisation, often with multiple internal
or external systems.
This thesis aims to design and implement a proof-of-concept unified
user request system that enables users to submit and view their
requests through a self-service interface, while still maintaining the
previously used email channel as an alternative. The system should be
centred around a ticketing tool and extend its functionality through
the development of a set of supporting applications and automations.
The finished solution should be locally deployable to showcase its
viability and cohesion among its various parts. It will also serve as a
base for future development of a comprehensive production system
centred around the chosen ticketing tool.
In the decisions regarding the future of the currently provisioned
ticketing system and the future processes for handling user requests
and automated reports, lessons learned during development will play
a similarly significant role as the proof-of-concept system itself. Due
to these factors, even if the system proves inadequate to fulfil the
identified requirements, its development will have served its purpose.
1
1 Problem Statement
The Institute of Computer Science1
at Masaryk University2
provides
IT services for the University. The Institute's many departments utilise
different processes to handle service requests. The delivery, management,
and provisioning of their services often differ significantly and
therefore require handling on a case-by-case basis.
1.1 User Request Handling
Historically, at the Institute, group email aliases (emailing lists) were
used for communication between the requester and the departments.
This way of handling user requests proved to be inefficient; Some
requests are forwarded multiple levels until they reach the responsible
team or employee. Other straightforward requests could be solved by
referencing relevant documentation or user guides without human
interaction.
1.1.1 Service Desk
A n alternative channel to address user requests was introduced in the
form of a service desk, enabling users to submit their requests through
a centralised interface without needing to know which email list is the
correct one for their type of issue. The service desk, equipped with a
GUI, handles user requests via provided forms, clearly stating what
information is necessary to resolve them, which significantly speeds
up the resolution.
Before the user is allowed to submit an issue, they may be asked
to review the provided guiding text to verify whether the problem
requires human intervention or can be resolved by following the provided
steps.
1. https://www.ics.muni.cz/en
2. https://www.muni.cz/en
2
l . PROBLEM STATEMENT
Existing Service Desk
Multiple target users and use cases exist for a service desk at the
Institute. Among the most pronounced are requests from local administrators,
which include IP address management requests, guest Wi-Fi
account requests, domain-name-related requests, password manager
account provisioning, and similar. Moreover, requests from Institute
employees typically include technical difficulties with internal tools or
employee-issued devices, V P N issues, facility-related concerns, and
other similar matters.
The Institute provides a Jira [1] service desk (see Figure 1.1); however,
it has some unsolvable faults, which will be addressed in Chapter
2 when comparing possible solutions.
1.2 Identity Access Management (IAM)
Identity Access Management [2] consists of processes, policies, and
systems that identify and monitor users and their permissions, both
limiting and providing access to protected resources within an organisation.
Any sufficiently large organisation needs to implement some
form of I A M in order to control access to such resources.
1.2.1 Existing Solution
At Masaryk University, the I A M is facilitated by cooperation between
Perun [3, 4], which tracks users and their permissions, and M U N I
Unified Login3
, which enables users to sign in using a single identity,
achieving what is known as Single Sign-On (further discussed in Section
4.4). However, M U N I Unified Login, in its current form, does not
provide information about user email aliases, making it problematic
to match them to a single user identity.
1.3 Summary
As mentioned above, the existing service desk solution is unsatisfactory
due to its flaws. Moreover, M U N I Unified Login does not provide
3. https://it.muni.cz/en/services/muni-unified-login
4
l . PROBLEM STATEMENT
information about user email aliases that is necessary to allow users
to submit tickets and match the tickets to a single identity when using
their email aliases.
It is not necessary to venture far to imagine a scenario where users
decide to send a request from their alias email. In the cybersecurity
context, for instance, when receiving a suspicious email, regardless
of whether the receiving address is an alias, diligent users often opt
to forward it immediately to their cybersecurity teams, leading to the
use of an alias address in such communication.
Therefore, due to the problems with existing solutions and the
need to address I A M , especially user aliases, as well as the growing
requirement to handle user requests efficiently, particularly as the
organisation expands, a search for a satisfactory service desk solution
ensued.
5
2 Comparison of Existing Tools
To properly compare available options, the necessary aspects of a
desired solution must be identified and discussed beforehand.
2.1 Identified Requirements
• Email support capability - an option to submit an issue by
email must be available. Email is necessary due to backward
compatibility with automated systems, and some users prefer
this method.
• Identity consolidation - related to email support: At Masaryk
University, users are allowed to have multiple email aliases.
However, we aim to establish a single unified identity, regardless
of the email alias used to submit a request. Therefore, a
mapping that connects user aliases to their identity is essential.
• Self-service ability - the possibility that users will solve some
of their more generic or simple issues independently with provided
guidance, relevant documentation and links.
• Form import/export - the forms and guiding texts in the service
desk should support import and export to Y A M L 1
, JSON2
or a
similar format.
• Integration of external tools - the ability to, for example, search
IP addresses recorded in the asset management tool or for
documents in the knowledge base document server.
• Ticket visibility - allow users to view the tickets they created
or are mentioned in, after logging in (hence, the importance of
consolidated identity).
• User separation - users should see only the tickets they have
created or are participants in.
1. https://yaml.org/
2. https://www.j son.org/j son-en.html
6
2. COMPARISON OF EXISTING TOOLS
• Automations - automatic actions executed when defined conditions
are met, e.g. sending notifications when a specific type
of ticket is received, setting S L A 3
ticket due dates, etc.
2.2 Request Tracker (RT)
Request Tracker (RT) [5] from Best Practical (see Figure 2.1) is an opensource
application that tracks user requests (a ticket management tool)
and is based on email correspondence. Two instances of RT are utilised
within the ICS M U N I ; one is used in CSIRT M U 4
for cyber security
incident handling, and a second instance serves as an internal tracking
tool within the ICS.
RT has many community plugins that are supported and shipped
by the original developers, who wrote them in Perl, the same language
as RT. CSIRT production RT utilises a few official and even some
custom-built extensions.
2.2.1 RT Strengths
• RT is thoroughly tested as a production cybersecurity incident
handling system at CSIRT M U , which has been in use since
approximately 2014.
• RT has a reliable email gateway that supports extensive communication
with multiple participants, whether as requesters or in
cc, and allows for adding new participants even during the handling
process. This feature provides a complete communication
history from the start, including all replies.
• Optional encryption and digital signatures can be enabled for
outgoing messages, and incoming messages are automatically
decrypted and signatures verified.
• Access to email headers and raw emails is facilitated directly
in the GUI.
3. Service Level Agreement (SLA)
4. https://csirt.muni.cz/en
7
Home - Search» Reports • Articl.es» Assets *• Tools» Admin - Q *
Homepage
Search Tickets,.. V v R E Q U E S T / /
• / T R A C K E R V *
I—»•
CT?
d
HJ
re
d
n
TT
rc
Hi
3
10 highest priority tickets I own (Found 0 tickets)
>st waded Wed Nov 12 IK53;30 3025.
10 newest unowned tickets (Found o tickets)
Last Waded Wed Nov 12 15-53-30 2025.
Bookmarked Tickets [Found o tickets)
ist loaded Wed Nov 15:53:31 2025.
Quick ticket creation
Subject
Requestors
root (Enoch Root)
root (Enoch Root)
My reminders
Queue list
Queue
Dashboards
RT System's dashboards
Homepage
Subscripts
None
Status
Enabled
2. COMPARISON OF EXISTING TOOLS
• RT supports queues and many customisations, such as custom
fields, which are optional, user-defined and queue-specific
ticket fields.
• RT offers a wide range of official plugins that enhance its functionality—being
open-source and having a significant community
results in a simple process for creating custom plugins.
• Automation scripts, in RT called "Scrips", are present out of
the box.
2.2.2 RT Shortcomings
• RT is an older software, and although it is still being actively
developed, with version 6 being the newest major version released
in May 2025, it is written in Perl, and some of its aspects
or GUI elements may appear dated.
• RT does not have out-of-the-box functionality to implement
email alias identity consolidation. Users can view tickets only
after logging in using the same email address they used to
submit the ticket.
There is a plugin called MergeUsers5
that enables merging
RT users; nevertheless, it only allows for a manually triggered
merge on selected users, rather than an automatic process to
identify and consolidate accounts with user aliases into a single
identity.
• RT supports assets and linking assets with tickets; however,
there is no plugin to connect to existing asset management
tools (in our case, NetBox [6], discussed in Section 4.5), i.e. to
synchronise existing assets automatically.
• A n extension called FormTools adds simple forms, which can
provide self-service and are exportable to JSON. Nevertheless,
forms are bound to RT queues, and apart from built-in fields
like subject, requester, cc, due, and content, form inputs are
only available based on custom fields that exist in the given
5. https://metacpaii.org/pod/RT::Extension::MergeUsers
9
2. COMPARISON OF EXISTING TOOLS
queue. Using FormTools would therefore lead to either having
one queue with custom fields for every input field in every form
(hundreds of custom fields), or having one queue per form with
specific input fields for that form (dozens of queues), or using
the content field and requiring users to input and format all
necessary data into a single text area. Neither is an acceptable
solution.
• There is no data about performed or ignored automations in
the GUI. Information about skipped automations can be found
in RT logs; however, only the count of executed automations is
noted. No retry mechanism or accessible error reporting exists
for failed automations.
• Internal comments cannot be entirely deleted; content can be
deleted, but an empty comment remains.
2.2.3 RT Summary
RT has solid email support, good user access and separation (although
it lacks SSO support), and is a time-tested, instrumental tool at CSIRT.
Nonetheless, it lacks built-in self-service capabilities, relying instead
on a form extension that falls short of expectations. There is no support
for identity consolidation, and the required external tools are not
supported. Automations are provided out-of-the-box; yet, there is
no visibility into which ones were executed or ignored, and no retry
mechanism is available.
2.3 Jira Service Management
Jira Service Management is a software solution from Atlassian that provides
a service desk, request queues, self-service features, service level
agreements (SLAs), external tool integrations (including Microsoft
Teams6
and Slack7
), and customisable reports. Simple automations
can also be defined through the GUI.
6. https://www.microsoft.com/en-us/microsoft-teams/
group-chat-software
7. https://slack.com/
10
2. COMPARISON OF EXISTING TOOLS
Jira is used as a Service Desk for IT services at the Institute and was
considered as a replacement for the RT used by CSIRT M U . However,
after three months of testing, the team returned to RT due to some
unsolvable faults. The lists below contain both positives and negatives
that were discovered and reported in the internal document [7].
2.3.1 Jira Strengths
• Overview charts show important information and are visually
pleasing.
• Supports SSO; Jira can be used with M U N I Unified Login.
• Jira supports intuitive full-text search.
• Internal comments can be deleted entirely (unlike in RT).
• Intuitive automation management and configuration.
• Simple inline ticket and comment modifications.
• Forms can be defined through the GUI, which provides a good
user experience. Forms in Jira can also facilitate self-service.
2.3.2 Jira Shortcomings
• If the email contains a UTF-8 encoded subject or sender, Jira
discards it; a UTF-8 encoded message body is also not displayed
correctly.
• HTML-formatted emails are not supported and are displayed
as plaintext.
• Jira does not support encrypting or digitally signing outgoing
emails.
• Configuring incoming message filters is not permitted, resulting
in some valid messages being discarded.
• Running the Service Desk under a custom domain ("muni.cz")
is not allowed; it must be run under "atlassian.net".
11
2. COMPARISON OF EXISTING TOOLS
• Tickets addressed to a mailing list are not visible to individual
users upon login, but only to the requester (the mailing list).
• To send an email to a new recipient, the recipient's email address
must be manually added to the Customers project in Jira
settings. Automatic onboarding of users is possible; however,
Jira has a hard-coded limit of 150000 (insufficient to onboard
all existing users of MUNI).
• When adding a new participant to the ticket, there is no way
to include the communication history; the new participant receives
only new messages.
• Tickets submitted by users using an alias are not available to
them. Jira uses "<uco>@muni.cz"8
to track users, and any other
email address used (even "<uco>@mail.muni.cz") will not be
connected to the correct user account.
• Logs of outgoing emails from Jira are inaccessible even to the
administrators.
• There were occasions when, according to the GUI, the message
was sent out, but the recipient did not receive it. Only the mail
system's (SendGrid9
) logs showed that no message was ever
sent.
• Automations are unreliable; sometimes, automation starts without
satisfying execution conditions. At other times, automation
failed and reported the failure in the logs, sometimes even after
a successful execution.
• Automations are monetised based on the number of executions,
not the number of automations (with the number of tickets per
month that CSIRT receives, a more costly license is required).
• If the user sends a request with multiple contacts in the " C C "
header, Jira correctly assigns everyone as Requesters. Nevertheless,
suppose the user adds a new participant later. In that case,
8. Uco stands for University ID number.
9. https://sendgrid.com/en-us
12
2. COMPARISON OF EXISTING TOOLS
Jira will not assign that participant as a requester, so no replies
or new communication will be sent to them. Additionally, confirming
such a situation has occurred is possible only through
logs, as information about the email's cc is not displayed in the
GUI.
• Similarly to cc, email headers are accessible only to the administrators
through logs.
• Custom email headers are not supported.
• Adding custom parameters to the tickets, such as labels "duplicate"
or "false positive", is not possible.
• When moving tickets between projects (i.e., from the M U N I
IT service desk to the CSIRT service desk), automations are
not being triggered. In a moved ticket from a different project,
there is no access to email logs in the current project.
• Closed tickets cannot be modified or opened again, not even
by the administrator.
2.3.3 Jira Summary
Jira email support is unreliable at best. User access and separation
are similar to RT, with the difference that RT does not support SSO.
Self-service support is robust, featuring an intuitive GUI management
system. Jira does not solve the email identity consolidation problem
(same as RT). External tools NetBox and Outline [8] (discussed in
Section 4.6) do not have direct support - only through automations,
which are unreliable and heavily monetised.
2.4 GitLab Service Desk
The GitLab [9] service desk (see Figure 2.2) is a feature on a GitLab
project that is enabled in the settings, transforming project issues into
tickets. Users can submit a ticket using a linked email address and are
kept up-to-date with ticket handling (comments, changes, etc.) via
email replies while also being able to respond themselves. The GitLab
13
2. COMPARISON OF EXISTING TOOLS
2. COMPARISON OF EXISTING TOOLS
Service Desk is primarily designed for external users submitting issues
to developers.
The CSIRT technological development group utilises the GitLab
service desk as a means for users to provide feedback on one of
their products. It utilises GitLab API instead of an email to submit
issues/tickets, but the process is the same otherwise.
2.4.1 GitLab Strengths
• GitLab supports SSO; the existing ICS GitLab instance utilises
M U N I Unified Login.
• Since the Institute already has a GitLab instance, deploying the
service desk is as simple as creating a designated project and
configuring it.
• Adding more participants to the email conversation is supported.
Participants receive email replies from GitLab when
ticket changes occur and can respond to the conversation flow
by sending email replies themselves, which are automatically
transformed into ticket comments.
2.4.2 GitLab Shortcomings
• There is no service portal available for external users (those
without a GitLab account or access to the service desk project).
They can submit a ticket only via email, and there is no way for
them to view the tickets they have created via email in the GUI.
• Internal users require at least the reporter role in the service
desk project to view any tickets. Still, when given the reporter
role, the problem only transforms from users not seeing any
tickets to seeing all tickets, which violates user separation.
• If a registered user opts to create an issue using an email address
(even if that email address was used to register to GitLab), their
account will not be associated with the issue. The same applies
to a user who first submits an issue via email and then registers
using the same address. Ownership of tickets is not transferable
15
2. COMPARISON OF EXISTING TOOLS
to the user because the Support Bot user owns email-submitted
issues in GitLab.
2.4.3 GitLab Summary
The GitLab service desk feature supports creating issues through
email; yet, it lacks features that email-based ticketing systems, such as
RT, have. Although GitLab enables SSO, the user ticket access and separation
are inadequate, as GitLab's access control is primarily projectoriented.
Moreover, self-service is possible with GitLab Wiki, but
without the forms. Furthermore, email-submitted tickets are not visible
to the requester, even when they are logged in via their primary
email address. Lastly, external tools, such as Netbox and Outline, are
also not supported.
GitLab was tested as a solution for the aforementioned requirements
less extensively compared to RT and Jira. GitLab is only used as
a feedback tracker within CSIRT M U and was only briefly considered
as an alternative to RT; however, the problems encountered during
the process discouraged this usage.
2.5 Comparison Summary
Due to Jira's unreliable email support, GitLab's lack of separate user
access, and other issues, it was decided to utilise RT. Even though RT
has its own shortcomings, it has already been tested in production, is
open-source, and is extensible. The proposed solution, discussed in
the next chapter (Chapter 3), was based on this extensibility.
16
3 Proposed solution
To satisfy the aforementioned requirements, it was determined that
implementing extensions and supporting applications will be necessary
for RT. Furthermore, due to time and resource constraints, it
was deemed risky to implement the complete production applications
outright. Therefore, a set of demo applications centred around the
RT was proposed to serve as a proof of concept and a basis for future
development. The architecture of the proposed solution is captured
in Figure 3.1.
external tools
(section 3.5)
o
API usage
SSO identity
provider
(section 3.5)
user
browser access send email
1 1
SSO
SSO
Legend
External
Tool
Implemented
Service
Self-Service Ul
(section 3.1)
Email Parser
(section 3.2)
create ticket
1
—y
create ticket
RT
(section 3.3)
pass transactions
message passing
tools
(section 3.5)
perform actions on tickets
I
RT Automations
(section 3.4)
pass RT transactions
Figure 3.1: Proposed Solution
17
3. PROPOSED SOLUTION
3.1 Self-Service UI
A standalone self-service application that provides a GUI, supports
NetBox and Outline integration, and allows users to submit forms as
RT tickets. The application should support importing and exporting
forms in Y A M L format. Users must be authenticated using an SSO
provider before submitting a request or accessing the self-service
interface.
The application does not necessarily need to be visually appealing,
as it is a proof of concept. The primary focus is on the functional
side, intending to showcase the desired cohesion between system
components.
3.2 Email Parser
A n email parser that would parse emails before they reach the RT
email gateway, extract headers, enhance user information (consolidate
the user identity if sent under an alias), and forward the enhanced
email to the RT email gateway. To this end, another service is needed
to store user data and provide an interface for querying.
3.3 Second RT Instance
For the use in the demo system, a new testing RT deployment was
required. A n existing deployment automation was to be revisited and
upgraded to utilise a new version of RT (RT6). RT SSO support was
to be examined and, if viable, integrated and tested.
3.4 RT Automations
Python service to parse RT transactions1
that are generated upon
interactions with RT and execute automations based on predefined
rules (queue, transaction type) and conditions being met. The service
enhances RT automations with a retry mechanism, as well as improvements
in visibility and maintainability. Moving automations outside of
1. Transactions are records capturing the actions performed by user or system.
18
3. PROPOSED SOLUTION
the RT by utilising Python and RT API would also enable the creation
of more complex and potentially more effective automations.
3.5 Supporting Infrastructure
• Message passing tools to enable sending transactions from RT
to trigger automations.
• SSO identity provider tool for testing with prepared testing
users.
• Testing instances of external tools for integration testing pur-
poses.
• Other supporting tools, as needed.
19
4 Used Technology
This chapter provides a brief introduction to the technologies used.
Due to the number of technologies used, some of which play a nonpivotal
role in the demonstration system, some descriptions were kept
concise.
4.1 Deployment Technologies
In this section, descriptions of the technologies used to deploy the
demonstration system, either as a whole or in part, are discussed.
4.1.1 Docker
Docker [10] is a tool designed to automate the containerisation and
deployment of containerised applications. It enables developers to define
step-by-step instructions for building and running the containers.
A file containing build and run instructions is typically referred to as
the Dockerfile.
In CSIRT M U , Docker is primarily used for local testing and in the
CI/CD1
pipelines to test code and build new images for release.
Docker Compose
Compose is another Docker tool that enables developers to orchestrate
multiple containers into a single deployment. It enables the definition
of networking, shared volumes, and dependencies between containers,
among other features. The deployment orchestration is defined in a
single Y A M L file, which is standardly named compose.yaml (older
versions docker-compose.yaml).
4.1.2 Kubernetes
Kubernetes [11], or K8S, is an open-source tool for deploying, managing
and scaling containerised applications. Kubernetes can operate
multiple servers, called nodes, not necessarily in a single location, as
1. CI - Continuous Integration, C D - Continuous Delivery
20
4. USED TECHNOLOGY
part of a cluster. Kubernetes deploys applications by creating pods (a
single container instance), based on a selected strategy. Pods are then
distributed to and run on nodes in the cluster.
4.1.3 Kustomize
Kustomize [12] is an open-source, Kubernetes-native configuration
management tool that enables simple, template-free application deployment.
Its main appeal comes from the ability to alter the provided
base deployment configuration by using patches (the required
changes) defined in Y A M L files without rewriting the original.
4.1.4 Vagrant
Vagrant [13] is an open-source virtual machine lifecycle manager that
simplifies and automates the creation, provisioning and decommissioning
of virtual machines. Vagrant enables automated setup of a
reproducible development environment regardless of the host operating
system. Virtual machine's setup and provisioning are defined in a
simple text file called Vagrantfile.
4.1.5 Ansible
Ansible [14] is an open-source automation tool for configuring and
deploying applications using an SSH connection to the server where
the application should be deployed. Individual automation steps are
called tasks and are grouped into roles, which can then be executed,
included in other roles, or incorporated into playbooks that can contain
multiple roles.
4.2 Transaction/Message Passing
To enable an external execution of RT Automations, it is necessary to
pass the generated transactions from RT to the service to trigger the
execution. The following tools were selected to facilitate this process.
21
4. USED TECHNOLOGY
4.2.1 Vector
Vector [15] is a tool for data pipelining that offers high performance.
Vector is primarily used to facilitate observability for cloud solutions,
which means, among other things, accepting, transforming, and forwarding
logs from deployed applications.
4.2.2 NATS
NATS [16] serves as a universal message broker. Its support for many
programming languages and ease of deployment make it a well-known
and used tool. It can also serve as both a data source and a data
destination (also known as a sink) for Vector.
NATS messages are not persisted when there is no active consumer.
To facilitate storing and replaying messages, a JetStream [17], a built-in
persistence engine, must be configured and utilised.
4.3 Work Orchestration/Automations
To automate and monitor the execution of automations, the Temporal
[18] orchestration tool was used and is described in this section.
4.3.1 Temporal
Temporal is an orchestrator and work distribution framework with a
robust and customisable retry policy. Temporal allows developers to
build easily, operate reliably and scale any code with little overhead.
Temporal supports multiple languages and has client libraries for each
of them.
Temporal workers can be easily containerised, and their scaling
is as simple as spawning a new container replica - this massively
simplifies deployment into a Kubernetes environment.
Temporal Workflows and Activities
Workflow is a developer-defined code unit that can be executed on
a worker. Activities are smaller code units that can only be executed
inside a workflow. Similar to activities, workflows can trigger the
22
4. USED TECHNOLOGY
execution of a so-called child workflow - a workflow that is triggered
by a different workflow. The temporal library supports awaiting the
triggered activity or workflow, or a fire-and-forget approach where
the activity or workflow is launched without awaiting the result.
Temporal Worker
Temporal workers (in Python) are initialised as a simple scripts that
utilise the Temporal library to connect to the Temporal server and
retrieve assigned workflow executions. Each workflow to be executed
on a given worker must be subscribed to it, indicating to Temporal
which workflows (that is, the workflow code) the worker can run.
Workers are connected to a specified Temporal queue. Workflow execution
requires specifying a queue in which it should be executed. All
started jobs awaiting execution are distributed among the workers in
the given queue.
4.4 User Authentication and Authorisation
This section will discuss the user authentication and authorisation
tools and protocols that were used.
4.4.1 OAuth2.0
OAuth 2.0 [19] is an authorisation protocol that defines different
"grant types" (or "flows") designed for various use cases. Temporary
and revocable tokens, which are data pieces representing access
to the resource, are used instead of the usual username-password
combination. The primary aim of OAuth 2.0 is to enable verified applications
to access resources on behalf of users without requiring them
to share their credentials directly.
4.4.2 JSON Web Token (JWT)
JWT [20] is a widely used type of token in the JSON format (sometimes
encrypted) containing one or more claims, which can be optionally
certified by the token's digital signature. Claims are statements about
an entity (usually a user).
23
4. USED TECHNOLOGY
4.4.3 Open ID Connect (OIDC)
OIDC [21] is a user authentication system built on the OAuth 2.0 protocol.
As with OAuth 2.0, users do not share their credentials directly;
instead, they use an identity provider, such as Google or M U N I Unified
Login, to log in to different applications. When users want to log
in to a service that supports OIDC and select this option on the service
login page, they are redirected to the identity provider, where they log
in using their credentials. After that, users only need to authorise the
service they want to log into to access their data. The identity provider
issues a JWT for the given service, which serves as proof of identity
and can be used later to fetch user data. It is a convenient and safer
way of authentication, as credentials are only known to the identity
provider. Users can log in to multiple services using the same provider,
a capability known as Single Sign-On (SSO).
Client
In the OIDC, the client is a different name for the service that wants to
authenticate users through the identity provider. Client ID and client
secret are used to authenticate the service against the identity provider
before allowing a redirect to the provider's user sign-in page.
Audience
The audience is a part of the JWT that signals for which clients the
token is intended. The audience can be used to issue tokens with
multiple clients present, allowing one service to be authorised against
other services on behalf of the user by using a mechanism called token
exchange (identity provider must support this and be configured
accordingly).
4.4.4 Perun
Perun is a resource, user, group, facility, and organisation access management
system developed through a cooperation between CESNET2
and CERIT-SC3
.
2. https://www.cesnet.cz/
3. https://www.cerit-sc.cz/
24
4. USED TECHNOLOGY
ICS instance of Perun facilitates a centralised management of access
to the thousands of resources operated by Masaryk University. M U N I
Unified Login collaborates with Perun by verifying permissions and
accessing other user and resource data stored there, enabling users to
sign in to multiple university systems using a single, centrally managed
identity.
Provisioning of sponsored accounts, such as those for guests, is
also supported via Perun by linking with a sponsor's identity.
4.4.5 Keycloak
Keycloak [22] is an identity and access management tool with SSO
capability. It can act as an OIDC identity provider and work with other
access management tools (such as L D A P 4
) . Its main strength is in its
configurability. The technological development group uses Keycloak
primarily for testing as a stand-in for M U N I Unified Login.
4.5 Asset Management
Asset management is an unavoidable and one of the most critical
parts of organisational management processes, as stated in ISO 27000
[23], particularly in the context of cybersecurity. Knowing the location,
current state, and who manages the organisation's assets is a crucial
step in protecting assets and ensuring their full utilisation.
4.5.1 NetBox
NetBox is an open-source IT asset management tool focusing on IPAM
(IP address management) and DCIM (data centre infrastructure management)
. NetBox is used as the source of truth for assets, locations,
administrators, and other relevant information at the Institute.
4. https://ldap.com/
25
4. USED TECHNOLOGY
4.6 Knowledge Base
A knowledge base is a centralised source of information; for example,
in a company, it can contain process descriptions and other information
related to day-to-day operations.
4.6.1 Outline
Outline is an open-source documentation server with a built-in editor
that serves as a team knowledge base. Outline is a production
knowledge base used at CSIRT M U N I and ICS M U N I . Outline supports
integration with various industry-standard tools and systems,
i.e. Slack. Outline does not implement its own user authentication; it
entirely relies on external identity providers.
4.7 Python Libraries
This section contains brief descriptions of the most important Python
libraries used for the development of the demo system applications.
4.7.1 UV
U V [24] is an open-source Python dependency manager developed
by Astral - a faster and modern alternative to Poetry (which was used
by the technological development group before).
4.7.2 Streamlit
Streamlit's [25] primary use case is to build simple web pages for data
visualisation. It supports visualisation of data tables, and a simple
OIDC integration is also available. This integration is rudimentary,
as it does not provide developers with access to the OIDC tokens;
nevertheless, it can be used for prototyping and development of simple
front-end applications.
4.7.3 MsgSpec
MsgSpec [26] is a lightweight library for defining Python object representations
of serialisable data structures, and parsing and validating
26
4. USED TECHNOLOGY
data in various formats (such as JSON and YAML) into user-defined
Structs and back. Using MsgSpec simplifies transforming data between
serialisable formats, DTOs (Data Transfer Objects) and built-in
Python objects.
4.7.4 Starlette
Starlette [27] is a lightweight framework that enables fast and simple
creation of asynchronous web applications and services in Python.
Its simple and efficient design enables cooperation with several of
different frameworks (e.g. FastAPI5
and Uvicorn6
). In the context of a
demonstration system, it was used to develop web applications with
a REST API.
4.7.5 SQLAlchemy
SQLAlchemy [28] is a Python Object-Relational Mapping (ORM) tool
that enables the programmatic definition of database models and
the manipulation and querying of data within a database, either via
mapped Python objects or through its SQL support. SQLAlchemy
supports various database engines, including PostgreSQL, MySQL,
SQLite, and Oracle. In the demo system, it is utilised in projects that
require a database.
4.7.6 csirtmu-core-lib
Core-lib is a Python library developed by the CSIRTs technological
development group. Part of this library was used in the demonstration
project to load configuration from the Y A M L files. It is utilised for the
configuration of each implemented Python service that was delivered.
4.8 Object Stores
Object stores organise data into a flat-structured, scalable architecture
by utilising objects instead of the usual block storage.
5. https://fastapi.tiangolo.com/
6. https://uvicorn.dev/
27
4. USED TECHNOLOGY
4.8.1 Amazon Simple Storage Service (Amazon S3)
S3 [29] is a cloud storage solution from AWS (Amazon Web Services).
It is highly scalable, simple to use, secure and has many use cases.
Containers for storing objects in S3, analogous to folders in block
storage, are called buckets.
4.8.2 MinIO
MinIO [30] is an open-source object storage system, an alternative
to S3, that is fully compatible with the S3 API. MinIO was designed
to be lightweight and scalable; therefore, it can be used to operate
from a single server to massive distributed clusters. It is designed for
modern data workloads, such as Kubernetes deployments and big
data analytics, due to its focus on simplicity, speed, and stability.
4.9 Cache
Many tools utilise a fast-access database (cache)—typically in memory—to
store frequently required data. Netbox and Outline are also
among such tools.
4.9.1 Redis
Redis [31] is a fast-access data store that functions as a dictionary of
key-value pairs, specialised for use as a cache. It supports a variety of
data structures, including strings, lists, sets, and hashes. Redis's quick
access time is achieved by storing data in memory.
4.9.2 Dragonfly
Dragonfly [32] is designed as a drop-in replacement for the Redis
data store. It provides better performance by utilising current multiC
P U architectures and consequently is well-suited for real-time and
high-throughput distributed systems.
28
4. USED TECHNOLOGY
4.10 Mail Transfer Agent (MTA)
A mail transfer agent is an application responsible for sending, receiving,
and relaying email messages via the Simple Mail Transfer
Protocol (SMTP).
4.10.1 Sendmail
Sendmail [33] is a well-known, free and open-source software in the
Unix and Linux communities. Regardless, due to its complexity and
difficulty in configuring, it is being replaced by simpler solutions. RT
utilises Sendmail as the M T A of choice for email communication by
configuring it to forward incoming emails to the RT mailgate and
sending outgoing emails from RT.
29
5 Delivered Solution
In this section, all parts of the delivered solution accompanying this
text will be described.
5.1 Applications
The application implementations can be found in the root directory of
the solution, as well as in the related Ansible roles in the rtir-deploy
project. The root-directory instances are present for easy access and
to list all projects implemented for the demonstration system. The
other instances are used for automatic deployment and configuration
into the virtual machine via Ansible. A l l implemented applications
mentioned in this chapter can be configured via the Y A M L file named
"ansible-deploy-conf.yml" located in the rtir-deploy project in the
"ansible" folder.
5.1.1 Self-Service UI (csirtmu-self-service)
Demo Self-Service UI app created using Streamlit and connected to
Keycloak as OIDC identity provider to visualise data returned from
the self-service backend.
The app contains three pages: a login page that is displayed upon
first access and is the only accessible page without logging in (see
Figure 5.1), a tickets page that displays tickets created by the signed-in
user (see Figure 5.2), and a self-service page that guides users through
self-service steps (see Figure 5.3).
The self-service page features a drop-down menu offering a selection
of currently available steps. Upon selecting a value, a new
drop-down is displayed with a subselection, and this process repeats
until a submittable step is reached.
5.1.2 Self-Service Backend (csirtmu-self-service-backend)
Although Streamlit enables the implementation of database calls alongside
the UI, a standalone backend for the UI was later developed to
30
5- DELIVERED SOLUTION
Figure 5.1: Self-Service UI Login Page
31
5- DELIVERED SOLUTION
• i l l I £ ü
s UJ = I J 3 O O
Figure 5.2: Self-Service UI Ticket Page
32
T1
re
ui
w
en
re
Navigation
Self Service
Submitted Tickets
100100100#m
John Kirby
How can we help you?
Request Category
Select from available request categories.
Networks and Wi-Fi
l - S
<
o
a
l - S
<
o
re
Language
O EN
Networks and Wi-Fi
What can we help you with regarding trie networks and Wi-Fi;
^ Select an option
Issues with VPN
Own VPN profiles (EduVPN}
Issues with Wi-Fi
Temporary Wi-Fi network
-AN «nrie<:ticr ;e vi^s i equ-rit
5- DELIVERED SOLUTION
facilitate an effortless switch to a dedicated frontend application in
the future.
The application allows importing and exporting of the defined
steps to and from Y A M L files. Import is automatic at the start of the
application, and export is achieved by running a dedicated Python
script.
Implemented Step Types
The implemented database models are also captured in a class diagram
in Figure 5.4.
• TextStep - A simple text-displaying step.
• LinkStep - Step containing a link (e.g. to a related resource).
• FormStep - Step containing a submittable form with customisable
fields that creates an RT ticket. A l l fields, except the composite
ones, have a Streamlit input counterpart used to display
them.
Available Fields:
- Textlnput
- Selectbox
- Multiselect
- TextArea
- Numberlnputlnt
- NumberlnputFloat
- Checkbox
- Radio
- Datelnput
- Timelnput
- FileUpload
- TextField
- OnSelection - Displays additional sets of fields based on
the control field's current selected value.
34
5- DELIVERED SOLUTION
5- DELIVERED SOLUTION
- OneRequired - A set of fields, at least one of which is
required to be filled out to submit the form.
- DynamicSection - Displays multiple copies of predefined
fields based on the value of the control counter field.
• NetboxSearchStep - To demonstrate integration with Netbox,
a search step was implemented to support searching for IP
addresses, prefixes, and tenants.
• OutlineSearchStep - To display integration with Outline, the
search for documents was chosen.
Demonstration Configuration
For the demonstration, the existing forms from the Jira Service Desk
of the Institute were converted into Y A M L definitions to be loaded
into the app upon startup.
The available NetBox and Outline search steps are also configured,
and one additional use case for the application was later identified
and added as a step. The mentioned use case considers an employee
who wants to register a new device with its IP address, and specify
the services that will be available on the said machine, as well as
the port ranges that will be expected to be allowed to communicate
with this machine. These steps are named TP Address Search', 'Prefix
Search', 'Tenant Search', 'Outline Document Search', and 'Register
Device', respectively.
External Tool Integration
Due to Streamlit's limited OIDC support, the full potential of NetBox,
Outline and OIDC remains unreachable. In a standard setting, tokens
with multi-audience capabilities can be used in a process called token
exchange, for example, to query NetBox on behalf of a logged-in user
and receive data accessible only to that user. Nonetheless, due to the
token inaccessibility via Streamlit, this method is unusable; therefore,
admin API access tokens are used to access NetBox and Outline.
36
5- DELIVERED SOLUTION
5.1.3 Perun User Synchronisation (csirtmu-perun-sync)
This service consists of Temporal workers used to sync Perun users
from the configured MinIO objects into the database, and a Starlette
application that enables querying the database using the exposed
REST API.
Synchronisation Process
Upon uploading the file into the monitored MinIO bucket, the workflow
parses the JSON file and inserts the user data into a database.
Stored user data is then accessible through the API.
This process was developed for the Security Dashboard (csirtmualpha)
- a tool implemented by the development group and used by
incident reaction, threat management groups, and system administrators
- to look up user access permissions (e.g., whether they can
access Eduroam or V P N services) based on their uco.
The Temporal Workflow was developed by colleagues in the technological
development group. The workflow was modified to store
email address information about users (which was not part of the
original scope), and a second Workflow was created to parse a temporary
source of user alias data. However, the finalised version assumes
aliases are present in the JSON file from Perun.
Demo Configuration
The JSON files with Perun exports that are automatically uploaded
into the designated MinIO buckets do not contain user aliases in the
current version. For the demo, it is expected that the aliases are present
in the exports and the prepared testing JSON file reflects this.
5.1.4 RT Email Parser (csirtmu-rt-email-parser)
A simple script that is deployed and configured using the rtir-deploy
Ansible playbook via the "email_parser" role. The script's purpose is to
parse incoming email messages in the mbox format using Python builtin
email libraries, extract email headers, namely the "From" header,
poll the perun-sync's exposed API to search for the sender's address in
its database, and upon a non-empty response replaces "From" header
37
5- DELIVERED SOLUTION
with returned user data while keeping original sender in the "X-RTOriginal-Requestor"
header. If conflicting or no data about the sender
is returned, the message is left unchanged.
5.1.5 RT Automations (csirtmu-beta)
The first developed part of this thesis, which was deployed and tested
in production on CSIRT RT for nearly a year, is named csirtmu-beta.
Beta consists of a NATS subscriber that listens for the incoming RT
transactions and a set of highly configurable and extendable Temporal
workflows that evaluate conditions and execute actions on RT tickets or
external services. There are three different kinds of workers present in
the Beta: HandleTransactions worker, ProcessWorkflows worker, and
PeriodicWorkflows worker. The HandleTransactions worker executes
only the HandleTransaction workflow, the PeriodicWorkflows worker
executes periodic jobs, and the ProcessWorkflows worker executes
all remaining workflows. The temporal queue to which the workers
connect is configurable.
Configuration allows defining for which RT queue and transaction
type combination, which workflows should be executed, and which
Temporal queue (per RT queue) should be used. Some workflows
have configurable parameters for greater code reusability.
Startup and Transaction Handling Process
Upon the subscriber's startup, the configuration with the queue mapping
is loaded, Temporal and NATS clients are instantiated, the callback
function is registered with the NATS client, and a connection to
NATS is established.
When the subscriber receives an RT transaction, it triggers the callback
function, which in turn tries to start the transaction-handling
workflow. If the Temporal server is unreachable, received transactions
are stored in the Redis cache until the periodic retry workflow successfully
executes them. The rest of the work is handled by Temporal
and its workers.
Workers on startup connect to the Temporal server with registered
workflows and actions and await job assignments.
38
5- DELIVERED SOLUTION
HandleTransaction Workflow
The HandleTransaction workflow receives a transaction and a list of
workflows (with optional workflow parameters) configured for the RT
queue and the transaction type, and executes them sequentially in the
specified order as child workflows in the configured Temporal queue.
Sequential execution is important because the ticket modifications
performed by workflows may lead to an inconsistent ticket state.
Workflow Identification
The workflow ID of each workflow is prefixed with the RT transaction
ID for easy lookup of defective workflow runs. Additionally, the
workflow ID of the HandleTransaction workflow contains information
about its transaction type. The prefix is necessary due to the shortened
workflow view, which displays only 10 pages with a maximum of 100
workflows per page in the Temporal GUI, and the custom type (not
a string, as would appear at first glance) used for the workflow ID.
Searching for a substring is impossible, as it only supports prefix-based
lookup.
Process Workflows
• ChangeSubjectOfAutomaticReportOnCorrespond
For historical reasons, the system that sends automatic reports
creates a placeholder ticket, allowing it to expose the report
with the attached ticket ID, and then sends the report to RT.
This workflow updates the ticket subject with information from
the report received through correspondence.
• CloseAutomaticTickets
Replaces the functionality of SetStatusRejectedOnReturnedEmail
and HandleGenericAutoreplies from the previous iteration
of development.
• CloseAutomaticTicketsFromOutside
Inspects the sender and possible IP addresses included in the
email headers, and based on these, determines whether the
ticket is connected to the University or not; If not, it is closed.
39
5- DELIVERED SOLUTION
• CreateGitLablssueOnCertificateTicket
Creates or updates a GitLab issue when an automatic certificate
expiration notice is received.
• HandleCopyrightlnfingement
This workflow recognises and parses copyright infringement
notices, which are in a known X M L format, extracts information
about the incident (i.e., IP address, time of incident detection,
file name, file hash, etc.), sends an automated reply to
the sender, and attempts to identify the user based on the IP
address and reported time through the user accounting agenda
of the Security Dashboard. IP address records can sometimes
be ambiguous within a time window, as Eduroam assigns IP addresses
dynamically. The result of the user search is announced
in a comment on the report ticket.
If there is a single user who can be definitively linked to the
reported IP address (i.e., a single record exists within the specified
time window), a new ticket is created and linked to the
existing report ticket, with the identified user as the requester.
The ticket contains a predefined message urging the user to
cease the activity. Both tickets are then closed.
If no user or multiple users are found to be linked to the IP
address, a manual intervention is required to determine the
culprit and send the notification. A template ticket with the
message is created and linked; however, the template ticket is
left open in this case.
• HandleGenericAutoreplies
Upon sending automatic reports to third parties (e.g., detection
of a network scan from the IP address registered to the
third party), an automated reply message is typically sent back.
Automation correctly sets the status of such tickets to "act" as
new correspondence was added; nevertheless, this behaviour is
undesirable. Therefore, this workflow closes tickets containing
known patterns present in the generic autoreplies.
• HandleProminentContact
Special care is given to the correspondence from or containing
40
5- DELIVERED SOLUTION
prominent contacts (faculty deans, rector, etc.). Upon receiving
such correspondence, a Mattermost notification is sent to
expedite the resolution.
• HashDiscoveredAttachments
A l l enclosed attachments are hashed, and their hashes are
added to a designated custom field.
• LinkWithTicketOnLinkWithHeader
If the ticket contains the "LinkWith" header, it is linked to the
ticket whose ID is present in the value of this header.
• MattermostNotificationOnAnalyticsCategory
When the custom field with the name "Category" is set to the
value "Analytics", a Mattermost message is sent to notify the
data analytics group.
• MattermostNotificationOnAnalyticsComment
If mention of "©analytics" is discovered in a new comment, the
data analytics group receives a Mattermost notification.
• MattermostNotificationOnAutomaticTicketFromUni
Upon receiving tickets in the Automatic RT Queue containing
an IP address registered in NetBox (i.e. belonging to the University),
a Mattermost message is sent to notify the incident
reaction group.
• MattermostNotificationOnCertificateTicket
The CreateGitLablssueOnCertificateTicket removed the need
to send Mattermost notifications on certificate notices, deprecating
this workflow.
• MattermostNotificationOnCSIRTWebForm
Users can submit an incident report through the CSIRT web
form, which generates an RT ticket. On such ticket creation, a
Mattermost message is sent.
• MattermostNotificationOnPentestTicket
This workflow sends a Mattermost notification on new tickets
received through email in the Pentest RT Queue, notifying the
threat management group.
41
5- DELIVERED SOLUTION
• SetCategoryForToolReport
Some external tools send email reports with the Category and
Subcategory headers. Their values are set in corresponding
custom fields by this workflow.
• SetCustomFieldsOnCreate
Extracts common email information stored in the Headers, such
as "From", "To", "Reply-To", etc., and fills the same-named
custom fields with the extracted data.
• SetDueOnTicketStatusChange
Part of the S L A support; O n ticket status change to "act" sets
Due to 2 workdays, and on status change to "wait" sets Due to
5 workdays as per the SLA.
• SetlPCustomFieldOnCreate
Extracts IP addresses from the newly created tickets, searches
NetBox for network and department information, and sets the
"IP", "Networks", "Departments", and "IP Mapping" custom
fields with the received data.
• SetNetworklnfoOnlPCustomField
Upon changing the "IP" custom field value, this workflow compares
the values in the "IP" and "IP Mapping" custom fields.
Based on the results, it either searches for missing NetBox data
and updates or deletes the custom field values.
• SetReportUUID
Sets the " U U I D " custom field if the same-named header is
found.
• SetSpamCategoryOnSpamHeader
Some email servers' spam filters set "X-Spam" header; if a
positive value is found, the "Category" custom field is set to
"Spam".
• SetStartsOnCreate
Upon ticket creation, the value of the "Starts" field is set to the
current time or the next workday if received during a weekend.
42
5- DELIVERED SOLUTION
• SetStatusActOnAutomaticCorrespond
If an email reply is received for the ticket in the Automatic RT
Queue, the ticket's body is checked against a list of exceptions.
When no exceptions apply, the ticket's status is set to "act" by
this workflow.
• SetStatusActOnEmailCorrespond
If an email reply is received regarding a ticket, this workflow
sets the ticket's status to "act".
• SetStatusRejectedOnReturnedEmail
Sometimes RT replies cannot be delivered correctly. On such occasions,
mail servers send notifications which (correctly) cause
tickets to be automatically reopened. This workflow recognises
familiar undelivered mail notifications and closes these tickets.
• SetStatusWaitOnWebCorrespond
Outgoing email messages also generate a Correspond transaction.
When an email message is sent from RT, this workflow
updates the ticket status to "wait".
• SetTicketPriorityOnCustomFieldChange
Generic workflow that reacts to custom field changes and updates
the ticket's priority accordingly. The custom field's name,
value, and resulting ticket priority are all configurable.
Periodic Workflows
• OpenStalledOverdueTickets
This periodic workflow is configured to run once an hour to
check all stalled tickets, whether they are overdue, and if so,
reopen them by setting the status "act".
• RetryFailedTransactions
When the subscriber loses connection or any other issue with
Temporal arises, it can be configured to store received transactions
in the Redis cache. In configurable time intervals (i.e.
10 minutes), the RetryFailedTransactions workflow checks Redis
for stored transactions and, in batches of 1000 transactions,
43
5- DELIVERED SOLUTION
retrieves them, updates their states in Redis from failed to processing
(in order not to execute them multiple times if the retry
is not finished within the time interval and another retry workflow
instance is triggered), and attempts to trigger the HandleTransaction
workflow with each one. After the batch is retried,
only the transactions of successfully executed workflows are
deleted from Redis.
Notes
Multiple external integrations, such as Mattermost, Trino, SecurityDashboard
(csirtmu-alpha), GitLab, etc., are required for a full production
deployment of Beta. Nonetheless, the demo is not focused on
interactions with these tools - for self-service and RT demonstration,
they are not necessary.
5.1.6 RT Ansible Deployment Playbook (rtir-deploy)
A previously mentioned deployment automation, in the form of an
Ansible playbook, was developed to deploy RT and install extensions
as a part of a colleague's bachelor's thesis [34]. It was maintained and
extended throughout the years by the members of the development
group.
The playbook can also be used to update the RT version on a running
instance of RT (this functionality was removed as it was deemed
unnecessary). It consists of dozens of tasks, split into multiple Ansible
roles. For the demo system, some parts were updated, others were removed,
and new components were added to deploy the implemented
services or supporting tools.
Changes
• Removed unnecessary roles that are not used anymore.
• Reworked the visibility role into the vector role.
• Created a self-signed demo certificate for the r t - t e s t . s v c .
c s i r t . muni. cz domain.
44
5- DELIVERED SOLUTION
• Adapted the RT role from RT version 5 to 6 (removed unsupported
plugins or located RT 6 compatible versions).
• Added and configured the RT Authen OAuth2 plugin for OIDC
support.
• Automated the installation of a custom RT "Scrip" for transaction
serialisation.
• Added installations of missing plugins (fixed reported warnings
or errors).
• Added "local_nats" role to install Docker, configure and run
NATS locally.
• Added "email_parser" role that installs and configures the
csirtmu-rt-email-parser.
• Optimised the installation of Perl dependencies from the A n sible
C P A N M 1
module to the Ubuntu A P T package manager
where possible.
• Created an SQL script based on the production RT database
data dump and configured the data restore to prepare a reproducible
demo environment.
• Added a role to copy and configure the implemented applications
and start the Docker Compose that orchestrates the
applications and necessary tools.
Keycloak Fixture Loader (csirtmu-auth-keycloak-fixture-loader)
A simple application created by the CSIRT technological development
group to read Y A M L configuration and, based on it, load realms,
clients, users, groups, roles, and other fixtures into Keycloak through
its API.
For the demo, the app was extended to include the ability to create
an audience mapper by adding a flag in the client config.
1. C P A N M is a Perl package manager.
45
5- DELIVERED SOLUTION
5.2 Infrastructure/External Tools
5.2.1 Unified Request System Deploy
Root directory of the delivered demo system. Contains all the projects,
the Compose file, the Vagrantfile, test emails in mbox format, Perun export,
and all the files required for deployment, except for configuration
files, to avoid confusion.
5.2.2 Vector and NATS
Vector is deployed using the "vector" Ansible role and is used to read
transactions that RT writes to the socket and forward them to the
NATS sinks according to the configuration.
For the demo system, NATS is run and initialised within the V M
using a separate Docker Compose, which is installed and configured
via an Ansible playbook executed by Vagrant during V M provisioning.
5.2.3 PostgreSQL
Multiple PostgreSQL databases are required in the Docker Compose
(Self-Service, Netbox, Outline, Keycloak, Perun Sync) and outside
of Docker for the RT. Two PostgreSQL instances are present in the
solution: one for the RT (installed directly via Ansible) and the other,
which contains all the remaining databases mentioned (installed via
a Compose file which is also copied and triggered via Ansible).
5.2.4 Other Deployed Tools
The below listed tools are deployed using the Docker Compose in the
virtual machine provisioned via Ansible.
• Temporal - temporal is used both for the execution of RT automations
and for synchronising Perun users.
• Dragonfly - cache for NetBox, Outline, and Beta.
• MinIO - object store for Perun exports.
• Keycloak - identity provider for NetBox, Outline, Self-Service
and RT.
46
5- DELIVERED SOLUTION
NetBox - asset manager for Self-Service integration showcase.
Outline - document server for Self-Service integration show-
case.
browser access
Self-Service Ul
load user data to DB
pass mbox file to parser access DB
± L
Self-Service backend Email Parser
create ticket create ticket
Perun Sync API
match sender to identity distribute work
RT
modify tickets
HandleTransaction
worker
distribute work
OIDC OIDC
write transaction to socket
Keycloak
HandleTransaction
worker
trigger handle workflow
Beta NATS subscriber
Vector subscribe to NATS subject
Outline
pass RT transactions
NetBox NATS
Legend
External
Tool
Implemented
Service
Figure 5.5: Delivered Solution
47
5- DELIVERED SOLUTION
5.3 System Description
Due to the complexity of the delivered solution (see Figure 5.5), this
section outlines the primary use cases and related information flows
through the system. Although entirely fictional, they represent what
an actual user interaction with the system might look like and what
happens in the background.
5.3.1 Email Use Case
A diagram capturing the data flow through the relevant parts of the
system during the email use case is visible in Figure 5.6.
Let us assume a user received an email addressed to their email
alias. The email contains suspicious content, urging the recipient to
click on the link and take immediate action. The user correctly identifies
the email as a phishing attack and reports it to the CSIRT team by
forwarding the email to the CSIRT email address.
The Sendmail MTA, deployed together with the RT, receives the
message and, based on its configuration, passes it to the RT email
parser script.
The email parser script extracts the sender's address from the email
headers and queries the Perun sync API. If an entry matching the
sender's email is found, the "From" header in the message is replaced
with the returned address ("<uco>@mail.muni.cz" is preferred in
the demo), and the original address is added as the "X-RT-OriginalRequestor"
header.
The message is passed to the RT mail gateway, and from its content,
a new ticket is created with the From header as the ticket requester.
Ensuring that users can access tickets submitted under their aliases
through their account, which is linked to only one email.
A service technician or handler can then communicate with the
user through the ticket by replying or commenting. This communication
is automatically sent as emails (to the user's email address) from
RT.
In the background, upon ticket creation, a transaction is generated
in the RT. Transactions are serialised using the custom Perl script and
written into the Unix socket where Vector listens.
48
5- DELIVERED SOLUTION
Perun Sync worker listen for changes
I
load user data to DB
pass mbox file to parser
access DB
Email Parser Perun Sync API
distribute work
I :
create ticket match sender to identity
RT
modify tickets
HandleTransaction
worker
distribute work
OIDC
Keycloak
Temporal
distribute work
HandleTransaction
worker
trigger handle workflow
Beta NATS subscriber
Legend
External
Tool
Implemented
Service
write transaction to socket
subscribe to NATS subject
1
Vector
pass RT transactions
Figure 5.6: Email Use Case
49
5- DELIVERED SOLUTION
Vector parses the transaction and, based on the defined rules (e.g.
RT queue where it originated), forwards it to the selected NATS sub-
ject.
Beta is subscribed to the NATS subject, and upon receiving a NATS
message, it parses the transaction and selects the workflows from its
configuration that are supposed to be executed.
These workflows are then passed to the HandleTransaction workflow
and executed as child workflows, which in turn affect the RT
ticket or external systems, as described in the workflow listing above.
5.3.2 Self-Service Use Case
Relevant parts of the system for the self-service use case and the flow
of data through it are captured in the diagram in Figure 5.7.
A user has an issue with setting up the VPN. They opted to report
the issue through the self-service portal, into which they logged in
using the company OIDC.
After logging in, they see possible steps that were loaded from
the self-service backend, and they are surprised to discover that their
company has a knowledge base in the form of a document server.
Intrigued, they try to search for documents concerning the V P N issue
they are facing.
The self-service portal calls the self-service backend with the user
query, and the backend, in turn, searches the Outline via its API. Some
documents are found; however, they contain information unrelated to
the issue. Now, the disappointed user decides to search in the relevant
area for possible next steps.
From the available options, they select the "Networks and Wi-Fi"
and then "Issues with V P N " , where they access information regarding
some common V P N issues. Regardless, the issue was neither clarified
nor resolved by this information, so the user selects the next step,
which is the Contact Form, where they enter information about the
type of V P N problem they encountered.
Upon form submission, the backend is invoked to create an RT
ticket with the entered form data. The user can view the tickets they
created on the Tickets page. They can also view the ticket in the RT by
clicking "view in RT" and logging in using the same OIDC account as
they used for the self-service portal.
50
5- DELIVERED SOLUTION
o o
browser access
User
Self-Service Ul
Staff
Legend
External
Tool
Implemented
Service
submit form handle user requests
J
Self-Service backend
create ticket
ProcessWorkflows
worker
HandleTransaction
worker
RT
distribute work distribute work
modify tickets
OIDC OIDC
Temporal
write transaction to socket
Keycloak
OIDC
Ttrigger handle workflow
I
Beta NATS subscriber
subscribe to NATS subject
-i pass RT transactions X
NetBox
access API
Figure 5.7: Self-Service Use Case
51
5- DELIVERED SOLUTION
A handler or technician can now access the ticket, and the rest of
the flow is the same as in the previous use case.
5.3.3 Perun User Data Flow
In the production environment, a synchronisation workflow listens
for new file uploads into a MinIO bucket. Perun facilities, resources,
and users are automatically exported in JSON format and uploaded
to the mentioned MinIO bucket upon modifications in Perun.
For the demo, a manual upload of the prepared JSON file is required
to trigger the modified synchronisation workflow and, therefore,
to load user alias data into the database, thus enabling user alias
lookup. A process captured in the diagram in Figure 5.8.
file upload
Legend
External
Tool
Implemented
Service
listen for changes
Perun Sync
Perun Sync Worker
work distribution
user data sync
Perun
SyncDB
Perun Sync API
Temporal Server
RT Email Parser
Figure 5,8: Perun User Synchronisation
5,3,4 Summary
The final product consists of a Vagrantfile that creates a V M and uses
Ansible to provision it by deploying instances of PostgreSQL, RT, Vector,
NATS (via Docker Compose), and the email parser. Additionally a
second Docker Compose file is used to deploy all the configured tools
via the "docker_deploy" Ansible role to the same V M . The second
52
5- DELIVERED SOLUTION
Compose file includes PostgreSQL, Temporal, Keycloak, MinIO, etc.
and all the implemented Python services (excluding the email parser),
i.e. Beta, Beta workers, self-service, self-service-backend, perun-sync,
etc.
The solution also contains a set of prepared testing files to demonstrate
the system's functionality, which can be found in the project's
root directory.
53
6 Implementation Process
In this chapter, the implementation process will be discussed in chronological
order to present the challenges encountered during the development
of the demo system.
6.1 csirtmu-beta
The implementation process began with the csirtmu-beta, as moving
the RT automations out of the RT to promote visibility and offer a retry
mechanism was the most pressing issue at the time, one that went
beyond just the demo request system. Beta operates as a standalone
production service, independent of the demo system, alongside the
RT.
Implementation began with familiarisation with the Perl mechanisms
for serialising transactions and custom RT automations that
were already in place.
As Temporal was already the go-to work orchestration tool used
by the technological development group, it was chosen to handle the
automations. The configuration of the subscribed workflows through
the Y A M L file was a central requirement that guided the entire architecture
of the solution. After testing the prototype with the NATS
subscriber and creating parsing structs for the transactions, the first
version of the handle transaction workflow was implemented.
This version triggered other workflows in a Temporal activity after
creating the Temporal client, which was not only inefficient but
also allowed only a retry of the entire activity, i.e., all the workflows
executed within it.
In a later version, it was changed to trigger the workflows from
the activity one by one, with control flow in the workflow body due
to an issue with naming that made child workflows unusable. A n d
again, this was changed in a later version when the naming issue was
resolved by removing the UUID from the workflow names, therefore,
allowing child workflows to be used instead.
After the first version of the handle transaction workflow was implemented,
a set of other workflows was steadily extended. At the start,
by rewriting already existing automations from Perl to Python and
54
6. IMPLEMENTATION PROCESS
later by adding new workflows based on the requirements of the incident
reaction group and other teams. Some workflows required rounds
of back-and-forth communication and fine-tuning before settling on
a final form. The following development was primarily focused on
feature requests, bug fixes, refactoring, and updating packages.
6.2 csirtmu-self-service and
csirtmu-self-service-backend
The second project that was developed was a Streamlit self-service
interface. The first steps involved familiarisation with the Streamlit
library and testing its limits, followed by the design of simple models
and testing the OIDC support.
After the OIDC, more complex models were implemented, such as
FormStep and FormFields. Although Streamlit allows mixing database
calls and other backend-related code within functions that control the
user interface, even promoting this practice in the documentation, it
undermines code reusability.
Therefore, the csirtmu-self-service-backend was implemented by
separating the database models, database calls, and external service
calls from the strictly user interface-related code, allowing it to be
later replaced for production use with a proper frontend application.
A simple REST API was implemented to facilitate communication
between the user interface and backend.
The final steps involved implementing the NetBox and Outline
search features, as well as testing the UI and import/export mecha-
nisms.
6.3 csirtmu-perun-sync
The next implemented part was the workflow to synchronise the Perun
users into the database. A workflow that subscribes to the MinIO
bucket, then parses newly uploaded JSON files for user data and stores
it in a database, was already implemented by colleagues. This workflow
was adapted to parse and store data relevant to the demonstration
use case.
55
6. IMPLEMENTATION PROCESS
However, due to miscommunication, at the time, it was not known
that the mentioned Perun JSON exports would provide user email
aliases in the future version. Therefore, to fill in the alias data, alternative
sources were considered, hence the implementation of the
AliasSync workflow, which parses aliases from a text file using regular
expression matching.
As this was not an intended feature of the demo system, it was
not prepared for showcase; nevertheless, it is present in the csirtmuperun-sync
code and mentioned here in the implementation process
description to provide a complete account.
Following the successful tests of synchronisation into a database,
a REST API was implemented to provide an interface for it.
6.4 rtir-deploy
The name "rtir-deploy" was historically chosen, as it was used to
provision the RT with the now-unused RTIR (RT Incident Response)
extension. After familiarising with Ansible, the virtualisation environment,
and the Ansible playbook, the first milestone was to deploy the
RT into a local virtual machine successfully via the playbook.
6.4.1 Local Virtual Machine Development
A virtual machine was created using Fedora's ready-to-use virtualisation
support packages, namely its Virtual Machine Manager1
.
To achieve a successful deployment, numerous modifications were
required, and it was sometimes challenging to diagnose issues, as the
playbook would become stuck at a task without any indication of a
problem and without any log data in the virtual machine.
The offending task, which detected and installed missing RT dependencies,
was later rewritten to address this issue and expedite
the playbook. In the updated version, dependencies, which had APT
alternatives (almost all), are installed using the APT Ubuntu package
manager from a predefined list, rather than being detected at runtime.
A few remaining packages that were not available as APT alternatives
1. https://docs.fedoraproject.org/en-US/quick-docs/
v i r t u a l i z a t i o n - g e t t i n g - s t a r t e d /
56
6. IMPLEMENTATION PROCESS
or required specific versions are installed using the Ansible C P A N M
module.
Some automated tasks were also added to mitigate issues that were
created by the unique environment of the locally provisioned virtual
machine - Vector role creation from the visibility role to remove a need
for connection to the production monitoring system, and creation of a
local NATS role that installs Docker Compose and starts up a NATS
service that is necessary for Vector to start correctly.
Manual integration testing with self-service was successful, and
subsequently, the next step was to adapt the playbook to utilise RT6.
Using RT6 led to the removal of a few extensions that did not support it
and were causing problems; some of these received updates since then
and were added back, while others were deemed inconsequential.
After having a functional RT6 deployment process, the OIDC support
options were examined. A functional plugin that enabled OIDC
interoperation while still maintaining the option to log in using classic
credentials existed; nevertheless, it did not support RT6 at the time.
Soon after, a forked repository that adapted the plugin for RT6 was
discovered, and a few days later, it was merged into the official plugin's
repository.
The plugin did not support Keycloak; regardless, since the OIDC
protocol affects some identity provider API features, it was possible
to adapt an existing configuration of a different identity provider
(Authentik) to force Keycloak support.
Following the successful OIDC integration, work on the csirtmu-rtemail-parser
began, and after its completion, an Ansible role to deploy
and configure it was added to the playbook.
However, configuring it correctly proved to be quite tricky because
the script needs to be executable by the Sendmail user used for executions
of forwarding scripts. For security reasons, this user drops all
unnecessary rights before execution, which caused permission-denied
errors when attempting to access the email parser files or run Python
(which was installed in a U V location as was later discovered). Additionally,
these errors were not reported or reported ambiguously in
Sendmail's logs.
57
6. IMPLEMENTATION PROCESS
6.4.2 Remote Virtual Machine Development
To test the email parsing and user identity consolidation subsystem, it
was decided to provision a testing virtual machine in the production
V M management system with a domain name and an M X DNS record.
The Perun sync was also deployed, into the production Kubernetes
cluster, and a domain was assigned to it.
After testing the identity consolidation, work on the local demonstration
began with the unified-request-system-deploy project.
6.4.3 Automatic Local Virtual Machine Demonstrator
Development
Some changes were required in the rtir-deploy to enable the local V M
provisioning to work smoothly; among others, configuration modifications
(path, U R L and name updates). A database data dump was
created from the configured RT, adapted, and added to the playbook to
be restored into the RT database on startup, providing a reproducible
RT environment with a stable configuration.
The final modifications, done in tandem with modifications in
unified-request-system-deploy, consisted of adding a new Ansible
role that would copy from the host, configure, and run the Docker
Compose file with all the implemented projects on the virtual machine.
This rework also required moving the configuration from individual
Y A M L files to the central Ansible configuration and using templating
to configure the services. It was implemented to mitigate issues with
firewalls and address translation when communicating between the
host and V M .
6.5 csirtmu-rt-email-parser
The email parser implementation proved relatively straightforward
after becoming familiar with the built-in Python library for working
with email messages, mbox format, and Sendmail alias forwarding.
A client for querying the Perun sync API was implemented swiftly
thereafter, and the whole user identity consolidation subsystem was
tested.
58
6. IMPLEMENTATION PROCESS
6.6 unified-request-system-deploy
Work on the local deployment began by reading the documentation
for Vagrant and the Vagrant-file, which would enable local V M deployment.
Discovering that Vagrant supports Ansible provisioning
as a part of the Vagrantfile was a pleasant surprise that facilitated a
smoother transformation. A critical part of the deployment was the
need for the host machine to be able to communicate with the V M
and vice versa.
This requirement was addressed by configuring the VM's network
through the Vagrantfile to create a private network and assigning a
static IP address to the V M within this network (i.e. "192.168.56.10").
In this network, the host will act as a gateway and be assigned an IP
address accordingly (i.e., "192.168.56.1").
A development Compose files were already used throughout the
implementation of the other parts, as it often entailed the use of thirdparty
tools, such as Temporal, NetBox, and Outline. These files were
joined into a single finalised version and configured.
A local instance of Keycloak was added, and with it came a requirement
to enrol the required entities into it. To this end, an older project
(csirtmu-auth-keycloak-fixtures) implemented for similar purposes
was reused and updated due to NetBox's token requirements.
After adding all of the necessary services to the Compose file and
configuring them, the whole deployment was tested. Testing revealed
some caveats that were introduced due to the complex networking in
the deployment. Primarily, the distinction between an IP address used
within containers and in the browser, and the requirement that Keycloak's
U R L remains the same throughout the entire OIDC client and
user authentication flow. Keycloak's URL differed when accessed from
the V M or container compared to the U R L required in the browser.
For example, Outline was configured to redirect users to
"http://localhost:8080/..." to access the Keycloak login page. Upon
successful login and redirect, Outline attempted to complete the login
procedure by accessing the userinfo endpoint, which is executed
within the Outline container. Therefore, to reach Keycloak, it must use
the U R L "http://keycloak:8080/..." (where Docker's internal DNS resolves
"keycloak" to a valid container address), since localhost would
lead to the container's localhost, not the host's. However, when this
59
6. IMPLEMENTATION PROCESS
was attempted, Keycloak would correctly restart the login process
since its address is also part of the issued access token, and it did not
match.
Adding an entry with Keycloak's relative address to both V M s '
and the host's "/etc/hosts" files and using only the
"http://keycloak:8080/..." U R L solved this problem.
6.7 csirtmu-auth-keycloak-fixtures
This project was outdated and required a tooling update to use current
development standards (e.g., replacing Poetry with UV, etc.).
Nonetheless, loading fixtures from the config file worked, and the only
necessary implementation change was to add an audience mapper
option that configures an audience mapper for the client, as NetBox's
OIDC implementation required this.
6.8 Final Testing
During testing on different machines, it was discovered that firewall
rules on some machines might interfere with communication between
the V M and Docker Containers - i.e., the RT login process via Keycloak
was interrupted after the redirect back to RT with the HTTP error 500
(logs revealed that RT could not fetch userinfo from Keycloak due to
error 111). All of the issues were resolved after the firewall rules were
removed.
Nonetheless, it was deemed to be too big a modification for demonstration
to alter firewall rules; therefore, a solution in the form of a new
Ansible role was implemented. The mentioned Ansible role, named
"docker_deploy", facilitates copying, configuring, and starting all the
implemented services and required tools via a Docker Compose file
in the V M , as Compose did previously (without Ansible) on the host
machine.
After testing and addressing the other minor issues discovered,
the installation and usage documentation, as well as the test files,
were added. The project files were then prepared for submission and
compressed.
60
7 Conclusion
This thesis aimed to explore and compare various options for satisfying
the identified requirements on a unified request system within the
University environment and to develop a demonstration system that
showcases the feasibility of using the RT as a dual self-service and
email interface for user requests.
A set of supporting applications was developed or modified to
fulfil the identified requirements on the system, enabling smooth
integration with the RT. To facilitate a seamless switch to the proper
production interface in the future, a self-service interface prototype
was implemented with a dedicated backend. Furthermore, a user
identity consolidation subsystem was developed to match user email
aliases to their University identity, consisting of Perun export parsing
and synchronisation to a database, an API to enable querying the
database, and an email parser to perform the matching based on
the extracted email data. Additional enhancements to the RT were
achieved by migrating automations to a dedicated service, which
improved visibility and provided a robust retry mechanism.
Demonstration of the entire system, which is locally deployed
with the RT at its centre, is facilitated by the cooperation of multiple
deployment and provisioning tools and their configuration, all of
which are delivered in the enclosed attachments.
The system sufficiently proves the viability of production use of
the RT with implemented supporting services. However, several modifications
will be necessary, among them the virtually obligatory switch
to a dedicated frontend application that would facilitate a richer user
interface without the drawbacks of Streamlit and to fully utilise the
capabilities of OIDC, as mentioned.
61
Bibliography
1. Jira Service Management [online]. Atlassian, 2025 [visited on 2025-
11-13]. Available from: https : //www. atlassian. com/software/
j ira/service-management.
2. Identity Access Management—Importance in Maintaining Security
Systems within Organizations. European Journal ofEngineering
and Technology Research [online]. 2023, vol. 8, no. 4, pp. 30-38 [visited
on 2025-11-14]. Available from DOI: 10.24018/ejeng. 2023.
8.4.3074.
3. Perun [online]. Masaryk University, 2025 [visited on 2025-11-13].
Available from: https: //perun-aai . org/.
4. PROCHÁZKA, Michal; LICEHAMMER, Slávek; MATÝSKA, Luděk.
Perun — Modern approach for user and service management. In:
2014 IST-Africa Conference Proceedings. 2014, pp. 1-11. Available
from DOI: 10.1109/ISTAFRICA. 2014.6880654.
5. Request Tracker [online]. Best Practical Solutions, LLC, 1996/2025
[visited on 2025-11-13]. Available from: https: //requesttracker.
com/.
6. NetBox [online]. NetBox Labs, 2025 [visited on 2025-11-13]. Available
from: https://netboxlabs.com/products/netbox/.
7. CSIRT M U , Incident Response Group. Jira Lessons Learned. [N.d.].
Internal report.
8. Outline [online]. General Outline, Inc., 2025 [visited on 2025-11-
13]. Available from: https ://www.getoutline. com/.
9. GitLab [online]. GitLab Inc., 2025 [visited on 2025-11-13]. Available
from: https: //docs . g i t l a b . com/.
10. Docker [online]. Docker Inc., 2025 [visited on 2025-11-13]. Available
from: https: //www. docker. com/.
11. Kubernetes [online]. The Kubernetes Authors, The Linux Foundation,
2025 [visited on 2025-11-13]. Available from: https : //
kubernetes.io/.
62
BIBLIOGRAPHY
12. Kustomize [online]. The Kubernetes Authors, The Linux Foundation,
2025 [visited on 2025-11-13]. Available from: https : //
kustomize.io/.
13. Vagrant [online]. HashiCorp, Inc., 2025 [visited on 2025-11-13].
Available from: https: //developer .hashicorp. com/vagrant.
14. Ansible [online]. Ansible project contributors., 2025 [visited on
2025-11-13]. Available from: https : //docs . ansible. com/.
15. Vector [online]. Datadog, Inc., 2025 [visited on 2025-11-13]. Available
from: https: //vector. dev/.
16. NATS [online]. NATS Authors, The Linux Foundation, 2025 [visited
on 2025-11-13]. Available from: https : //nats . io/.
17. JetStream [online]. NATS Authors, The Linux Foundation, 2025
[visited on 2025-11-13]. Available from: https: //docs .nats . io/
nats-concepts/Jetstream.
18. Temporal [online]. Temporal Technologies, 2025 [visited on 2025-
11-13]. Available from: https : //temporal. io/.
19. OAuth 2.0 [online]. Aaron Parecki, Chriss Messina, et al., 2025
[visited on 2025-11-13]. Available from: https: //oauth. net/2/.
20. JWT [online]. Okta, 2025 [visited on 2025-11-13]. Available from:
https://www.j wt.io/.
21. OpenID [online]. OpenID Foundation, 2025 [visited on 2025-11-
13]. Available from: https ://openid.net/.
22. Keycloak [online]. Keycloak Authors, The Linux Foundation, 2025
[visited on 2025-11-13]. Available from: https : //www.keycloak.
org/.
23. ISO/IEC 27000family - Information security management [online].
International Organization for Standardization, 2025 [visited on
2025-11-13]. Available from: https : //www. iso. org/standard/
iso-iec-27000-family.
24. UV [online]. Astral Software Inc., 2025 [visited on 2025-11-13].
Available from: https: //docs . a s t r a l . sh/uv/.
25. Streamlit [online]. Snowflake Inc., 2025 [visited on 2025-11-13].
Available from: https: //streamlit. io/.
63
BIBLIOGRAPHY
26. msgspec [online]. Jim Crist-Harif, 2025 [visited on 2025-11-13].
Available from: https: //j c r i s t h a r i f . com/msgspec/.
27. Starlette [online]. Encode OSS Ltd., 2018 [visited on 2025-11-13].
Available from: https: //starlette. dev/.
28. SQLAlchemy [online]. SQLAlchemy authors and contributors,
2025 [visited on 2025-11-13]. Available from: https : / /www .
sqlalchemy.org/.
29. Amazon S3 [online]. Amazon Web Services, Inc., 2025 [visited
on 2025-11-13]. Available from: https: //aws . amazon. com/s3/.
30. MinIO [online]. MinIO, Inc., 2025 [visited on 2025-11-13]. Available
from: https: //www.min. io/.
31. Redis [online]. Redis Ltd., 2025 [visited on 2025-11-13]. Available
from: https: //redis. io/.
32. Dragonfly [online]. DragonflyDB Ltd., 2025 [visited on 2025-11-
13]. Available from: https : //www. dragonflydb. io/.
33. BRYAN COSTALES Claus Assmann, George Jansen; SHAPIRO,
Gregory Neil, sendmail. 4th ed. United States: O'Reilly Media,
Inc., 2007.
34. ČECH, Michal. Integrace systému RTIR určeného pro bezpečnostní
týmy CSIRT. Brno, 2018. Available also from: https : //is .muni.
cz/th/dgdkf/.
64
A Attachment File Structure
• compose.yaml
• create-multiple-postgresql-databases.sh
• csirtmu-auth-keycloak-fixture-loader/
• csirtmu-beta/
• csirtmu-perun-sync/
• csirtmu-rt-email-parser/
• csirtmu-self-service/
• csirtmu-self-service/
• perun-0123456789.json
• README.md
• rtir-deploy/
• test_mails/
- joe-stephens-alias-mail.mbox
- joe-stephens-uco-mail.mbox
- john-kirby-alias-mail.mbox
- john-kirby-uco-mail.mbox
- tony-river-alias-mail, mbox
- tony-river-uco-mail.mbox
• Vagrantfile
A . ATTACHMENT FILE STRUCTURE
A.l /csirtmu-auth-keycloak-fixture-loader
• assets/...
• config/config.yaml
• csirtmu/auth_keycloak_fixture_loader/
- config.py
- init .py
- keycloak_api_client.py
- loader.py
- main.py
• Dockerfile
• LICENSE
• pyproject.toml
• README.md
• tests/...
• uv.lock
• wheels/...
A.2 /csirtmu-beta
• config/
- config.yaml
- worker_config.yaml
• csirtmu/
- beta/
- app.py
66
A . ATTACHMENT FILE STRUCTURE
- config.py
- handler.py
- handlerjbuilder.py
- init .py
- queuejbuilder.py
- redis_struct.py
- rt_queue.py
- beta_temporal/
- commons/...
- config.py
- constants.py
- external_services/
- alpha/...
- data_platform/...
- gitlab/...
- init .py
- mattermost/...
- netbox/...
- rt/...
- utils.py
- worker.py
- workflows/...
• Dockerfile
• kustomize/...
• pyproject.toml
• README.md
• resources/...
• tests/...
• typings/...
67
A . ATTACHMENT FILE STRUCTURE
• uv.lock
• wheels/...
• worker.Dockerfile
A.3 /csirtmu-perun-sync
• alembic.ini
• config/config.yaml
• csirtmu/perun_sync/
- alias_sync/...
- app.py
- cli.py
- config.py
- init .py
- perun_sync/...
- repositorypy
- temporal/...
• Dockerfile
• kustomize/...
• migrations/...
• pyproject.toml
• README.md
• typings/...
• uv.lock
• wheels/...
• worker.Dockerfile
68
A . ATTACHMENT FILE STRUCTURE
A.4 /csirtmu-rt-email-parser
• config/config.yaml
• csirtmu /rt_email_parser /
- config.py
- init .py
- main.py
- parser.py
- perun_sync/...
• pyproject.toml
• R E A D M E . m d
• uv.lock
• wheels/...
A.5 /csirtmu-self-service
• config/config.yaml
• csirtmu /self_service/
- app.py
- client.py
- config.py
- enums.py
- init .py
- models.py
- pages/
- init .py
- login.py
- main.py
69
A . ATTACHMENT FILE STRUCTURE
- tickets.py
- structs.py
- ui_helpers.py
• Dockerfile
• pyproject.toml
• README.md
• typings/...
• uv.lock
• wheels/...
• .streamlit/
- config.toml
- secrets.toml
A.6 /csirtmu-self-service-backend
• alembic.ini
• config/
- config.yaml
- steps/...
• csirtmu/
- external_services/
- init .py
- netbox/
- init .py
- netbox_client.py
- queries.graphql
- structs.py
70
A . ATTACHMENT FILE STRUCTURE
- outline/
- client.py
- init .py
- structs.py
- rt_client.py
- self_service_backend/
- app.py
- config.py
- dto_structs.py
- enums.py
- exporter.py
- init .py
- input_structs.py
- loader.py
- models.py
- repository.py
- stepjbuilder.py
• Dockerfile
• migrations/...
• pyproject.toml
• README.md
• typings/...
• uv.lock
• wheels/...
A.7 /rtir-deploy
• ansible/
- ansible-deploy-conf.yaml
71
A . ATTACHMENT FILE STRUCTURE
- playbook.yml
- roles/
- apache/...
- certs/...
- cron/...
- database/...
- docker_deploy/...
- email_parser/...
- local_nats/...
- perl/...
- postgresql/...
- rt/...
- sendmail/...
- vector/...
- webserver/...
• LICENSE
• README.md
72