39687180
| Frage | Antworten |
| Authentifizierungsmethoden | Passwort Multi- / 2-Faktor-Authentifizierung Biometerische Authentifizierung Tokens Smartcard One-Time-Passwort Zertifkate Passkey Single Sign-On |
| Rollenbasierte Zugangskontrolle | Authentifizierung aufgrund von Rolle (role-based access control, RBAC) Anders: attributbasierte Zugangskontrolle (attribute-based access control, ABAC) authentifiziert aufgrund Merkmalen |
| Authentifizierung & Autorisierung - Basic Methods | Network Access Control (reguliert den Zugang zu Netzwerken) Application Programming Interface (API): ermöglicht Kommunikation zwischen SW-Komponenten |
| Scopes | definieren Zugangsberechtigungen können Zugriff beschränken Beispiele: workflow, user:email:, repo |
| (Sicherheits-)Protokoll | definiert Format und Ablauf von Nachrichten zwischen Netzwerkteilnehmern definiert Aktionen nach Erhalt oder Senden einer Nachricht Sicherheitsprotokoll definieren wie Informationen sicher im Netzwerk ausgetauscht werden |
| Request for Comments (RFC) | formelle Dokumente der Internet Enigneering Task Force (IETF), die technische und organisatorische Aspekte des Internets spezifizieren Beispielprotokolle: TLS1.3, OAuth, SSH Warum wichtig? Kompatibilität, Konsistenz, Zuverlässigkeit, Innovation, Konformität |
| OAuth2.0 - Definition | Bevollmächtigendes Protokoll eine Softwareapplikation (Client) bekommt im Auftrag eines Ressourcen-Besitzers die Erlaubnis auf diese Ressource zuzugreifen |
| Wie man Zugriffe nicht erlauben sollte - First Try | Kopieren der Zugangsdaten eines Ressourcen-Besitzers Problem: gleiche Zugangsdaten -> einfacher zu stehlen Client kennt Benutzerpasswort die Ressource kann nicht zwischen Benutzer und Client unterscheiden |
| Wie man Zugriffe nicht erlauben sollte - Second Try | Universaler Schlüssel, der es Client erlaubt auf alle Ressourcen von allen Benutzern zuzugreifen Problem: Client kennt zwar nicht die Zugangsdaten des Benutzers, aber unlimitierter Zugang, der bei Diebstahl alle Ressourcen für den Angreifer erreichbar macht |
| Wie man Zugriffe nicht erlauben sollte - Third Try | ein spezielles Passwort (oder Token), sodass nur die spezifische Ressource für den Client erreichbar ist Problem: Client kennt zwar nicht die Zugangsdaten des Benutzers und das spezielle Passwort ist nur auf die Ressourcen des einen Benutzers anwendbar, aber Extra-Zugangsdaten, die verwaltet werden müssen Schon gut, aber ein Sicherheitsprotokoll fehlt! |
| Password-sharing Antipattern | ein Benutzergeheimnis wird direkt mit einer Anwendung geteilt => Anwendung kann so tun, als wäre sie der Benutzer Viele Implementierung verwenden diesen Ansatz aber noch... NICHT MACHEN! |
| OAuth2.0 Authorisierungsrahmen - RFC 6749 | gewährt einer Anwendung limitierten Zugang zu einem HTTP Service im Auftrag eines Ressourcenbesitzers entweder übernimmt dieser das Genehmigen mit dem HTTP Service oder erlaubt der Anwendung, sich diese Genehmigung selbstständig zu holen |
| OAuth Client | SW-Anwendung, die Zugang zur geschützten Ressource möchte im Auftrag des Ressourcenbesitzers |
| Protected Resource | über HTTP Server erreichbar und Zugriff via OAuth Token validiert Token bevor Zugang gewährt wird |
| Resource Owner | delegiert Zugriff an den Client Person, die Client gerne mit einer Anwendung (auf der Ressource läuft) verbinden würde |
| Authorization Server | HTTP Server, der Ressourcenbesitzer ermöglicht Client zu autorisieren stellt Client Tokens zur Verfügung |
| GitLab Personal Access Tokens | GitLab-Benutzer können für jede Anwendung einen personalisierten Zugriffstoken generieren, den sie mit ihrem GitLab verbinden möchten nutzt OAuth2.0 um sicheren Zugang zu gewähren |
| OAuth2.0 Flow | zu keinem Zeitpunkt sind die Zugangsdaten des Benutzers sichtbar Authorization Server sendet zusätzlich zum Access- noch einen Refresh-Token |
| OAuth2.0 - Authorization Code Grant Type | |
| OAuth2.0 - Refresh Token Grant Type | erlaubt down-scoping |
| Komplexität | Wann immer es möglich ist sollte Komplexität von Clients auf Server verschoben werden |
| Back Channel | nutzt direkte HTTP Verbindungen zwischen Komponenten (Browser nicht beteiligt) |
| Front Channel | nutzt HTTP Umleitung durch Browser, da keine direkte Verbindung vorhanden ist |
| OAuth2.0 - Grant Types | +Refresh Token +Device Code |
| OAuth2.0 - PKCE | |
| OAuth2.0 - Introspection Protocol | erlaubt der Protected Resource den Authorization Server nach dem Status eines Access Token zu fragen |
| OAuth2.0 vs OIDC | OAuth2.0 ist kein Authentifizierungsprotokoll OIDC hingegen schon und stellt innerhalb des OAuth Flow Authentifizierung und Identitätsinformationen basierend auf ID Tokens bereit |
| OpenID Connect (OIDC) | |
| OIDC - ID Token | iss = Issuer (Ausgeber) eines Tokens sub = subject-identifier (Benutzer) des Tokens aud = audience (Empfänger) des Tokens exp = expiration (Ablaufdatum) des Token iat = Zeit an dem der Token ausgestellt worden ist |
| Webhook | erlaubt es Servern und Web-Services, Ereignis-basiert miteinander zu kommunizieren und automatisierte Aufrufe zu tätigen |
| ContainerSSH | startet einen neuen Container für jede SSH-Verbindung (Kubernetes, Docker, Podman) in diesem kann der Benutzer arbeiten bis er die Verbindung trennt, dann wird auch der Container entfernt Authentifizierung und Container-Konfiguration erfolgen automatisch durch Webhooks (kein Benutzer notwendig) |
Möchten Sie mit GoConqr kostenlos Ihre eigenen Karteikarten erstellen? Mehr erfahren.