Denodo: AD/LDAP, SSO, Rollen und Quellidentität sauber trennen

Quellen- und Prüfstand: 24.10.2026 · Denodo Platform 9.5. Tatsächliche Updates, Treiber, Bundle und Deployment mit der passenden Herstellerhilfe abgleichen. Menüs und Funktionen können sich ändern. Redaktionelle Pilotanleitung; kein ausgeführter Kundensystemtest.

Drei Fragen vor jeder Konfiguration

Wer meldet sich an? Der Identitätsanbieter oder das Verzeichnis bestätigt eine Identität. Was darf diese Identität in Denodo? Zugeordnete Rollen und Rechte begrenzen die Nutzung. Mit welcher Identität liest Denodo die Quelle? Das kann ein technisches Konto oder eine unterstützte Durchreichung sein. Diese drei Antworten sind nicht automatisch gleich.

Active Directory kann über passende Verzeichnis- oder SSO-Verfahren eingebunden werden. LDAP-Anmeldung ist nicht dasselbe wie SAML- oder OAuth-basierte Föderation. Die 9.5-Hilfe behandelt unterschiedliche Authentifizierungsverfahren. Zuerst das von eurer konkreten Oberfläche, eurem Client und eurem Deployment unterstützte Verfahren wählen; keinen universellen Assistenten für alle Clients versprechen.

Zuordnung mit IAM ausarbeiten

Die Bezeichnungen sind Projektbeispiele, keine vorausgesetzten Standardrollen. Ein technisches BI-Konto kann Nutzergrenzen zusammenfassen. Dann ist persönliche Regionssteuerung anhand des angemeldeten Denodo-Nutzers nicht ohne weiteres nachgewiesen. Benutzeridentität und Anwendungskontext bewusst modellieren und testen.

Schritt für Schritt

1. Zuerst die tatsächlichen Zieloberflächen bestimmen: Design Studio, Marketplace, SQL-Client und BI-Verbindung. Für jede Oberfläche Anmeldung, Sitzungsdauer und Verantwortlichkeit klären.
2. Mit IAM Verzeichnis-/IdP-Endpunkt, Vertrauenskette, Gruppenquelle und Rollenabbildung dokumentieren. Geschützte Credential-Verweise verwenden; keine Bind-Passwörter, Tokens oder privaten Schlüssel in allgemeine Notizen kopieren.
3. In einer genehmigten Testinstanz das versionsbezogene Verfahren konfigurieren. Herstelleranleitung für LDAP oder das gewählte SSO-Verfahren verwenden. Verbindungsprüfung und Nutzeranmeldung getrennt protokollieren.
4. Zuerst eine minimale Testrolle anlegen beziehungsweise freigeben lassen. Metadatenanzeige, Ausführung und administrative Änderungen als unterschiedliche Tätigkeiten behandeln.
5. Testnutzer mit nur einer vorgesehenen fachlichen Rolle prüfen. Danach absichtlich einen zweiten freigegebenen Rollenfall testen. Nicht davon ausgehen, dass eine einschränkende Rolle jede zusätzliche Berechtigung anderer Rollen neutralisiert.
6. Quellabfrage mit der tatsächlich verwendeten Quellidentität prüfen. Bei Durchreichung Nachweis an Quelle und Denodo erfassen. Eine erfolgreiche Denodo-Anmeldung allein belegt die Durchreichung nicht.
7. Gruppe oder Rolle im genehmigten Testfall entfernen. Neue Sitzung und gegebenenfalls dokumentiertes Rollen-/Gruppen-Caching berücksichtigen. Beobachteten Zeitpunkt des Entzugs, Verbindungsrolle und verbleibende Kopien prüfen.

Abnahme

Erlaubte Konsumsicht funktioniert; nicht freigegebene Quell- oder Detailansicht bleibt unzugänglich; Zusatzrollen sind nachvollzogen; Entzug wirkt im definierten Zeitfenster; Betriebszugang und Notfallverfahren sind getrennt dokumentiert. Ein fehlender Zugriff im Marketplace beweist nicht automatisch denselben Zustand in JDBC oder in einer bestehenden BI-Datei.

Offener Punkt statt Annahme: Wenn IdP, Client oder Durchreichung noch nicht getestet sind, die Unterstützung als Pilotaufgabe erfassen. Nicht anhand einer Marketingliste die konkrete Kombination freigeben.

Die Governance-Entscheidung im Alltag

Ein Wechsel von Vertrieb nach Support ändert die erlaubten Datenwege. Der fachliche Owner bestätigt den neuen Zweck; IAM ändert die Zuordnung, Denodo-Verantwortliche prüfen effektive Rollen und der Quellbetrieb kontrolliert die tatsächliche Quellidentität. Prüfe Marketplace, direkten SQL-Zugriff und die vorhandene BI-Verbindung getrennt. Eine angepasste Gruppe allein schließt den Vorgang nicht.

Hält die BI-Anwendung einen technischen Sammelzugang, muss dessen Sicht bereits den erlaubten Umfang begrenzen. Eine persönliche Regionsentscheidung darf nicht allein im Portal dokumentiert sein, während der SQL-Zugang weiterhin alles liest. Der Abschluss ist der nachgewiesene Rechtezustand einschließlich bestehender Ergebnisdateien.

Herstellerquellen

• Denodo 9.5: neue Funktionen
• Administration
• Globale Sicherheitsregeln
• Cache und Materialisierung
• LDAP-Anmeldung
• Data Marketplace: Umbenennung