Wie man OIA Microsoft SQL beibringt

Einmal davon abgesehen, dass Oracle bereits seit einiger Zeit plant, das Produkt Oracle Identity Analytics abzuschaffen, erfreut es sich aber noch immer einer erstaunlichen Beliebtheit. Nicht zuletzt sicher deshalb, weil es flexibel ist und sich in alle nur denkbaren Richtungen konfigurieren, erweitern und sogar anpassen lässt.

Besonders wichtig für ein Identity Management Produkt ist dabei der Weg, wie Daten hineingelangen. I.d.R. stammen diese aus vollkommen unterschiedlichen Systemen und oft werden für den Import-Prozess entweder CSV-Dateien eingesetzt, oder direkt Datenbankverbindungen zu Endsystemen genutzt. Eine weitere Alternative sind sog. Provisioning-Server, die im Gesamtprozess des Identitätsmanagement zwei Aufgaben erfüllen:

More...

Bugfix: Glossar Beschreibung im OIA anzeigen

Mit diesem Artikel folgt ein weiteres Deep Dive in die Welt des OIA (Oracle Identity Analytics). Dieses Mal vor dem Hintergrund eines Bugs, dessen Lösung im Folgenden beschrieben wird.

Im letzten Artikel haben wir gezeigt, wie eine Zertifizierung auf der Grundlage lokaler Konten konfiguriert und durchgeführt werden kann. Da es dabei erforderlich ist, Primärschlüssel zusammenzusetzen, entstehen für die Attribute relativ lange Namen. Das macht die Darstellung für den Zertifizierer unübersichtlich.

Zu sehen war deswegen in dem Artikel, wie beispielsweise die Gruppenmitgliedschaft zwar als Kombination zwischen Server, Account und Gruppe importiert wurde (“SRV01 > A000002 > Users”), die Anzeige sich aber während der Zertifizierung auf die Darstellung der Gruppe beschränkt:

image

 

Klickt nun der Zertifizierer auf die Gruppe, können Glossarinformationen angezeigt werden, die in diesem Beispiel im Feld Description eine Beschreibung des Servers mitführt. Das kann dem Zertifizierer dabei helfen, den Kontext besser zu verstehen. Damit das funktioniert, müssen ressourcenabhängig Glossarinformationen importiert werden.

Import Glossary

Datei: …\import\schema\Betriebssystem_glossary.rbx

# @iam:namespace name="Betriebssystem" shortName="OPS"
attributeName,atributeValueValue,endpointName,definition,shortDescription

Datei: …\import\in\Betriebssystem_01_glossary.csv

"groups","SRV01 > D000001 > Users","Windows","Users","Zentraler Entwicklungsserver"
"groups","SRV01 > D000001 > Developers","Windows","Developers","Zentraler Entwicklungsserver"
"groups","SRV01 > A000002 > Administrators","Windows","Administrators","Zentraler Entwicklungsserver"
"groups","SRV01 > A000002 > Users","Windows","Users","Zentraler Entwicklungsserver"

Das Ergebnis des Imports kann nun im Identity Warehouse im Bereich Data Management der jeweiligen Ressource eingesehen werden:

image

Wenn der Zertifizierer während der Zertifizierung nun wie oben dargestellt auf einen Glossareintrag klickt, erhält er aber folgendes Popup:
image

 

Was fehlt, ist die Description. Und der Grund hierfür ist der oben erwähnte Bug in OIA.

Analyse

Bei der Analyse des Datenstroms zwischen Server und Browser mit Hilfe der Internet Explorer Developer Toolbar hat sich gezeigt, dass die Daten für das Popup über den Service dwrIDCService mit der Methode loadBatchUserAccounts gezogen werden. Der Blick in den Quellcode hat zutage gefördert, dass am Ende die Abfrage getIDCAccountAttributesFlatByUser ursächlich für das Problem verantwortlich ist. Da allerdings im OIA das (inzwischen abgemeldete) Produkt iBATIS zum Einsatz kommt, lässt sich die Abfrage leicht einsehen. Sie befindet sich in der Datei IDCAccount.xml im Verzeichnis …\WEB-INF\classes\com\vaau\rbacx\idc\dao\ibatis\maps.

Zunächst wird in der Abfrage ein Defaultdatensatz erzeugt:

<select id="getIDCAccountAttributesFlatByUser" resultMap="account-attribute-wrapper">
  select
  null as attribute_value_id,
  null as attribute_id,
  null as attribute_value,
  null as glossary_def,
  null as short_description,
  null as attribute_name,
  ,
  

 

Einige Zeilen später findet ein Union statt mit einer Abfrage, die die tatsächlichen Daten aus der Datenbank bezieht. Hier zeigt sich das Problem:

select 
   
  idc_account_attributes.short_description as short_description, 
    
from 
  idc_account_attributes, attributes, idc_user_acct_attrs, idc_accounts, namespaces 
  
  

 

Der Blick in die Datenbank zeigt, dass sich hier schlicht keine Daten befinden. Die Glossarinformationen wurden beim Import nämlich in die Tabelle attribute_value_metadata eingelesen.

Lösung

Die Abfrage muss angepasst werden, so dass die Tabelle attribute_value_metadata mit einbezogen wird. Dabei ist darauf zu achten, über die Where-Klausel die Verknüpfung korrekt zu definieren.

select 
   
  attribute_value_metadata.short_description as short_description, 
   
from 
  idc_account_attributes,attribute_value_metadata, attributes,  
where 
  attributes.attributekey = idc_account_attributes.attribute_id and 
  attribute_value_metadata.attribute_value_id=idc_account_attributes.iam_attr_val_id and 
  attribute_value_metadata.endpoint_id=idc_accounts.endpoint_id and 
  idc_account_attributes.id = idc_user_acct_attrs.account_attribute_id and
   
  

Das war es auch schon.

An dieser Stelle ein leider notwendiger Hinweis: Soweit wir es sagen können, hat diese Änderung keine Auswirkungen auf das restliche Produkt. Da wir den OIA aber nicht entwickelt haben, können wir dafür keine Gewährleistung übernehmen. Sollten Sie daher ebenfalls Änderungen an Ihrem System vornehmen, geschieht das auf eigene Gefahr.

Fazit

Leider zeigt sich beim OIA, dass durch den turbulenten Lebenslauf (entwickelt von vaau, übernommen von Sun, gekauft von Oracle) die eine oder andere Unstimmigkeit entstanden ist. Von außen lässt sich natürlich schwer nachvollziehen, welches Unternehmen nun ursächlich für solche Probleme verantwortlich ist. Das ist aber auch unerheblich. Wichtiger ist, dass man sie lösen kann.

Wir konnten dieses Problem durch den Einsatz verschiedener Analysewerkzeuge inkl. Einsicht in den Quellcode identifizieren und nachhaltig beheben. Da von einem Unternehmen, das den OIA zum Zweck der Zertifizierung von Benutzern, Rollen und Konten einsetzt, natürlich kaum erwartet werden kann, so tief in die Technik einzusteigen wenn etwas nicht funktioniert wie erwartet, gibt es für Kunden i.d.R. nur eine Option: Bei Oracle einen Spezialisten einkaufen.

Oder aber Sie fragen uns. :)

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.

Wie eine Attribute-Level Remediation in OIA funktioniert…

… wissen wir leider auch nicht.

Das heißt: Eigentlich schon. Aber es ist nicht gerade so, dass die Funktion besonders sinnvoll erscheint. Doch was ist damit eigentlich gemeint?

In Oracle Identity Analytics werden Daten vereinfacht gesagt wie folgt strukturiert:

image

 

Es gibt also globale Benutzer (darunter versteht der OIA Identitäten, also reale Menschen) und darunter Accounts. Sprich: Ein Mensch kann über mehrere Accounts (z.B. Anmeldekonten) verfügen. Jedem Account können mehrere Attribute zugewiesen sein, die den Account besser beschreiben. Dabei können Attribute auch verschachtelt werden. Beispielsweise ist es so möglich, folgendes abzubilden:

Global User > Account > Group Membership > Folder Permissions

In diesem Fall kann also ein Mitarbeiter über einen Account verfügen, der Mitglied in verschiedenen Gruppen ist, wobei jede Gruppe über spezifische Verzeichnisberechtigungen in irgendwelchen Netzwerk-Shares verfügt.

Attribute-Level Remediation

Unter Remediation versteht man in der Welt des OIA die Notwendigkeit von Korrekturen, die immer dann anstehen sollten, wenn eine IST-Situation von einem SOLL abweicht. Hat ein Mitarbeiter z.B. das Unternehmen verlassen, sein Account existiert aber nach wie vor im Active Directory, müsste bei einer Identity Certification genau das herauskommen: Der Zertifizierer bekommt den Mitarbeiter vorgelegt und lehnt ihn direkt ab (disclaim). Der OIA erkennt den Unterschied und führt den Benutzer der Korrekturverfolgung zu (Remediation Tracking).

Was aber, wenn nicht der Benutzer (bzw. die Identität oder wie der OIA sagen würde: der Global User), und auch nicht in dem Sinne dessen Account, sondern stattdessen Gruppenmitgliedschaften zertifiziert werden sollen – bzw. korrigiert werden sollen, falls IST und SOLL voneinander abweichen?

Dann ließe sich das – nach offizieller Aussage – mittels der Data Owner Certification abbilden. Neben der Benutzer-, Rollen- und Ressourcenbasierenden Zertifizierung ist das die Nummer vier im Bunde:

image

 

In dieser Art der Zertifizierung ließe sich nämlich auf Ebene der Attribute arbeiten. Dazu werden einfach die gewünschten Attribute ausgewählt:

image

 

Doch nun kommt der Pferdefuß: Wie bei allen anderen Zertifizierungstypen auch muss natürlich noch die Frage beantwortet werden, wer denn nun die Zertifizierung ausführen soll. Bei einer Identitätsbasierenden Zertifizierung kann das z.B. der Manager der jeweiligen Ressource sein, oder aber der Manager der jeweiligen Abteilung.

Bei der Data Owner Zertifizierung kann entweder nur ein einziger Mitarbeiter dazu auserkoren werden, oder aber – hence the name – der jeweilige Data Owner. Ein einziger Mitarbeiter wäre in den meisten aller Fälle unsinnig. Denn der müsste dann ja die entsprechenden Attribute aller Mitarbeiter des Unternehmens zertifizieren. Und in der Annahme, dass nur Großunternehmen ein Produkt wie den OIA einsetzen, gehe ich davon aus, dass einen Mitarbeiter mit dem Thema zu beschäftigen vermutlich gegen das Arbeitsschutzgesetz verstößt (oder wird Folter hier nicht berücksichtigt?).

Data Owner

Wer ist denn nun also der Data Owner?

Die Ressourcenansicht zeigt: Jedes einzelne Attribut an jedem einzelnen Account hat einen eigenen Data Owner:

image

 

Interessanter Fact am Rande: Die Frage danach ob es Sinn ergibt oder nicht mal beiseite gestellt, lassen sich Data Owner über die OIA Oberfläche hinzufügen. Die Sache ist nur die: Man kann sie nicht wieder entfernen (nur ein Hinweis, falls es jemand versuchen sollte).

Da aber auch hier ein gewissen Mengenproblem dem Tatendrang die Motivationsgrundlage entzieht, stellt sich also eher die Frage, ob sich der Data Owner beim Importieren der Accounts setzen lässt. Einen pfiffigen BI-Experten mit Kenntnissen in der Bedienung eines modernen ETL Tools vorausgesetzt wäre das doch die Lösung. Richtig?

Falsch. Denn der Data Owner lässt sich eben nicht automatisiert importieren.

Ende der Geschichte.

Falls jemand dazu andere Informationen vorliegen hat, oder einen Weg kennt, das Problem zu lösen, freue ich mich über einen Kommentar. Anderenfalls greife ich es vielleicht noch einmal auf, sollten wir selbst dazu eine Lösung finden (mir schwebt hier die Implementierung eines benutzerdefinierten Post-AccountImport Jobs vor – ähnlich den MaintenanceJobs und einer konfigurierbaren Zuordnung zwischen Attribute-Values und Data Ownern).

Microsoft goes Linux und ich installiere Oracle Identity Analytics auf einem Windows Server

Zugegeben, die Idee, den OIA auf einem Windows Server zu installieren klingt zunächst einmal hanebüchen. Warum sollte man so etwas tun? Nun, ganz einfach: 1. Weil es sich bei dem OIA um nicht mehr und nicht weniger als eine Web-Anwendung handelt, der es egal sein sollte, auf welchem Betriebssystem sie gehostet wird und 2. Weil es dem OIA tatsächlich egal ist, auf welchem Betriebssystem es gehostet wird.

Außerdem bewege ich mich leichtfüßiger in der Microsoft-Welt im Vergleich zu bspw. Oracle Linux.

Hintergrund ist aber eigentlich das Bedürfnis, völlig frei und unabhängig mit dem OIA experimentieren zu können. Wie lässt sich die Anwendung customizen? Wie können hierarchische Daten importiert werden? Wie funktioniert eine sog. "Open Loop Remediation" und was muss man dazu in der Konfiguration beachten?

Kundenserver haben die Angewohnheit, meist von anderen administriert zu werden. Auf meinem eigenen Hyper-V Windows Server kann ich aber schalten und walten, wie es mir gefällt, Checkpoints erstellen, Daten in den OIA importieren, wieder löschen, Identitäten anlegen, Zertifizierungen nur zum Test durchführen, eigene Java Beans für die Integration OIA-fremder ETL Tools einbauen (und sie wieder ausbauen, weil das vermutlich nicht funktionieren wird), etc. pp.

Und wer denkt, für den Oracle Identity Analytics Server bräuchte es Oracle Experten, um ihn zu installieren, der irrt. Zumindest unter Windows sind die notwendigen Schritte für eine einfache Basis-Installation nicht schwer. Die "Setup-Experience" unterscheidet sich zwar spürbar von der Installation gewohnter Microsoft-Produkte, aber wenn man bestimmte Dinge beachtet, funktioniert alles reibungslos:

  • Installation von Windows Server 2008 R2
  • Installation von Oracle Database 11
  • Einrichten einer Datenbank (rbacx) und Erstellen eines Benutzers (rbacxservice)
  • Vorbereitung der OIA Installation
  • Erstellen des OIA Datenbankschemas
  • Installation des WebLogic Applicationservers
  • Einrichten einer WLS Domain (rbacx)
  • Deployment der OIA Anwendung

Auf dem Weg zur funktionierenden OIA Installation müssen verschiedene Dinge beachtet werden. Einige Konfigurationsdateien beispielsweise verlangen eine Umgebungsvariable, die am sinnvollsten als Systemvariable eingerichtet wird (sonst läuft schon mal gar nichts). Gemeint ist übrigens RBACX_HOME. Das steht aber im Prinzip bereits in der Installationsanleitung. Außerdem wird ein Windows-Administrator bei dem Gedanken schmunzeln, dass so etwas Triviales wie ein Datenbank-Treiber separat heruntergeladen und eingebunden werden muss (ojdbc). Interessant wird es bei Dritt-Abhängigkeiten wie z.B. Jasper-Reports oder CloverETL.

Ersteres ist die OSS Reporting Engine, deren korrekte Version nicht mehr da zu finden ist, wo die Anleitung es behauptet. Selbiges gilt für CloverETL. Die Idee dahinter ist eigentlich pfiffig: Der OIA integriert die Open Source ETL Engine, so dass Transformationen von Quelldaten vor dem eigentlichen Import in den OIA vom OIA selbst automatisiert durchgeführt werden können. Der Haken daran ist lediglich, dass es sich um die so ziemlich älteste Version der Engine handelt, die es gibt: Sie stammt von 2006 und nach zwei Akquisitionen hat es der aktuelle Rechteinhaber Oracle nicht geschafft, das Thema zu aktualisieren (zuvor hieß der OIA noch Sun Role Manager und davor hieß es Vaau RBACx). Unglücklicherweise gibt es die alte Clover GUI nicht mehr, die mit CTL1 in der Lage war, OIA kompatible ETL-Graphen zu erzeugen. Da die in den OIA integrierte CloverETL Engine nicht mit CTL2 kompatibel ist, hilft einem der aktuelle CloverETL Designer auch nicht weiter. Mal abgesehen davon, dass die Anschaffung mit nicht unerheblichen Lizenzkosten verbunden ist.

Es wäre für mich mal interessant zu erfahren, wie andere Unternehmen damit umgehen. Irgendwie müssen die Daten ja vorverarbeitet und qualifiziert werden. Mit Microsoft SSIS? Mit Talend Open Studio? Mit Informatica PowerCenter? Und wie wird das jeweilige Produkt in den OIA Workflow eingebunden?

Mehr dazu vielleicht ein anderes Mal.

Ü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