## 5 Application of IdMSecMan  
In this section, we applied IdMSecMan in the areas of identification (see Section 5.1), authentication (see Section 5.2), and authorization (see Section 5.3). The applications explain the contribution of IdMSecMan practically. Table 2 provides an overview of which action of identity management is relevant on which SABSA layer. The table indicates that identification, authentication, and authorization need to work hand in hand. Whileauthentication is progressing in research and practice, identification and authorization are less regarded. The context of these applications is summarized in Table 3. Here, the assets (what), motivation (why), process (how), people (who), location (where), and time (when) are specified for identity management and identification, authentication, and authorization, according to SABSA's scheme. This ensured the architectural traceability and justification for the elements of the architecture. All aspects of identity management are relevant anytime. Based on the table, we see that policies are important besides technology. Hence, security controls are needed for both sides. The individual actions are detailed in the following by applying the use case.  
The descriptions were partly based on the computer science department of a university used for the case study in Section 6. The production environment mainly consisted of various physical, and especially virtual, Linux-based machines for different purposes, including operations and infrastructure. In addition, several heterogeneous laboratory infrastructures operated. The infrastructure, hence, consisted of different user groups, projects, and resources (central and decentral) with various requirements of trust, data protection, and security. While central services (such as project management software and GitLab), and servers for projects, were administrated centrally, professors and researchers might also run their own infrastructures. The projects again had different requirements, ranging from public to restricted projects. Even though the risks and benefits of changes typically did not result in a higher budget, security incidents might have consequences for upcoming projects and collaborations. As a consequence, their risks were estimated based on that.  
\begin{table}
\begin{tabular}{c c c c c} \hline
**SABSA Layer** & **Identity Management** & **Identification** & **Authentication** & **Authentication** \\ \hline Contextual & Organizational structure and regulations & \begin{tabular}{c} GDPR \\ Concepts for identity proofing and \\ verification \\ \end{tabular} & \begin{tabular}{c} Costs of, e.g., incidents \\ Authentication concept \\ Trust \\ \end{tabular} & \
\begin{tabular}{c} Role concept \\ Trust \\ \end{tabular} \\ \hline Physical & User interface, security & Identification methods &
\begin{tabular}{c} Authentication methods, physical \\ components \\ Access control system \\ Access, roles \\ \end{tabular} \\ Component & Functions, components for security & Identification & Authentication components & Access, roles \\ \hline Management & User support & Identification management & Authentication lifecycle & Control lists \\ \hline \end{tabular}
\end{table}
Table 2: Integration of SABSA with IdMSecMan.  
\begin{table}
\begin{tabular}{c c c c c c c} \hline
**SABSA** & **What** & **Why** & **How** & **Who** & **Where** & **When** \\ \hline Identity Management & Management of identities & Security & Processes, policies, best practice & Stakeholders & Anywhere & Anytime \\ \hline Identification & Digital identity & Management of identity & Processes related to identities & Stakeholders & Anywhere & Anytime, business hours \\ \hline Authentication & Authentication of user & Verifying identities & Authentication lifecycle & Stakeholders & Anywhere & Anytime, business hours \\ \hline Authorization & Access to resources & Access protection & Access policies & Stakeholders & Anywhere & Anytime, business hours \\ \hline \end{tabular}
\end{table}
Table 3: Context of IdMSecMan.