RRZE – Projekte & Prozesse (P&P)

Das Blog der RRZE Stabsstelle "Projekte & Prozesse"

Content

UserApp-Schulung

Ziel

Highlight dieser Woche war die dreitägige Schulung zur Anpassung und Erweiterung der Identity Manager User Application (kurz UserApp) durch Herrn Dr. Wolfgang Schreiber von Novell. Ziel dieses Workshops war die Einführung in die Portlet-Entwicklung mit dem JBoss Application Server im Allgemeinen und die Integration eigener Portlets unter Verwendung UserApp-eigener Schnittstellen im Speziellen.

Teilnehmer

Oleg Britvin, Alessandro Dargenio, Hendrik Eggers, Peter Rygus, Patricia Meyer-Seidt, Christoph Singer, Frank Tröger, Krasimir Zhelev

Verlaufsprotkoll

Am Montag startete der Workshop mit einer Einführung in den Portlet-Standard JSR168, den Unterschied zwischen “portlet definitions” und “portlet registrations”, der Bedeutung von Import und Export sowie der Administration von Portlets und Pages. Nach einem kurzen Ausflug in die Anpassung von Themes wurde das grundsätzliche Vorgehen zur Integration eigener Portlets erläutert. Der technische Fokus veranlasste Frau Meyer-Seidt, Herrn Eggers sowie Herrn Dr. Rygus zum vorzeitigen Verlassen des Workshops. Die Bereiche Stylesheets, Localization und “Store and Retrieve” rundeten den ersten Tag ab.

Der Dienstag begann mit der Konfiguration der Arbeitsumgebung der übriggebliebenen Teilnehmer. Danach ging es mit Unterstützung von Herrn Schreiber an die praktische Umsetzung. Beispielhaft wurde eine Passwort-Änderung via LDAP implementiert. Am Mittwoch wurde das Wissen anhand dieser Aufgabe noch weiter vertieft. Es folgten weitere “Lego-Steine”, mit denen IDMone die geplanten Erweiterungen der UserApp umsetzten sollten. Leider gelang dies nur sehr eingeschränkt und falls doch, dann auf dem Fußweg. Das Tempo des Workshops hätte für die verbliebenen Teilnehmer durchaus höher sein können.

Ergebnisprotokoll

Nach Aussage von Wolfgang Schreiber existieren keine für IDMone verwendbaren internen Schnittstellen für den Zugriff auf das der UserApp zugrundliegende eDirectory. “Für IDMone verwendbar” bedeutet dabei, keine offiziellen und/oder dokumentierten Schnittstellen – von Änderungen bei zukünftigen Releases einmal ganz abgesehen. Lediglich folgende Variablen werden durch das UserApp-Portal bereitgestellt:

• Given Name
• Surname
• Email (funktioniert nicht)
• Fdn (LDAP-DN)
• User name
• Canonical fdn (DN in Novell-Schreibweise)
• Fdn (Login – nur mit “enable SSO”)
• fdn pwd (Klartext-Passwort – nur mit “enable SSO”)

D.h. wenn ein eigenentwickeltes Portlet auf ein anderes Attribut der eingeloggten Person zugreifen will, muß es eine eigene LDAP-Verbindung (verschiedene andere APIs stehen zwar zur Verfügung, aber prinzipiell läuft es auf das gleiche hinaus) aufbauen, ggf. mit den Credentials der eingeloggten Person. Dabei ist es aus Portletsicht dann auch egal ob es das der UserApp zugrundeliegende eDirectory ist oder ein beliebiges anderes Verzeichnis. Die im Vorfeld häufig diskutierte Unterscheidung zwischen Meta-Directory und Administrationsbaum kann in Bezug auf die Eigenentwicklung von Portlets nicht aufrecht erhalten werden.

Grundsätzlich kann man sagen, dass IDMone momentan Portlet-Entwicklung im Allgemeinen betreibt. Bis auf kleinere Anpassungen würden alle Beispiele also auch auf einem ganz anderen Application-Server laufen. Entscheidende Punkte konnten nicht geklärt werden. Die erwarteten UserApp-Aha-Erlebnisse blieben aus.

Offene Punkte

• keine verwendbaren APIs
→ Alle Zugriffe eigener Portlets auf das zugrundeliegende eDirectory erfolgen direkt via LDAP.
• kein Zugriff auf das Directory Abstraction Layer (kurz DAL)
→ Dies hat weitreichende Konsequenzen! Alle dort definierten Beziehungen, z.B. Employee-Manager-Beziehung zum Aufbau der Organisationsstruktur, können vom integrierten OrgChart-Modul verwendet werden. Eigene Portlets bleiben außen vor.
• UC1203 Affiliation auswählen
→ Herr Schreiber konnte keine Lösung bieten (fehlende Schnittstellen). Damit ist immernoch nicht geklärt, ob Personen zwischen Ihren verschiedenen Affiliations wechseln können.
• UC1402 Webmaster-Kennung beantragen
→ PDF-Erzeugung wurde nicht behandelt. Selbst der Download von dynamisch generierten Dateien konnte nicht gänzlich geklärt werden.

Notizen Feinkonzeptworkshop Mittwoch, 16.3.

Notizen Feinkonzeptworkshop Mittwoch, 16.3. 9:00 – 12:30, 13:30 – 15:30

Teilnehmer: Hendrik, Peter, Frank, Gert, Patrizia, Norbert, Jürgen, Matthias
Norbert, Jürgen: UseCases, Review UseCase

Agenda

9:00 – 12:00
Abstimmung Vorgehen Barrierefreiheit
Review Use Cases
Welcher Aufwand steckt hinter jedem Arbeitspaket?
Detaillierung
Ergebnisse
Initiale Zeitschätzungen

14:00 – 16:00
Mapping der UseCase auf UserApp und iManager
Review Aufgaben aus dem Workshop
Feedbackrunde

Ergebnisse

Vorschlag Vorgehensweise Barrierefreiheit:

1. Schritte testen der Grundseite: Portalseite, Login, Organigramm, Suche, Anschauen Details, Passwort Management
2. Schritt: Beispielworkflow mit allen möglichen UI-Elementen gegen die Checkliste halten
3. Schritt: iManager: check Helpdesk funktionalität und eDir Administration

Vorschlag Peter: TÜV einbinden und Barrierefreiheit zertifizieren, testen lassen

UseCase Review

Es gibt folgende Akteure: Admins, User, Manager, IDM Service Portal
UseCase Ablauf endet immer, wenn zwischen zwei Schritten Genehmigungen liegen z.B Manager muß Antrag genehmigen.
Zur ergänzende UseCases:
1. “Sonstige Verwalten” muß runtergebrochen werden -> wird am 28.3. im Team gemacht
2. “Manager genehmigt Anträge” runterbrechen -> GB

Nächste Schritte:
Fehlende ergänzen (Manager)
28.3. Use Case Iteration: Inhaltlicher Review jedes UseCases, Vereinheitlichung

Arbeitspakete detaillieren

Wichtig: Loopback Treiber generisch im Meta-Directory Konzept beschreiben (Logik!), Applikationsspezifischen Ausprägung dann für jedes Zielsystem

Mapping der UseCases auf UserApp Funktionalität:

• Datenschutzselbstauskunft: Implementierung über Portlet, Aufwandschätzung. Security Level paßt. Die Funktionsweise dieses Portlets kann auch für andere Funktionen (z.B. Stammdatenänderung) übernommen werden
• Kontosalden anzeigen: soll das initial ins IDM Portal? In Release I nicht -> Use Case auf R2 verschieben
• Kann der Workflow auf ein event im Admindirectory warten -> Damit könnte der Enduser den status seiner Anfrage checken -> NB
• User Kennung aktivieren erfordert ein separates Portlet, welches auch Passwortänderung erzwingt. -> Bedingte Umleitung der Startseite nach Anmeldung -> zusätzliche Attribute (“hat Benutzerbedingungen akzeptiert”). Aufwand schätzen JO
• Man könnte damit leben, dass man für Administrationsaufgaben geschlossen iManager einsetzt (anstatt aufwendig jede notwendige Funktion in die User App zu integrieren). Dann müsste es allerdings konsequent sein. Vorteil wäre: klare Trennung zwischen Admin und Enduser.

Aufgaben aus dem Workshop:

NK: Testen der UserApp und iManager auf Barrierefreiheit mit BITV Checkliste: Annahmen: …..
ML: Klären Buchungsvorlauf für Schulung Webprogrammierung Wolfgang Schreiber
JO: Kann Novell die NDS Anbindung beschreiben und implementieren? Schätzen und Plan liefern.
FT: Aufsetzen der Dokumentenstruktur, Wichtig: Bei der Beschreibung der Konnektoren sollten zuerst die Geschäftsregeln beschrieben werden.
FT: UseCases WikiSeite durchstrukturieren, 16.3.
FT: Nummerierungsschema für UCs überlegen und beschreiben bis 16.3.
ML: Beschreibung der UseCase Attribute aus Wikepedia ins Wiki übernehmen bis 16.3.
ML: zusätzliche Begriffe ins Glossar einbauen, bis 16.3
JO: Schätzung Aufwand für die Erstellung Portlet für Login / Logout in UseApp 16.3.
NB: Kären: Kann der Workflow auf ein event im Admindirectory warten -> Damit könnte der Enduser den Status seiner Anfrage checken
JO: Schätzung Aufwand für die Erstellung Portlet für User – Kennung aktivieren
GB: UseCases “Manager genehmigt…” runterbrechen
NB: Arbeitspaket: IDM Service Portal detaillieren (nach Brainshare).
NB: Sobald IDM 3.5 Gold Master da ist, Hendrik informieren und Link senden

Weitere Planung Norbert, Jürgen:
15.3. 2 Stunden für restliche Use Cases, Norbert startet Barrierefreiheit Testing, Jürgen die Schätzungen
16.3. Fortsetzung Barrierefreiheit
2.4. IDM Service Portal detaillieren: Aufwandschätzung / Vorgehensweise / Termin mit Wolfgang Schreiber machen
Ansonsten 4 Wöchige Onsites für Jürgen mit Telefonterminen dazwischen. -> Planung Matthias
Blocker für Norbert 2 Tage KW17, z.B. 26/27.4.

Notizen Feinkonzeptworkshop Dienstag, 15.3.

Teilnehmer: Hendrik, Peter, Frank, Gert, Patrizia, Norbert, Jürgen, Matthias
Notizen Feinkonzeptworkshop Dienstag, 15.3. 9:30 – 13:00, 14:00 – 18:00

Ergebnisse

Begriffe, die definiert und im Wiki Glossar dokumentiert werden müssen:
Produktionsverzeichnis: Applikationsverzeichnisse.
Containerklasse
Auxiliary Klasse
Effektive / Nicht Effektive Klassen: virtuelle, nicht virtuelle Klassen
Attribut definitionen: Single Value, Synchronize immediately, public read, write managed, per replica, sized
Autoritative Quelle (Objekt, Attribut)
Administrative Quelle (Objekt, Attribut)

Weitere Teile für Feinkonzept:
# Beschreibung der Systemarchitektur
# Beschreibung der Umgebungen -> ist bereits im Wiki
# Testkonzept
# Beschreibung der Vorgehensweise -> nicht relevant für Feinkonzept, eher für Nachhaltige Nachnutzung und andere Projekte
(dieser Teil findet sich direkt in der aktuellen Mindmap und dem Gantchart.)

Wichtig:
Jedes Arbeitspaket enthält auch die Umsetzung im Entwicklungssystem! -> muß in die Beschreibung der Arbeitspakete einfließen, erwartete Ergebnisse.

Offen: Realisierung IDMService Portal mit UserApp, oder Custom? Basierend auf Use Cases (ML in Workshop einbauen)
Für morgen:

Abstimmung, Diskussion: Einsatz Rollenkonzept in IDMone

Diskussionspunkte:
Irgendwo muß stehen, was der Benutzer initial an Ressourcen erhält?
Sind Rollen überhaupt handhabbar?
Problem: das Wegnehmen ist dem Admin egal? Mißbrauchsschutz? Automatisiertes Entfernen? Admin auf die Füße stellen?
Muß es möglich sein, dass ein Subadmin Ressourcen verteilt?
Brauche ich Role Based Access Control -> Novell Behold?

Entscheidungsfindung:
1. Das Hinzu- und Wegnehmen von Ressourcen erfolgt mittels Ablaufdatum, d.h. Standardmäßig besitzt jede Ressourcenzuweisung ein definiertes Ende.
2. Die Zuweisung von Ressourcen kann ich in jedem Fall über Templates gestalten. Ein Template enthält eine def. Menge von Ressourcen mit vordef. Werten.
3. Wenn das Template verändert wird, dann erfolgt die zukünftige Zuweisung mit einer neuen Menge von Ressourcen und Werten.
3a): Alle Zuweisungen, welche durch das Template erstellt wurden bleiben nach der Templateänderung unberührt.
3aa: es existieren keine Informationen über bestehende Zuordnungen, d.h. der Admin kann mit den Informationen im Directory allein die Änderungen nicht umsetzen
3ab): es existieren Informationen über bestehende Zuordnungen, d.h. der Admin kann mit den Informationen im Directory die Änderungen manuell umsetzen.
3b): Das System iteritert über alle Zuweisungen, welche durch das Template erstellt wurden und zieht die Änderung nach.
Konsequenzen aus 2a):

Konsens-Entscheidung: In IDMone werden nur Templates verwendet und das Thema Rollen initial nicht betrachtet. Peter prüft in seinem Meta-Dir Konept die obigen Fälle ab und informiert über die funktionalen Auswirkungen.

Kann ich mit der UserApp auf Informationen zugreifen, die im Meta-Directory und nicht im Administrationsbaum liegen? Hintergrund: das Meta-Directory soll vor direktem Zugriff geschützt werden, daher die Indirektion über den Administrationsbaum. Trotzdem müßte ich von der UserApp auf Daten zugreifen könne, die nur im Meta-Directory liegen (z.B. für Datenschutzselbstauskunft).

Antwort: UserApp kann das von sich aus nicht. Die UserApp kann immer nur von einem Verzeichnis abstrahieren.
Idee: Selbstauskunft als Workflow realieren und dadurch Trennung der Verzeichnisse aufrechterhalten -> Soll Novell mitnehmen

Ausblick auf Themen morgen:

#Detaillierung Arbeitspakete: Abhängihkeiten, Ergebnis, Aufwand initial
#Terminplanung
#Review Use Cases
#Abstimmung Vorgehen Barrierrefreiheit testen
#Zeit 9:00 -15:30

Aufgaben:

NK: Testen der UserApp auf Barrierefreiheit mit BITV Checkliste: Annahmen: …..
ML: Klären Buchungsvorlauf für Schulung Webprogrammierung Wolfgang Schreiber
JO: Kann Novell die NDS Anbindung beschreiben und implementieren?
FT: Aufsetzen der Dokumentenstruktur, Wichtig: Bei der Beschreibung der Konnektoren sollten zuerst die Geschäftsregeln beschrieben werden.
FT: UseCases WikiSeite durchstrukturieren
FT: Nummerierungsschema für UCs überlegen und beschreiben bis 16.3.
ML: Beschreibung der UseCase Attribute aus Wikepedia ins Wiki übernehmen bis 16.3.
HE: zusätzliche Begriffe ins Glossar einbauen, bis 16.3

Notizen Feinkonzeptworkshop Montag

13:00 – 18:00

Agenda:

Einführung (Matthias)
Ziele des Workshop, Ablauf klären, kurze Vorstellungsrunde
Abgleich: aktueller Stand – Was haben wir bis jetzt erreicht?

Vorstellung IDM 3.5. Delta mit Fokus auf UserApp und iManager (Norbert) (ca 60 Minuten Präsentation + 30 Min für Fragen und Diskussion)

Aufstellung von Use Case aus Endbenutzersicht: welche Funktionalitäten muß das System für den Endbenutzer bereitstellen?
Studierende
Administratoren
Dezentrale Administratoren

Ergebnisse:

Ziele des Workshops:
1.Gliederung der Feinkonzeptphase in planbare und kontrollierbare Aufgaben durch Aufstellung des Projektstrukturplans (WBS) und Ermittlung Arbeitspakete -> Basis für die Erstellung eines Projektplans schaffen
2. Vorstellung IDM3.5 und der neuen UserApp -> Aufstellung von Use Cases für das IDM Service Portal
3. Zusammenstellung und Konsolidierung der offenen Fragen

Projekt Status:

Gert: Dokumentation zur aktuellen Benutzerverwaltung liegt im Wiki zum Review vor
Frank: Fortschritte im Bereich Anbindung Mailsystem, Dokumentation der Ist Datenflüsse in der aktuellen BV in Tabellenform
Peter: Analyse zu Shiboleth, Vorbereitung Brainshare

Neues Teammitglied: Patrizia Meier Seith Rolle, Orgstruktur Abbildung, Startet ab 15.5. mit 75% Stelle, wird den Workshop komplett begleiten

Fragen während IDM 3.5 Demo

Engine:
Wie werden Work Orders genutzt? A: man kann Events schon mal einstellen und erst später aktivieren. Z.B. Mitarbeiterfreischaltung vorbereiten.

Könnte Password Generation zur Generierung von Passworten für IDMone (ServicePortal Passwortgenerierungsservice) verwendet werden? A: leider nicht out of the box, da der Job nur im Hintergrund läuft und für die direkte Erstellung der Passwörter in den Zielsystemen gedacht ist (SSO).

UserApp:
Kann man auch komplexere Stylesheets einbringen? A: die Konfiguration funktioniert mit der Adminoberfläche nur für die Bildelemente, für komplexere Eingriffe muss das WAR file bearbeitet werden.
Kann man die Darstellende Schicht abkoppeln? A: nein, UserApp ist kein Framework es gibt aber eine WebServices Schnittstelle
Besteht die Möglichkeit Teams automatisch z.B. aufgrund von eDir Attributen zu erzeugen? A: ja, z.B. Prof. werden als Manager definiert und Teams werden definiert aufgrund des “direct report” Attributs.
Wie sind Digitale Signaturen bei Approvals implementiert? A: zuückgestellt, ev. Peter schaut mal nach Slides

WebServices:
Wie erfolgt die Nutzung der Web Services? A: mit Hilfe der SOAP Schnittstelle kann der volle Funktionsumfang des Provisioningmoduls abgebildet werden. Daher könnte IDMone auch eine komplett eigene Oberfläche bauen. Der Zugriff auf Attribute würde allerdings nur funktionieren, wenn hier ein entsprechender Workflow gebaut würde.
Kann man die Org. Struktur auch um 90Grad drehen: A: ja funktioniert
Kann man die MouseOver (Popups) Texte editieren?: A: ja, wie genau? Norbert kann das zeigen?
Ist die Lokalisation in der Demo schon vollständig implementiert? A: nein, viele Texte sind auch im Deutschen Scheme noch English

Aufgaben:

Nummerierungsschema für UCs überlegen und beschreiben -> FT bis 16.3.
Beschreibung der UseCase Attribute aus Wikepedia ins Wiki übernehmen -> ML bis 16.3.
UseCases Beschreiben bis morgen 9:30. (Verteilung siehe Wiki/Konzepte)
Offen: Realisierung IDMService Portal mit UserApp, oder Custom? Basierend auf Use Cases (ML in Workshop einbauen)

Nachtrag: 03.11. Team-Normung

Am 03.11. hat sich die Gruppe IDM_Core (Gert Büttner, Hendrik Eggers, Dr. Peter Rygus, Frank Tröger) mit den beiden Novell Consultants (Matthias Lippert, Dr. Harald Meyer) zur Team-Normung getroffen.

Unter der Agenda:
– Einführung
– Proektorganisation
– Rollen und Verantwortlichkeiten
– gegenseitige Erwartungen
– Einführung Risikomanagement
– Risikoidentifizierung
– Planung Kick-Off

wurde von 09:30 – 14:30 Uhr intensiv an den Strukturen für eine erfolgreiche Zusammenarbeit gearbeitet.

Die Ergebnisse besonders zum Rollenverständnis sowie der Risikoidentifizierung werden noch gesondert dokumentiert.

Fazit des Tages war, dass es nun in die Kick-Off Woche gehen kann!

 

Addition: 3. Nov. Team Charta

On 3/11 the group IDM_Core (Gert Büttner, Hendrik Eggers, Dr. Peter Rygus, Frank Tröger) met with the two Novell consultants (Matthias Lippert, Dr. Harald Meyer) for a team charta.

Intensive work in the agenda:
– Introduction
– Project organization
– Roles and responsibility
– Reciprocal expectations
– Introduction of a risk management
– Risk identification
– Plan for Kick-Off

has been done from 9:30 am to 2:30 pm for a successful teamwork.

The results, especially for the understanding of roles as well as the risk identification will be documented separately.

Conclusion of the day was, that the Kick-Off week can start now!

Koordinationsgespräch mit Matthias Lippert

Heute fand das initiale Koordinierungsgespräch zwischen dem project coach Matthias Lippert (Novell) und dem Projektleiter Hendrik Eggers (RRZE) statt.

In intensiver Diskussion, die u.a. die telefonische Rücksprache mit Matthias Ruckdäschel erforderten, wurden diverse Änderungen an dem Projektleitdokument (PID – project initiation document) erarbeitet.

Außerdem wurde die Agenda für die morgige (03.11.) Teamnormung zusammen gestellt und versandt.

So langsam geht es los …

 

 

Coordination Meeting with Matthias Lippert

Today the initial coordination meeting between the project coach Matthias Lippert (Novell) and the project leader Hendrik Eggers (RRZE) took place.

In an intensive discussion, which amongst others needed a telephone consultation with Matthias Ruckdäschel, several changes within the project initiation document (PID) were made.

Furthermore the agenda for tomorrows team charta has been put together and sent.

It is starting already…