Falcon setzt auf moderne Sicherheitsstandards und unterstützt primär OIDC (OpenID Connect) mit OAuth 2.1. Um maximale Kompatibilität zu gewährleisten, können auch Legacy Identity Provider integriert werden.
Die Basiskonfiguration kann vom Kunden vorgenommen werden, während erweiterte Einstellungen für Legacy-Systeme ausschließlich durch einen Techniker von Nordantech konfiguriert werden müssen.
📌 Wichtiger Hinweis: Die möglichen Endpunkte sind auf Standard-IDPs wie Microsoft Entra und Google Identity limitiert. Bei Bedarf können durch Nordantech weitere Standard-Provider oder individuelle Provider-URLs für einzelne Hubs ergänzt werden.
Verantwortlichkeiten
Kunde: Basis-Einstellungen können selbstständig in Falcon vorgenommen werden.
Nordantech-Techniker: Legacy-Anpassungen und Provider-Erweiterungen erfolgen ausschließlich durch Supportanfrage.
Generelle Kundeneinstellungen
Diese Einstellungen können Sie als Administrator selbstständig in Falcon vornehmen und verwalten.
Issuer
Die URL des Identity Providers, die diesen eindeutig identifiziert.
Format: Vollständige URL
Beispiele:
Microsoft Entra:
https://login.microsoftonline.com/{tenant-id}/v2.0Google:
https://accounts.google.com
Verwendung: Dies ist die Basis für alle OIDC-Operationen und die Token-Validierung. Der Issuer muss exakt mit dem iss-Claim in den vom IdP ausgestellten Tokens übereinstimmen.
Client ID
Die eindeutige Client-ID, die Ihr IDP für Falcon bereitgestellt hat.
Format: UUID oder String, je nach Provider
Zweck: Identifiziert Falcon gegenüber dem Identity Provider und wird für alle OAuth/OIDC-Flows benötigt.
Client Secret
Das geheime Passwort für die Client-Authentifizierung.
Format: Alphanumerischer String
Sicherheit: ⚠️ Behandeln Sie diesen Wert streng vertraulich. Er wird in Falcon verschlüsselt gespeichert.
Empfehlung: Regelmäßige Rotation alle 6-12 Monate
Zweck: Ermöglicht die sichere Server-zu-Server-Kommunikation zwischen Falcon und Ihrem Identity Provider. Ohne das korrekte Secret können keine Tokens ausgetauscht werden.
Discovery
Aktiviert die automatische Erkennung aller OIDC-Endpunkte und der Konfiguration.
Standard: Aktiviert
Funktionsweise:
Ruft die URL
{issuer}/.well-known/openid-configurationabLiest alle verfügbaren Endpunkte aus der OIDC-Discovery-Konfiguration
Ermittelt automatisch unterstützte Features, Algorithmen und Scopes
Speichert die Konfiguration im Cache
Vorteile:
Keine manuelle Endpunkt-Konfiguration erforderlich
Automatische Anpassung bei Änderungen am IdP
Reduzierte Fehleranfälligkeit durch manuelle Eingaben
Compliance mit OIDC-Standards
Empfehlung: Sollte bei modernen IdPs immer aktiviert sein.
Provisioning
Legt fest, ob Benutzer automatisch beim ersten Login angelegt werden (Just-in-Time Provisioning).
Standard: Aktiviert (JIT)
JIT aktiviert:
Benutzer werden beim ersten erfolgreichen Login automatisch in Falcon erstellt
Alle verfügbaren Attribute werden aus dem IdP übernommen
Kein manueller Aufwand für die Benutzeranlage erforderlich
Ermöglicht schnelles Onboarding neuer Mitarbeiter
Ideal für große Organisationen und dynamische Teams
JIT deaktiviert:
Benutzer müssen vorab manuell in Falcon angelegt werden
Login nur für bereits existierende Benutzer möglich
Volle Kontrolle über den Benutzerzugriff
Erfüllt strenge Compliance-Anforderungen
Empfohlen für hochsensitive Bereiche oder kleine, stabile Teams
Prompt
Steuert, ob der Benutzer bei jedem Login aktiv sein Konto auswählen muss.
Standard: Aktiviert (select_account)
Benutzerauswahl aktiviert:
Zeigt dem Benutzer die Kontoauswahl-Seite beim Login
Benutzer muss explizit sein Konto auswählen
Verhindert versehentliche Anmeldung mit falschem Konto
Empfohlen für Umgebungen mit mehreren Konten pro Benutzer
Ideal für Shared Workstations oder öffentliche Computer
Benutzerauswahl deaktiviert:
Automatischer Login mit dem aktuell aktiven IdP-Konto
Keine Unterbrechung durch Kontoauswahl
Schnellerer Login-Prozess
Geeignet für dedizierte Arbeitsplätze mit einem Konto pro Benutzer
Authorization Endpoint
Die URL, an die der Benutzer zur Autorisierung weitergeleitet wird.
Format: Vollständige URL
Verwendung: Initiiert den Login-Prozess beim Identity Provider. Der Benutzer wird zu dieser URL weitergeleitet, um sich anzumelden und die Anwendung zu autorisieren.
Bei aktiviertem Discovery: Wird automatisch aus der OIDC-Konfiguration geladen und muss nicht manuell eingetragen werden.
Wann konfigurieren: Nur wenn Discovery nicht funktioniert oder Sie spezifische Endpunkte überschreiben möchten.
Token Endpoint
Die URL zum Austausch des Authorization Codes gegen Access Tokens.
Format: Vollständige URL
Verwendung: Nach erfolgreicher Authentifizierung tauscht Falcon den erhaltenen Authorization Code an diesem Endpunkt gegen ein Access Token und ID Token.
Bei aktiviertem Discovery: Wird automatisch aus der OIDC-Konfiguration geladen.
Wann konfigurieren: Nur wenn Discovery nicht funktioniert oder Sie spezifische Endpunkte überschreiben möchten.
Userinfo Endpoint
Die URL zum Abruf der Benutzerinformationen.
Format: Vollständige URL
Verwendung: Lädt die Profildaten des Benutzers nach erfolgreicher Authentifizierung. Liefert Informationen wie Name, E-Mail-Adresse und weitere Attribute.
Bei aktiviertem Discovery: Wird automatisch aus der OIDC-Konfiguration geladen.
Wann konfigurieren: Nur wenn Discovery nicht funktioniert oder Sie spezifische Endpunkte überschreiben möchten.
JWKS URI
Die URL zu den öffentlichen Schlüsseln des IDPs zur Token-Validierung.
Format: Vollständige URL
Verwendung: Falcon ruft von dieser URL die öffentlichen Schlüssel ab, um die Signatur der empfangenen JWT-Tokens zu validieren. Dies ist essentiell für die Sicherheit, da nur so sichergestellt werden kann, dass die Tokens tatsächlich vom angegebenen IdP stammen.
Bei aktiviertem Discovery: Wird automatisch aus der OIDC-Konfiguration geladen.
Wann konfigurieren: Nur wenn Discovery nicht funktioniert oder Sie spezifische Endpunkte überschreiben möchten.
Legacy-Provider-Einstellungen
⚠️ Wichtig: Die folgenden Einstellungen können ausschließlich durch Nordantech-Techniker angepasst werden. Sie sind nur bei Legacy Identity Providern erforderlich, die nicht vollständig OIDC-konform arbeiten oder spezielle Anpassungen benötigen.
Die erweiterten Einstellungen erfordern tiefgehendes technisches Verständnis der OAuth 2.1 und OIDC-Spezifikationen.
Fehlkonfigurationen in diesen Bereichen können zu ernsthaften Sicherheitslücken führen, wie etwa die Akzeptanz unsicherer Token, fehlerhafte Benutzer-Mappings oder die Umgehung wichtiger Sicherheitsmechanismen.
Aus diesem Grund werden diese Parameter ausschließlich durch erfahrene Nordantech-Techniker konfiguriert, die mit den Sicherheitsanforderungen und verschiedenen IdP-Implementierungen vertraut sind.
Unterstützte Algorithmen
Definiert, welche Signaturalgorithmen für JWT-Tokens akzeptiert werden.
Standard: Wird automatisch aus der OIDC-Discovery-Konfiguration übernommen
Fallback-Werte: HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512
Algorithmus-Typen:
HMAC (symmetrisch): HS256, HS384, HS512 – Verwenden einen gemeinsamen geheimen Schlüssel
RSA (asymmetrisch): RS256, RS384, RS512 – Empfohlen für Produktivumgebungen
ECDSA (modern): ES256, ES384, ES512 – Beste Performance und Sicherheit
Wann anpassen: Wenn ein Legacy-IdP nicht-standardkonforme Algorithmen verwendet oder die Discovery unvollständige Informationen liefert.
Best Practice: RS256 oder ES256 verwenden. HMAC-Algorithmen sollten vermieden werden, da sie einen gemeinsamen Schlüssel erfordern.
PKCE
Aktiviert PKCE (Proof Key for Code Exchange) für erhöhte Sicherheit.
Standard: Aktiviert mit S256-Challenge (SHA-256)
Zweck: PKCE schützt vor Authorization Code Interception Attacks. Ein dynamisch generierter Code Verifier wird verwendet, um sicherzustellen, dass der Token-Request von derselben Anwendung stammt, die den Authorization Code angefordert hat.
OAuth 2.1 Anforderung: PKCE ist eine Pflichtanforderung in OAuth 2.1 und sollte immer aktiviert bleiben.
Wann deaktivieren: Nur in Ausnahmefällen bei älteren Legacy-Providern, die PKCE nicht unterstützen. Dies stellt jedoch ein Sicherheitsrisiko dar.
Unterstützte Scopes
Legt fest, welche OAuth-Scopes der Provider unterstützt.
Standard: Wird automatisch aus der OIDC-Discovery-Konfiguration übernommen
Fallback-Werte: openid, email, profile
Scope-Bedeutung:
openid: Pflicht-Scope für OIDC, signalisiert dem IdP eine OpenID Connect Anfrageemail: Zugriff auf die E-Mail-Adresse des Benutzersprofile: Zugriff auf Profilinformationen wie Name, Bild, etc.
Wann anpassen: Bei IDPs mit eingeschränkten oder abweichenden Scope-Definitionen, oder wenn zusätzliche Provider-spezifische Scopes benötigt werden.
Scope-Trennzeichen
Definiert das Trennzeichen zwischen mehreren Scopes in der Authentifizierungsanfrage.
Standard: Leerzeichen ()
OIDC-Standard: Der offizielle OIDC-Standard verwendet Leerzeichen als Trennzeichen.
Alternative Trennzeichen:
Komma (
,) – Wird von manchen älteren oder proprietären Providern verwendetPlus (
+) – In einigen Legacy OAuth-Implementierungen
Beispiel: Standard wäre openid email profile, während manche Legacy-Systeme openid,email,profile erwarten.
Wann anpassen: Nur bei Legacy-IDPs, die von der Spezifikation abweichen und ein anderes Trennzeichen erfordern.
Identitäts-Attribute
Mappt die Attribute aus dem IDP-Token zu den Falcon-Benutzerfeldern.
Standard-Mapping:
IdP-Attribut | Falcon-Feld | Beschreibung |
|
| Die eindeutige, unveränderliche Benutzer-ID vom Identity Provider. Dies ist der wichtigste Identifier und muss über die gesamte Lebensdauer des Benutzerkontos konstant bleiben. |
|
| Der vollständige Name des Benutzers, typischerweise als "Vorname Nachname". |
|
| Der Vorname des Benutzers. |
|
| Der Nachname oder Familienname des Benutzers. |
|
| Die E-Mail-Adresse des Benutzers. Wird häufig als sekundärer Identifier verwendet. |
|
| Die Position oder der Jobtitel des Benutzers in der Organisation. |
|
| Die Abteilung, in der der Benutzer arbeitet. |
|
| Die Firma oder Organisation, der der Benutzer angehört. |
Wann anpassen:
Der IdP verwendet andere Attributnamen (z.B.
surnamestattfamily_name,jobTitlestattposition)Custom Claims für unternehmensspezifische Felder
Mehrsprachige Attribute, die gemappt werden müssen
Verschachtelte Attribute im Token, die extrahiert werden müssen
Audience
Legt fest, welche Token-Audience als gültig akzeptiert wird.
Standard: Entspricht der client_id
Format: String oder Array von Strings
Zweck: Die Audience (aud-Claim im JWT) gibt an, für welche Anwendung das Token ausgestellt wurde. Dies stellt sicher, dass das Token tatsächlich für Falcon bestimmt ist und nicht für eine andere Anwendung missbraucht werden kann.
Sicherheit: Verhindert, dass Tokens, die für andere Anwendungen ausgestellt wurden, für den Zugriff auf Falcon verwendet werden.
Wann anpassen: Wenn der IdP eine abweichende Audience im Token setzt, z.B. eine API-Identifier-URL oder eine Resource-Server-URL statt der Client-ID.
Audience Strict
Steuert, ob nur eine einzelne Audience oder mehrere Audiences im Token erlaubt sind.
Standard: Aktiviert (nur eine Audience erlaubt)
Modus Strikt (true):
Das Token muss exakt eine Audience enthalten
Diese Audience muss mit dem konfigurierten
audience-Wert übereinstimmenHöhere Sicherheit, da der Verwendungszweck eindeutig ist
Empfohlen für Single-Tenant-Anwendungen mit dediziertem Token-Zweck
Modus Flexibel (false):
Das Token kann mehrere Audiences enthalten
Falcon akzeptiert das Token, solange die konfigurierte Audience in der Liste enthalten ist
Notwendig bei Multi-Resource-Scenarios
Empfohlen für Multi-API-Umgebungen, bei denen Tokens für mehrere Services ausgestellt werden
Wann deaktivieren: Wenn Tokens für mehrere APIs oder Services gleichzeitig ausgestellt werden und mehrere Zielgruppen enthalten müssen.
Erforderliche Claims
Definiert, welche JWT-Claims im Token vorhanden sein müssen, damit es als gültig akzeptiert wird.
Standard-Claims: iss, sub, aud, exp, iat
Claim-Bedeutungen:
iss(Issuer) – Der Aussteller des Tokens, muss mit dem konfiguriertenissuerübereinstimmensub(Subject) – Die eindeutige Identifikation des Benutzers, unveränderlich und essentiell für die Zuordnungaud(Audience) – Die Zielgruppe des Tokens, definiert für welche Anwendung das Token gültig istexp(Expiration) – Der Ablaufzeitpunkt des Tokens als Unix-Timestamp. Nach diesem Zeitpunkt ist das Token nicht mehr gültigiat(Issued At) – Der Ausstellungszeitpunkt des Tokens als Unix-Timestamp
Wann anpassen:
Verschärfung: Zusätzliche Claims als erforderlich definieren (z.B.
email,nonce,auth_time)Lockerung: Bei Legacy-IDPs, die nicht alle Standard-Claims liefern können
Compliance: Spezielle Claims für regulatorische Anforderungen
Hinweis: Die Standard-Claims entsprechen den OIDC-Mindestanforderungen und sollten nur in begründeten Fällen angepasst werden.
Leeway
Zeitlicher Spielraum in Sekunden für die Validierung von Token-Zeitstempeln.
Standard: 10 Sekunden
Format: Ganzzahl (Sekunden)
Zweck: Kompensiert Zeitunterschiede (Clock Skew) zwischen dem IdP-Server und dem Falcon-Server. Ohne Leeway könnten gültige Tokens abgelehnt werden, wenn die Serveruhren nicht perfekt synchronisiert sind.
Anwendung: Wird bei der Validierung von exp (Expiration), iat (Issued At) und nbf (Not Before) Claims angewendet.
Wann erhöhen:
Bei global verteilten Systemen mit größeren Zeitabweichungen
Wenn "Token expired" Fehler auftreten, obwohl das Token eigentlich gültig sein sollte
Bei IdPs mit bekannten Zeitsynchronisationsproblemen
Typische Werte: 10-60 Sekunden. Werte über 120 Sekunden können ein Sicherheitsrisiko darstellen.
Parameter
Zusätzliche optionale Parameter, die bei Authentifizierungsanfragen mitgesendet werden müssen.
Format: Key-Value-Paare als JSON-Object
Zweck: Manche Identity Provider benötigen spezielle, proprietäre Parameter für ihre OAuth/OIDC-Implementierung. Diese werden als Query-Parameter an die Authorization- und Token-Endpunkte angehängt.
Typische Anwendungsfälle:
resource– Microsoft-spezifisch: Angabe der Ziel-APItenant– Mandantenzuordnung in Multi-Tenant-Umgebungendomain_hint– Vorauswahl der Anmeldedomäneacr_values– Anforderung spezifischer Sicherheitsstufen (Authentication Context Class Reference)
Wann verwenden: Bei IdP-spezifischen Anforderungen, die nicht im OIDC-Standard abgedeckt sind.
Prompt (erweiterte Optionen)
Erweiterte Prompt-Optionen über die Standard-Kundeneinstellung hinaus.
Standard: select_account (bei Kundeneinstellung true)
Alle OIDC-konformen Optionen:
none– Keine Benutzerinteraktion. Der Login schlägt fehl, wenn eine Interaktion erforderlich wäre. Wird für Silent Authentication verwendet.login– Der Benutzer muss sich erneut anmelden, auch wenn bereits eine aktive Session besteht. Erzwingt eine Re-Authentifizierung.consent– Der Benutzer muss die angeforderten Berechtigungen erneut explizit bestätigen, selbst wenn bereits zugestimmt wurde.select_account– Zeigt die Kontoauswahl-Seite an, auch wenn nur ein Konto verfügbar ist. Der Standard für die Kundeneinstellungtrue.
Kombinationen möglich: Mehrere Werte können kombiniert werden (z.B. login consent erzwingt sowohl Re-Authentifizierung als auch neue Zustimmung).
Wann anpassen:
Spezielle Compliance-Anforderungen (z.B. Pflicht zur regelmäßigen Re-Authentifizierung)
Hochsensitive Anwendungen, die explizite Zustimmung erfordern
Silent Authentication Flows für nahtlose Benutzererfahrung
IdP-spezifische Anforderungen, die von den Standard-Optionen abweichen
Wann werden erweiterte Einstellungen benötigt?
Erweiterte Einstellungen sind typischerweise in folgenden Situationen erforderlich:
Legacy Identity Provider ohne vollständige OIDC-Unterstützung – Ältere Systeme, die nicht alle OIDC-Standards implementieren
Proprietäre IDP-Implementierungen mit Abweichungen vom Standard – Custom-Lösungen mit nicht-standardkonformen Implementierungen
Spezielle Compliance-Anforderungen Ihrer Organisation – Regulatorische Vorgaben, die zusätzliche Sicherheitsmaßnahmen erfordern
Fehlerhafte oder unvollständige Discovery-Konfiguration beim IDP – Wenn die automatische Endpunkt-Erkennung nicht funktioniert
Custom Attribute-Mappings für unternehmensspezifische Felder – Spezielle Benutzerattribute, die nicht den Standard-Claims entsprechen
Multi-Mandanten-Umgebungen mit komplexen Anforderungen – Komplexe Organisationsstrukturen mit mehreren Tenants oder Domains
Implementierung
Die Konfiguration erfolgt in Falcon unter Sicherheit und Datenschutz → Authentifizierung → Identitätsprovider verwalten.
Tragen Sie die Pflichtfelder issuer, client_id und client_secret ein und aktivieren Sie discovery für moderne Identity Provider. Konfigurieren Sie provisioning und prompt nach Ihren Anforderungen.
Kontakt und Support
Für die Konfiguration Ihres Identity Providers oder bei Fragen zu den Einstellungen wenden Sie sich bitte an: support@nordantech.com
Bei Legacy-IDPs oder Kompatibilitätsproblemen wird ein Techniker die notwendigen erweiterten Einstellungen für Sie vornehmen. Für die Standardkonfiguration mit OIDC-konformen IDPs unterstützen wir Sie gerne beim Setup.