Figure 3.4: IAM Sequence

1. Diagrammtyp & Architektur-Kontext

• Diagrammtyp: Konzeptionelles Interaktions- und Datenflussdiagramm (vereinfachtes Sequenz-/Kollaborationsdiagramm) zur Darstellung des Zugriffskontrollmodells.
• Architektur-Kontext: AUTOSAR Adaptive Platform (AP), Functional Cluster Identity and Access Management (IAM).
• Technischer Zweck: Visualisierung des Autorisierungsmechanismus nach dem RFC 2904 / XACML-Referenzmodell. Das Diagramm spezifiziert, wie Zugriffe einer Adaptive Application (Subject) auf geschützte Systemressourcen (z. B. Krypto-Schlüsselspeicher oder IPC-/Dienst-Kommunikation) über einen Policy Enforcement Point (PEP) und einen zentralen/lokalen Policy Decision Point (PDP) anhand konfigurierter Manifeste validiert und durchgesetzt werden.

2. Komponenten, Entitäten & Schnittstellen

• Subject (Adaptive Application Local or Remote):
  • Nicht-privilegierter POSIX-Prozess (ara::core::Result), der als lokaler Prozess (IPC/OS-Domain-Socket) oder remote (z. B. via SOME/IP über das Netzwerk) operiert.
  • Besitzt eine kryptografisch/systemisch verifizierbare Identität (POSIX UID/GID, Process ID, Security Identifier).
• Object Provider (Functional Cluster / Daemon):
  • Ressourceneigner und Service-Anbieter innerhalb der AUTOSAR Adaptive Platform (z. B. Crypto Daemon für ara::crypto, Communication Management Binding/Library für ara::com).
  • Stellt die angeforderte Ressource bereit (z. B. Key Slot, Service Interface Event, Field, Method).
• Policy Enforcement Point (PEP):
  • Logisch und funktional in den Object Provider bzw. in dessen Middleware-Schicht integrierter Kontrollpunkt.
  • Interzeptiert alle eingehenden Anfragen des Subjects, isoliert die Ressource vor nicht-autorisiertem Zugriff und erzwingt das Votum des PDP.
• Policy Decision Point (PDP):
  • Autorisierungsinstanz (zentraler IAM-Daemon oder statisch generierte Auswertungslogik).
  • Evaluiert Zugriffsanfragen gegen die statisch definierten Berechtigungsregeln und Manifest-Einträge.
• Manifest (Execution / Service Instance / Access Control Manifest):
  • Maschinengenerierte Konfigurationsartefakte (ARXML bzw. kompilierte/geparste Binär-Repräsentationen wie JSON/CBOR).
  • Enthält deklarative Sicherheitsbeschreibungen: Identität des Subjects, Intentionsdeklarationen (Access Grants, Service- und Crypto-Intents).

3. Dynamisches Verhalten & Sequenzablauf

Der Kontroll- und Datenfluss erfolgt in vier diskreten, sequenziellen Phasen:

1. Step 1 – Resource Request (Subject → Object Provider):
   • Trigger: Das Subject ruft eine Plattform-API auf (z. B. Öffnen eines Key Slots in ara::crypto oder Aufruf von FindService / Subscribe in ara::com).
   • Übertragung: Synchrone oder asynchrone Interprozess-Nachricht an den Object Provider.
2. Step 2 – Policy Query (PEP → PDP):
   • Der PEP fängt die Anfrage ab, extrahiert den Kontext (Subject-Identität, Resource-Identifier, angeforderte Operation/Intent) und sendet eine synchrone Autorisierungsabfrage an den PDP.
3. Step 3 – Manifest Evaluation & Decision (PDP → Manifest → PEP):
   • Der PDP lädt/parst die hinterlegten Manifeste bzw. liest vorinitialisierte Cache-Tabellen aus.
   • Regelabgleich: Abgleich der angeforderten Intention mit den für das Subject autorisierten Intents/Grants der Policy.
   • Rückmeldung: Binäres Autorisierungsvotum (Grant / Deny) wird an den PEP retourniert.
4. Step 4 – Enforcement & Response (PEP → Subject):
   • Im Erfolgsfall (Grant): Der Object Provider führt die Operation aus (z. B. Rückgabe eines Key-Slot-Handles, Bestätigung des Event-Abonnements).
   • Im Fehlerfall (Deny): PEP blockiert den Ressourcenzugriff. Rückgabe eines spezifischen Fehlercodes (z. B. SecurityErrorDomain, AccessDenied oder Negative Response Code / NRC) an das anfragende Subject. Ein unautorisierter Direktzugriff auf die Hardwareressource/Daemon-Interna wird verhindert.

4. Normative Relevanz & Entwickler-Hinweise

• Manifest-Konfiguration (ARXML):
  • Applikationsentwickler müssen Zugriffsrechte explizit im Execution Manifest / IAM Manifest deklarieren (IAMGrant, ServiceInstanceDeployment, CryptoKeySlotUsage). Nicht deklarierte Intents resultieren deterministisch in einem Laufzeit-Deny (ara::core::ErrorCode).
• Performance & Latenzbudgets:
  • PEP-PDP-Roundtrips verursachen IPC- und Parsing-Overhead. Im Stack-Design müssen PDP-Entscheidungen typischerweise gecacht werden (z. B. Permission-Token nach initialem Subscribe oder Erhalt des Krypto-Handles), um hochfrequente Datenpfade nicht zu blockieren.
• Fehlerbehandlung (API-Vertrag):
  • Applikationscode darf nicht von einer dauerhaft erfolgreichen Ressourcenbereitstellung ausgehen; ara::core::Result<T> muss zwingend auf IAM-spezifische Fehlerkategorien geprüft werden.
• Zero Trust & Tamper Resistance:
  • Der PEP muss zwingend auf Kernel- oder vertrauenswürdiger Daemon-Ebene durchgesetzt werden. Ein kompromittiertes Subject im User Space darf weder Manifeste manipulieren noch die PEP-Ebene umgehen können. Identitäten müssen über OS-Integritätsmechanismen (z. B. SELinux-Labels, SO_PEERCRED bei Unix Domain Sockets) verifiziert werden.