Figure 14.2: IAM sequence

1. Diagrammtyp & Architektur-Kontext

• Klassifikation: Hybrides Architektur- und Interaktions-/Kollaborationsdiagramm mit sequenzieller Ablaufnummerierung (basierend auf dem XACML-/RFC-2753-Sicherheitsmuster für Access Control).
• Technischer Zweck: Spezifikation des grundlegenden Autorisierungs- und Zugriffskontrollmodells der AUTOSAR Adaptive Platform (Identity and Access Management – IAM).
• Funktionale Einordnung: Absicherung von Plattform-Ressourcen (z. B. Crypto Key Slots, Persistency-Bereiche) und IPC-/Service-Schnittstellen (z. B. Event-Subscriptions oder Method-Calls via ara::com) gegen unberechtigte Zugriffe durch lokale oder entfernte Applikationen über statisch deklarierte Zugriffsrechte (Grants/Intents).

2. Komponenten, Entitäten & Schnittstellen

• Subject:
  • Rolle: Konsument/Client (Adaptive Application, lokal als Linux/POSIX-Prozess oder remote über Netzwerkschnittstelle angebunden).
  • Identität: Identifiziert über Prozessattribute (POSIX UID/GID, Security Credentials) bzw. Security Extensions im Kontext des Execution Manifests.
• Object Provider:
  • Rolle: Ressourcen-verwalter bzw. Funktionscluster-Daemon/Bibliothek (z. B. Crypto Daemon für ara::crypto, Communication Management Binding/Library für ara::com, Persistency Daemon für ara::per).
• PEP (Policy Enforcement Point):
  • Rolle: Durchsetzungsinstanz, integraler Bestandteil oder vorgeschaltetes Kontrollmodul des Object Providers. Interzeptiert eingehende Ressourcenanforderungen und setzt das Urteil des PDP zwingend durch.
• PDP (Policy Decision Point):
  • Rolle: Zentrale logische Entscheidungsinstanz des IAM-Subsystems. Bewertet die Autorisierungsanfrage anhand der konfigurierten Zugriffsrichtlinien und Manifest-Regeln.
• Manifest:
  • Rolle: Konfigurations- und Datenbasis (Execution Manifest / Service Instance Manifest / IAM Grant Model).
  • Inhalt: Statische Zuordnung von Subjekt-Identitäten (Process, Executable) zu autorisierten Intents bzw. Zugriffsrechten (GrantDesign, ServiceInterfaceDeployment).
• Beziehungen & Kopplung:
  • Subject → Object Provider: Asynchrone/synchrone API-Anforderung über IPC (Unix Domain Sockets, Shared Memory) oder Middleware-Bindings.
  • Object Provider / PEP ↔ PDP: Interne Schnittstelle (lokale IPC oder direkter Funktionsaufruf innerhalb des Plattform-Stacks).
  • PDP → Manifest: Lesezugriff auf das geparste ARXML-/JSON-Modell zur Laufzeit (oder Zugriff auf vortranspilierte/gecachte Policies in der Plattform).

3. Dynamisches Verhalten & Sequenzablauf

Der Ablauf erfolgt in vier chronologischen Schritten:

1. Ressourcenanforderung (Trigger):
   • Das Subject fordert Zugriff auf eine Plattform-Ressource an (z. B. Belegung/Zugriff auf einen KeySlot in ara::crypto oder Aufruf von FindService/Subscribe auf ein Event via ara::com).
2. Autorisierungsprüfung (PEP → PDP):
   • Der dem Object Provider zugeordnete PEP fängt den Aufruf ab und generiert eine Zugriffsanfrage an den PDP, bestehend aus Subjekt-Identität, Ziel-Objekt und gewünschter Operation (Intent).
3. Policy-Evaluierung & Entscheidungsfindung (PDP → Manifest → PEP):
   • Der PDP liest die hinterlegten Manifest-Definitionen aus. Er prüft, ob der angeforderte Intent mit den für die Identität des Subjects im Manifest deklarierten Grants übereinstimmt.
   • Der PDP trifft ein Urteil (Access Granted / Access Denied) und meldet die Entscheidung synchron/asynchron an den PEP zurück.
4. Durchsetzung & Response (PEP → Subject):
   • **Positivfall (Permit):** Der PEP gibt die Anfrage frei; der Object Provider führt die Operation aus und liefert das Ergebnis an das Subject.
   • **Negativfall (Deny):** Die Ausführung wird blockiert. Der PEP veranlasst das Senden einer Fehlermeldung (im Diagramm generalisiert als NRC bzw. ara::core::Result<T, ara::core::ErrorCode>), z. B. SecurityErrc::kAccessDenied oder ComErrc::kGrantEnforcementFailed.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Deklaration zwingend erforderlich: Jeder Zugriff auf geschützte Ressourcen muss zur Integrationszeit explizit im ARXML-Modell (IAM Grant Design, ServiceInstanceToProcessMapping) deklariert sein. Nicht deklarierte Zugriffe werden vom PDP standardmäßig verworfen (Default Deny).
• Fehlerbehandlung auf Applikationsebene: Applikations-Entwickler dürfen nicht von implizitem Zugriff ausgehen. Alle API-Rückgaben, die durch den PEP geschützt sind, kapseln Fehler via ara::core::Result (z. B. Rückgabe systemspezifischer Zugriffsfehler anstelle von Nutzdaten).
• Performance- & Latenz-Auswirkungen: Die Evaluation über den PDP erzeugt bei dynamischen Aufrufen Overhead. Plattform-Stacks cachen PDP-Entscheidungen häufig für bestehende Sessions/Handles (z. B. einmalige Prüfung bei Subscribe(), nicht bei jedem einzelnen Event-Empfang).
• Prozess-Authentizität (Platform Integrators): Die Integrität der Subject Identity hängt an der zugrundeliegenden OS-Sicherheit (z. B. Linux cgroups, DAC, POSIX Capabilities, SELinux/AppArmor). Ein Spoofing der Prozess-Credentials hebelt den PDP aus; die Absicherung der OS-Isolation ist zwingende Integrationsvoraussetzung.