2025-01-29 00:54:27 +01:00
|
|
|
%
|
|
|
|
|
% Chapter: Technische Umsetzung
|
|
|
|
|
%
|
|
|
|
|
|
|
|
|
|
\chapter{Technische Umsetzung}
|
|
|
|
|
\section{Berechtigungsverwaltung}
|
2025-01-29 15:56:05 +01:00
|
|
|
\subsection*{Ausarbeitung der Herangehensweise}
|
|
|
|
|
Zunächst wurde gebrainstormed, welche Herangehensweisen hier möglich sind.
|
|
|
|
|
Ein Artefakt des Brainstormings ist eine Mind-Map, die unter \fullref{app:ideensammlung} zu finden ist.
|
|
|
|
|
Der aus dieser Mindmap, nach individueller Meinung des Autors, vielversprechenste Ansatz ist es,
|
|
|
|
|
die \ac{1P}-Restful-API zu verwenden.
|
|
|
|
|
Bei diesem Ansatz würden Administratoren und Entwickler API-Keys für \ac{1P} erhalten.
|
|
|
|
|
Entwickler haben mit ihren Keys bestimmte Leseberechtigungen $r$ und Administratoren
|
|
|
|
|
die Berechtigung $r$ zu verändern.
|
|
|
|
|
|
|
|
|
|
\begin{nicepic}
|
|
|
|
|
\includegraphics[width=0.75\textwidth]{images/dev-stuff-via-api-keys.png}
|
|
|
|
|
\captionof{figure}{Relationsdiagramm: Ansatz 1 | 1Password-API}
|
|
|
|
|
\caption*{Quelle: Eigene Darstellung}
|
|
|
|
|
\label{fig:ansatz-1-mit-api-keys}
|
|
|
|
|
\end{nicepic}
|
|
|
|
|
|
|
|
|
|
Dieser Ansatz wurde zeitnah als unumsetzbar erkannt und verworfen, da \ac{1P} das nachträgliche Verändern
|
|
|
|
|
von API-Key-Berechtigungen nicht erlaubt.
|
|
|
|
|
|
|
|
|
|
|
2025-01-29 00:54:27 +01:00
|
|
|
\section{Integration in Ansible}
|
|
|
|
|
|
