Wie man wirklich (!) eine manuelle Korrekturverfolgung im OIA konfiguriert

Das Produkt Oracle Identity Analytics ist eine wirklich umfangreiche Anwendung zur Analyse von Rollen und Berechtigungen. Im Zusammenspiel mit dem Oracle Identity Manager (OIM) gelingt es zudem, sogar automatisiert Konsequenzen aus der Analyse zu ziehen: Sobald ein Manager bspw. einem Konto Berechtigungen entzogen oder eine Rollenzugehörigkeit aufgehoben hat, kann der OIA diese Information an den OIM weitergeben, der dann wiederum die Umsetzung erforderlicher Maßnahmen in der Infrastruktur auslöst (Deprovisioning). Gleichzeitig fungiert er auch als Provisioning Server und kann somit den OIA mit entsprechenden Daten beliefern, auf Grundlage derer die Manager den Status der Benutzer und deren Berechtigungen analysieren und letztendlich zertifizieren können. Diesen Prozess nennt Oracle Closed Loop Remediation und das dazugehörige Modul im OIA, welches diesen Prozess visualisiert, nennt sich Remediation Tracking, oder auf deutsch: Korrekturverfolgung.

Was aber, wenn es keinen OIM gibt? Dann spricht man von einer Open Loop Remediation, oder alternativ von einer erforderlichen manuellen Korrektur. Dieser Artikel beschreibt, was für Schritte erforderlich sind, damit der OIA in etwa das tut, was man von ihm erwarten würde.

Ausgangslage

  • Es wurden Resourcen-Typen angelegt und konfiguriert (in diesem Beispiel: Ein Ressourcen-Typ mit dem Namen Betriebssystem, dem Kurznamen OPS und einem Multivalue-Attribut groups in der Attributkategorie General)
  • Es existieren Global User (wird weiter unten erläutert)
  • Es wurden Accounts importiert, den Global Users zugeordnet und auf Ressourcen verteilt (wird weiter unten erläutert)

Auf dieser Grundlage ließen sich nun Zertifizierungen erstellen. Aber bevor es soweit ist, zunächst die Einstellungen für die Wartung von Konten und den OIA Prozess der Korrekturverfolgung.

Grundeinstellungen

Damit bei der Korrekturverfolgung auch erkannt werden kann, ob eine zu entziehende Berechtigung auch entzogen wurde, muss der OIA in der Lage sein, die zuvor importierten Daten zu einem Benutzer verändern zu können. In der IT wurde beispielsweise ein Konto von einem Server gelöscht oder eine Gruppenmitgliedschaft aufgehoben. Diese Information muss nun auch der OIA erhalten. Dazu gibt es zwei Möglichkeiten.

Explicit Revoke

Bei der expliziten Methode werden die Daten einfach erneut importiert. Im Falle eines Accounts wird zusätzlich der Parameter suspended übergeben. Der Wert 0 bedeutet, dass der Account aktiv ist (nicht suspended) und der Wert 1 deaktiviert ihn (suspend). Dazu muss natürlich der Parameter in der entsprechenden Schema-Datei (.rbx) angegeben sein.

Im Falle eines Attributes wie z.B. einer Gruppenzugehörigkeit, geht das natürlich nicht. Denn diese werden allenfalls in Form eines Multivalue-Feldes linear aufgelistet; man kann nicht zu jedem Attribut ein zusätzliches Feld wie z.B. suspended übergeben. Was aber geht: Weglassen. Sprich: Sobald ein Account erneut importiert wird, ohne dass die in Frage kommende Gruppenmitgliedschaft aufgelistet wird, erkennt der OIA sie als entfernt (revoked)

Implicit Revoke

Implizit bedeutet, dass der OIA die Korrektur selbst erkennt. Das geschieht auf Basis des letzten Update-Timestamps. Sobald mehr Tage seit dem letzten Import vergangen sind, als angegeben, kann der OIA den existierenden Datensatz selbst aktualisieren.

Schritt 1

In der Datei …\conf\iam.properties muss dazu die Account Maintenance konfiguriert werden (~Zeile 49):

# Account Maintenance parameters
# options { delete | suspend }
com.vaau.rbacx.maintenance.accounts.maintenanceAction=suspend
com.vaau.rbacx.maintenance.accounts.maxStaleDays=30
com.vaau.rbacx.maintenance.accounts.resources=All

Hier sind zwei Dinge zu beachten. Zum einen führt ein Löschen (delete) dazu, dass der Account in dem Fall tatsächlich gelöscht wird. In der Korrekturverfolgung (auf die ich später noch eingehe) gilt die Maßnahme damit zwar als umgesetzt. Allerdings kann sie den Account dann auch nicht mehr anzeigen und somit kann man auch die Historie nicht mehr einsehen. Die Einstellung suspend wiederum hat den Vorteil, dass man weiterhin Einblick in die Historie hat. Optisch führt das dazu, dass in der Account-Auflistung unterhalb der Global User der jeweilige Account ausgegraut wird.

image

 

Zum anderen ist hier der Wert maxStaleDays zu beachten. I.d.R. wird die Maintenance regelmäßig durchgeführt (z.B. einmal am Tag). Wenn nun die Accountdaten bspw. alle 10 Tage importiert werden und maxStaleDays auf einem niedrigeren Wert steht, dann werden regelmäßig alle Konten im OIA gelöscht, bzw. suspended. Insofern gilt es, den Wert auf die Import-Prozesse abzustimmen.

Schritt 2

Für sowohl die automatische Wartung von Accounts wie auch die Verarbeitung der Korrekturinformationen sind im OIA zwei Jobs zuständig. Diese werden ausgelöst von dazugehörigen Triggern. Beides muss aktiviert und konfiguriert werden.

In der Datei …\WEB-INF\scheduling-context.xml im Property jobDetails (~Zeile 157) sind die Jobs per Default auskommentiert. Sie müssen aktiviert werden:

<ref bean="accountsMaintenanceJob"/>

<ref bean="certificationRemediationJob"/>

In der gleichen Datei im Property triggers (~Zeile 195) sind die dazugehörigen Trigger per Default auskommentiert. Sie müssen ebenfalls aktiviert werden:

<ref bean="accountsMaintenanceTrigger"/>

<ref bean="certificationRemediationTrigger"/>

Schritt 3

Die soeben aktivierten Trigger müssen konfiguriert werden. Dabei dient ein Cron-Ausdruck dazu, anzugeben, wann die Jobs automatisch ausgeführt werden sollen.

In der Datei …\WEB-INF\jobs.xml wird die Bean accountsMaintenanceTrigger (~Zeile 516) konfiguriert:

<bean id="accountsMaintenanceTrigger" class="org.springframework.scheduling.quartz.CronTriggerBean">
 
<property name="jobDetail">
    <ref bean="accountsMaintenanceJob"/>
   </property>
  < property name="cronExpression">          
    < value>0 0 0 ? * SUN-THU</value>
  </property>
</bean>

Die cronExpression kann bspw. mit Hilfe von http://www.cronmaker.com/ erzeugt werden.

In der gleichen Datei wird die Bean remediationCertificationTrigger (~Zeile 938) konfiguriert:

<bean id="certificationRemediationTrigger" class="org.springframework.scheduling.quartz.CronTriggerBean">
  < property name="jobDetail">
    < ref bean="certificationRemediationJob"/>
  </property>
  < property name="cronExpression">
    <value>0 0/2 * * * ?</value>
  </property>
< /bean>

Auch hier ist die cronExpression zu beachten. Für Testzwecke kann es sinnvoll sein, beide Trigger auf z.B. 2 Minuten zu setzen, um schnell Ergebnisse beobachten zu können. Für die In-Produktivnahme sollten die Werte aufeinander abgestimmt sein.

Schritt 4

Sobald die Konfiguration durchgeführt wurde, muss der OIA neu gestartet werden, um die Änderungen zu übernehmen. Im Anschluss gilt es beim Erstellen einer Zertifizierung auf das Thema Korrekturverfolgung zu achten.

Unter Administration > Settings im Tab Identity Certification im Abschnitt Revoke and Remediation:

image

Hier sind gleich zwei Einstellungen bemerkenswert. Erstens hat die Checkbox Display Remediation Instructions keinerlei Auswirkungen. Unsere Annahme war, dass nach Abschluss einer Zertifizierung ein Manager die Instruktionen angezeigt bekommt, die wir später noch konfigurieren werden. Dem ist aber nicht so. Statt dessen sieht man diese ausschließlich an zwei Stellen: Zum einen, wenn man in einer Zertifizierung auf einen Resourcen-Namen klickt und zum anderen in verschiedenen Reports. Aber dazu später mehr.

Wir haben uns mit einem Decompiler den Code angeschaut und in der Tat: Dieses Setting wird nirgends genutzt.

Zweitens ist die Checkbox Perform Closed Loop Remediation (und die dazugehörige Einstellung Certification Completion Date) wichtig. Denn selbst wenn der Certification Remediation Job durch den entsprechenden Trigger, den wir bereits konfiguriert haben, ausgeführt wird: Wenn diese Checkbox nicht gesetzt wird, tut der Job nichts. Und das hat nichts mit der Closed Loop Remediation im Sinne einer Integration in den OIM zu tun. Sondern in jedem Fall mit der Korrekturverfolgung. Auch der “manuellen”.

Schritt 5

Wir sprachen eben von den Remediation Instructions. Diese werden in den Resourcen konfiguriert. Und auch hier gibt es Einiges zu beachten.

Unter Identity Warehouse > Resources klickt man auf eine Resource und wechselt in den Tab Remediation:

image

 

Für eine manuelle Korrektur wird entsprechend der Wert Manual ausgewählt. Zusätzlich gibt es die Möglichkeit, sich zwischen einem Plain Text und einem Rich Text Editor zu entscheiden. Hierzu ein Hinweis: Sollte man versuchen wollen, sich auf die mitgelieferten Reports zu beschränken, dann empfehlen wir den Plain Text Editor und hier lediglich auf z.B. ein internes Handbuch o.ä. zu verweisen, in dem die notwendigen Schritte für die Deprovisionierung beschrieben werden. Denn die Reports übernehmen für jede einzelne erforderliche Korrektur diesen Text und sind leider nicht in der Lage HTML zu erkennen. Sprich: Wenn man den Rich Text Editor nutzt und viel Text eingibt (mit jeder Menge Formatierungen), erscheinen diese inkl. HTML-Tags im Report. In jedem Datensatz. Soviel dazu.

Datenimport

Ausgehend davon, dass z.B. User- und Accountdaten wie folgt mittels CSV-Dateien importiert wurden, kann nun eine Zertifizierung erstellt werden. Doch zunächst die Daten:

Import Global User

Datei: …\import\schema\users.rbx (Schema)

userName,firstName,lastName,primaryEmail

Datei: …\import\in\users_01.csv

"D000001","Timo","Tempel","Timo.Tempel@domain.com"

"A000002","Yasmin","Markmann","Yasmin.Markmann@domain.com"

Import Accounts

Datei: …\import\schema\Betriebssystem_accounts.rbx

# @iam:namespace name="Betriebssystem" shortName="OPS"
userName<CorrelationKey>,name,endpoint,groups,suspended

Datei: …\import\in\Betriebssystem_01_accounts.csv

"D000001","SRV01 > D000001","Windows","SRV01 > D000001 > Users,SRV01 > D000001 > Developers","0"
"A000002","SRV01 > A000002","Windows","SRV01 > A000002 > Administrators,SRV01 > A000002 > Users","0"

Wem die seltsame Nomenklatur aufgefallen ist, sei folgender Hinweis mitgegeben: Für dieses Szenario zwar unerheblich, orientiere ich mich aber dennoch an einem Kundenprojekt, in dem wir es mit der Zertifizierung lokaler Benutzerkonten zu tun haben. Da hier ein Kontoname (z.B. D000001) auf mehreren Servern vorkommen kann und dabei nicht zwangläufig identisch ist (da nicht zentral verwaltet mittels bspw. dem Active Directory), benötigen wir zusammengesetzte Primärschlüssel. Gleiches gilt für z.B. Gruppenmitgliedschaften, die wir als Multivalue-Felder konfiguriert haben. Wie man trotzdem eine halbwegs annehmbare User Experience während der Zertifizierung hinbekommt, erkläre ich evtl. ein andern Mal.

Zertifizierung

Nachdem eine Zertifizierung erstellt wurde, stellt sich diese für den Manager wie folgt dar:

image

 

image

 

Der Manager entzieht nun Timo Tempel den Account auf SRV01 und Yasmin Markmann wird die Mitgliedschaft in der Gruppe Administrators entzogen.

Inder Korrekturverfolgung unter Identity Certification > Remediation Tracking zeigt sich nun, dass der OIA das Delta zwischen SOLL und IST verstanden hat:

image


In den Details zeigt sich z.B., dass Yasmin aus der Gruppe Administrators entfernt werden soll:

image

 

Zu Timo zeigt der OIA an, dass er aus sowohl der Developers als auch der Users Gruppe entfernt werden muss. Soweit alles OK.

Zur Demonstration wird nun eine neue Betriebssystem_01_accounts.csv Datei importiert:

"D000001","SRV01 > D000001","Windows","","1"
"A000002","SRV01 > A000002","Windows","SRV01 > A000002 > Users","0"

Hier zu erkennen: In Timos Datensatz wurden die Gruppen entfernt; außerdem wird sein Account suspended. Yasmin wurde einfach nur aus der Gruppe Administrators entfernt.

Im Remediation Tracking schaut das dann so aus:

image

 

Klickt man nun im Remediation Tracking bei Yasmin bspw. auf den Attributwert Administrators, lässt sich im Akkordeon Certification History auch die Historie anzeigen:

image

 

Auch ohne das Neu-Importieren der Datensätze wie oben beschrieben hätte der OIA die Korrektur erfolgreich erkannt, sobald eine entsprechend maxStaleDays Anzahl an Tagen verstrichen wäre.

Im Prinzip ist es nicht kompliziert, den OIA für eine manuelle Korrekturverfolgung zu konfigurieren. Allerdings verlangt es an einigem Know-How und unglücklicherweise schweigt sich die Dokumentation vom Hersteller zu diesem Thema gänzlich aus. Darüber hinaus gibt es noch einige weitere Themen in diesem Zusammenhang, auf die ich nicht im Detail eingegangen bin. Hoffentlich wurden trotzdem einige wesentliche Punkte etwas klarer!

Falls dennoch Fragen offen sind, stehen wir wie immer gerne zur Verfügung. Dazu freuen wir uns über eine Email über unser Kontaktformular auf http://www.toptechnologies.de.

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS