RRZE – Projekte & Prozesse (P&P)

Das Blog der RRZE Stabsstelle "Projekte & Prozesse"

Content

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)

IDM-Wochen-E-Mail 015

Eine Woche der Kleinaufgaben, Abstimmungen und Gespräche liegt hinter dem IDM Kernteam.

So hat Herr Tröger seine kleinen Erfolge in http://www.blogs.uni-erlangen.de/IDM/stories/760/ zusammen gefasst. Ich erspare es mir sie hier zu wiederholen. Dennoch möchte ich ergänzen, dass Herr Tröger seine pwgen-Implementation verfeinern und dann veröffentlichen wird.

Herr Rygus und ich haben uns diese Woche um die personelle Verstärkung des Teams gekümmert. Für die Thematik Organisationsstruktur konnten wir Frau Meyer-Seidt gewinnen. Das andere Bewerbungsgespräch war leider weniger erfolgreich, da der Bewerber nur als HiWi eingestellt werden kann. Somit bleibt die Stelle als Webprogrammierer weiter vakant. Es wird nun in Kooperation mit Herrn Wiese eine neuerliche Ausschreibung gestartet.

Herr Lippert hat den Feinkonzept-Workshop umfassend vorbereitet, so dass wir in der nächsten Woche durch starten können.

Das bayernweite IDM-Konzept war heute wieder einmal Gegenstand einer Videokonferenz. Die Produktunabhängigen Texteile wurden weitestgehend abgestimmt. Da die Themen DIT-Struktur, Zielarchitektur und Dienstleistungsdefinition viel Diskussionsbedarf in sich bergen, wurde ein persönliches Treffen in Nürnberg am 27.03. vereinbart.

Die Top-Punkte im Risiko-Management sind derzeit:
– Personelle Ausstattung
– Barriefreie Weboberfläche Novell Front-End
– Konsensverfahren
– Abbildung der Organisationsstruktur
– DIT -Struktur
– Ablösung der bisherigen Benutzerverwaltung bis Ende 2007
– Neueinführung Novell IDM
– Anbindung RRZE-Abrechnung

In der nächsten steht vom 12. bis 14.03. der Feinkonzept Workshop auf der Agenda.
Diesen nachzubereiten wird auch den Rest der Woche ausfüllen.

Kleinvieh macht auch Mist

In den letzten beiden Wochen konnten einige kleinere Aufgaben abgeschlossen
werden. So konnte die Nachbereitung der Teststellung, häufig durch wichtigere
Aufgaben unterbrochen, endliche abgehakt werden. Ergebnis ist eine
übersichtliche Zusammenfassung der durchgeführten Diapers-Anbindung und des
eingesetzten ID-Servers von Novell.

Weniger anstrengend, aber genauso zeitaufwendig war die Korrektur des
OID-Eintrags bei der Internet Assigned Numbers Authority (IANA). Seit dieser
Woche sieht der Eintrag von Nummer 693 der sog. “private enterprise numbers”
wie folgt aus:

693
Regionales Rechenzentrum Erlangen
Peter Rygus
verzeichnisdienst@rrze.uni-erlangen.de

Die vom RRZE registrierte OID dient zum Erstellen eines eigenen Schemas für
Verzeichnisdienste.

Als kleinen Programmiereinstand wurde das in C geschriebene pwgen
(http://sourceforge.net/projects/pwgen) in Java implementiert. pwgen dient zur
Generierung von benutzerfreundlichen Passwörtern, welche trotzdem noch einem
gewissen Sicherheitsstandard genuegen.

Desweiteren wurden die Grundsteine für zwei zentrale Dokumente innerhalb des
Projekts gelegt. Eines stellt eine erste Version des aktuellen Attributflusses
zwischen aktuellem Verzeichnisdienst und den daran angeschlossenen Systemen dar
und dient als Ausgangspunkt für die zukünftige Provisionierung. Das zweite
Dokument stellt einen Vergleich der verfügbaren, teilweise standardisierten
Schemas dar. Noch sind nicht alle Schemas eingepflegt, doch der Arbeitstitel
läßt erahnen was darin stectk: “Schlacht um Mittelschema”

4. Shibboleth-Workshop des DFN-AAI am 28.02.2007 in Berlin

Am 28.02.2007 lud das DFN im Anschluss an die DFN Betriebstagung zu einem Workshop zum Thema DFN-AAI ein. Gefolgt waren der Einladung ca. 100 Interessierte. Das RRZE wurde durch F. Hänel und P. Rygus sowie anfangs durch G. Dobler und F. Prester vertreten.

Nach der Begrüßung durch Herrn U. Kähler vom DFN Verein und einleitenden Worten von Herrn Ato Ruppert von der UB Freiburg via live-webcam-Schaltung gab Herr Franck Borel (UB Freiburg) eine techische Übersicht über die grundsätzliche Funktionsweise und den Aufbau des Shibboleth SSO Systems. Er wies nochmals darauf hin, dass personenbezogene Attribute nur mit Zustimmung des Kunden weitergegeben werden dürfen. In diesem Zusammenhang wurden auch die Tools ShARPE (https://wiki.aai.dfn.de/wiki/index.php/ShARPE) und Autograph (http://federation.org.au/twiki/bin/view/Federation/AutographView) erwähnt.

Er wies auch darauf hin, dass es noch keine Werkzeuge für die Verwaltung der Metadaten gibt. Man muss sich also umsehen, ob jemand etwas gebastelt hat, was sich abzukupfern lohnt.

Im Anschluss gab Herr U. Kähler vom DFN eine Übersicht über Organisation, Richtlinien, Attribute, Zertifikate und Zeitplan der DFN-Förderation. Die Dienste des DFN werden folgendes beinhalten:

– Betrieb der Technik (WAYF, Testumgebung, etc.)
– Vertragswesen (KEINE Lizenzverträge, nur Föderationsverträge) -> Diensthandbuch
– Ausbildung und Beratung
– Verteilung der Metadaten an Mitglieder der Föderation

Voraussetzung für die Mitgliedschaft in der DFN-Föderation:

– IDM mit SSO-Schnittstelle
– Einhalten der Qualitätsanforderungen bzgl. Aktualität, Verlässlichkeit, Verfügbarkeit
– Die benötigten Attribute müssen vorhanden sein.
– Zertifikate vom DFN-PKI o.ä. f. WAYF, Pers. Auth., …

Der nächste Vortrag von Herrn R. Borenius vom DFN erläuterte den Stand der Arbeiten an der Technik des DFN-AAI und den angestrebten Endzustand.

Herr Bernd Oberknapp vom AAR-Team erläuterte nach einer kurzen Kaffepause, wie man Anwendungen mit Shibboleth schützen kann.

Herr W. Hommel vom LRZ München berichtet im Anschluß vom VHB-AAI-Projekt über eLearning + Shibboleth in Bayern und welche Erweiterungen die DFN-AAI-Lösung noch erhalten müsste, um die Anforderungen der VHB zu erfüllen. In diesem Rahmen wurde auf eine Diplomarbeit verwiesen, die einen XACML 2.0-Standard vorschlägt.

Danach erläuterte Herr P. Gietz vom DAASI recht länglich über das voher veröffentlichte DFN-AAI-Schema. Siehe https://wiki.aai.dfn.de/wiki/images/9/98/DFN-AAI-Attribute-V08.doc

Zu guter letzt wurde von Herrn Oberknapp vom AAR-Team ein Ausblick auf Features der ausstehenden Shibboleth Version 2.0 gegeben, auf deren Erscheinen man aufgrund von Verzögerungen der Entwicklung nicht warten sollte. Als zu erwartende Neuerungen wurden u.a. SingleLogOut, ein nicht triviales Problem, sowie andere Methoden des Attributtransfers genannt.

Die Folien der Vorträge werden noch zur Verfügung gestellt werden.

Der anschließend angebotene Frage- und Diskussionsteil wurde wenig genutzt. Einige Teilnehmer verliessen die Veranstaltung aufgrund von ungünstigen Verkehrsverbindungen früher, und zum Abendessen waren die meisten schon auf der Heimreise.

Zum Glück waren die kompetenten AAR-Team Mitglieder und Ingo Müller von der Virtuellen Hochschule Bayern noch bis spät abends zum fachlichen Austausch verfügbar. Sowohl die VHB als auch das AAR-Team zeigt Interesse an einer Zusammenarbeit mit dem RRZE. Das wird sicherlich in Zukunft noch vertieft. So wurde z.B. vereinbart, bei der Anbindung von weiteren Applikationen Erfahrungen auszutauschen.

Herr Oberknapp wird von den entsprechenden Stellen eine Auskunft über die Verträglichkeit der Redirects beim Shibboleth-Procedere mit den Bestimmungen zur Barrierefreiheit von Webseiten einholen. Allgemein fiel mir auf, dass die Problematik der Barrierefreiheit bei keinem der anwesenden Fachleute im Fokus zu sein schien.

Treffen des VHB-AAI-Arbeitskreises am 09.02.2007 am LRZ in München

Am 09.02.2007 trafen sich die Mitglieder des Arbeitskreises, der die technische Zukunft der VHB abstecken sollte, am LRZ in München. Das RRZE wurde von P. Rygus vertreten.

Zunächst gab Herr Ingo Müller von der VHB eine einleitende Übersicht, um die Randbedingungen zu erläutern. Bemerkenswert erschien mir die große Zahl an Anbietern (333 Kurse von 36 Hochschulen pro Jahr) und Konsumenten (44500 Belegungen von 15000 Studenten pro Jahr).

Probleme entstehen durch proprietäre, teilweise noch papiergestütze Verfahren. Die Übermittlung der Leistungsnachweise und deren mangelnde Anerkennung durch die Hochschulen ist verbesserungswürdig.

Im Anschluß gab Herr Wolfgang Hommel vom LRZ eine kurze Einführung in die Software Shibboleth, mit der die VHB künftig die Authentifizierung und evtl. auch die Autorisierung realisieren möchte. Dabei wurde auch schnell klar, dass die vom AAI vorgesehenen Attribute (eduPerson) für die Zwecke der VHB nicht ausreichen werden.

Herr Franck Borell vom AAR-Projekt (UB Freiburg) gab danach einen Erfahrungsbericht über den bisherigen Verlauf des Projekts. Es zeigte sich , dass die Ziele nicht zu hoch gesteckt waren und man genug Zeit für den Support anderer hatte. Die Laufzeit wurde bis Mitte 2008 verlängert. Spätestens dann sollte alles zum DFN-AAI migriert sein, und sowohl der Betrieb, als auch die Beratung von dort aus geleistet werden. Ab Juni 2007 beginnt die Pilotphase des DFN-AAI mit einigen ausgewählten Einrichtungen.

Für uns könnte auch interessant sein, die in Freiburg realisierte Nagios- oder die SOAP-Anbindung abzukupfern.

Nach diesen Übersichtsvorträgen begann eine rege Diskussion, welche Ziele der Arbeitskreis wann in Angriff nehmen sollte. Es kristallisierten sich drei Zielrichtungen heraus.
1. Die Authentifizierung via Shibboleth und deren technische Umsetzung.
2. Die Übermittlung von Leistungsnachweisen bzw. die Anerkennung der erbrachten Leistungen durch die Hochschulen.
3. Die Benutzung von Resourcen von Trägerhochschulen

Man hat sich darauf geeinigt, zunächst den ersten Punkt anzugehen. Da das eh ein Thema des AK Meta-Dir ist, wird das nächste Treffen auch gemeinsam statt finden (09.05.2007 am RRZE). Die VHB und das RRZE haben eine Zusammenarbeit vereinbart, die die FH Coburg gerne nutzen würde. Dort gibt es kaum Personalresourcen, um eine eigene Shibboleth-Lösung aufzubauen. Das RRZE wird dabei helfen.

Der Zweite Punkt wird angegangen, wenn der erste gut vorangeschritten ist. Der dritte Punkt, so die Meinung der Mehrheit, ‘ergibt sich von alleine’. Schau mer mal.

IDM-Wochen-E-Mail 014

Es ist wieder mal Freitag und damit Zeit für einen Wochenbericht. Da wir uns diese Woche f2f gesehen haben, fasse ich mich hoffentlich kurz.

Nachdem das Fachkonzept endlich fertiggestellt wurde und die Lenkungsausschussitzung statt fand. Haben wir sofort Kurs auf das Feinkonzept genommen.

Herr Tröger hat dafür die Arbeit an der Liste der benötigten Attribute (Arbeitstitel: “Kampfstern Attributica”), dem Schema-Vergleich (Arbeitstitel: “Schlacht um Mittelschema”) sowie dem Konzept zur Anbindung des E-Mail-Systems fortgesetzt und verstärkt.

Herr Dr. Rygus und err Hänel waren auf dem DFN AAI Workshop in Berlin. Ihr Reisebericht folgt im Blog.

Das Thema Kartensysteme wird wohl nicht weiter zu verfolgen sein. Die technischen Lösungsanbieter der Universität und des Studentenwerks sind nicht kooperationsbereit und Herr Meyer vom Studentenwerk sieht derzeit in dieser Thematik auch keine Veränderung. Sollte die Universität über ein IDM-System verfügen und bereit sein, wie die FH Ingolstadt Geld für einen neuen Studierendenausweis zur Verfügung zustellen, ist er jedoch gesprächsbereit.

Anmerkung am Rande: Das Essen in der Südmensa soll sich bis Sommer bessern. Auch hier sind allerdings Investitionen notwendig.

Das bayernweite IDM-Konzept wurde heute in einer Videokonferenz diskutiert. Dabei zeigt sich, dass nur in Erlangen der Weg einer klaren Dienstleistungsdefinition und eines differenzierten Dienstleistungsportfolios gegangen wird. Da die anderen Rechenzentren dies nicht tun, unterscheiden sich die Anforderungen an das IDM massiv. Es wird sich zeigen, wohin das Konzept sich entwickelt.

Die Top-Punkte im Risiko-Management sind derzeit:
– Personelle Ausstattung
– Barriefreie Weboberfläche Novell Front-End
– Konsensverfahren
– Abbildung der Organisationsstruktur
– DIT -Struktur
– Ablösung der bisherigen Benutzerverwaltung bis Ende 2007
– Neueinführung Novell IDM
– Anbindung RRZE-Abrechnung

In der nächsten Woche gilt es den Feinkonzept Workshop 12. – 14.03. vorzubereiten.
Am Mittwoch und Donnerstag gibt es drei Bewerbungsgespräche, u.a. hoffen wir auf einen Webprogrammierer.
Außerdem findet am Freitag wieder die Videokonferenz Novell.IDM@Bayern statt, die als einzigen Tagesordnungspunkt das gemeinsame Konzept hat.

Protokoll Lenkungsausschusssitzung 02

Am 27.02.2007 fand die zweite Sitzung des IDMone Lenkungsausschusses statt. Hier nun der Bericht:

0. Aktuell
Unter dem Titel Mit IDMone fit für morgen” berichtet die aktuelle Ausgabe des uni kurier aktuell http://www.uni-erlangen.de/infocenter/presse/publikationen/unikurier_aktuell/uka_pdf/UKA_65.pdf auf Seite zwei über das Identity Management Projekt.

1.Status Projekt:
Das Projekt hat sich über die folgenden Meilensteine seit der letzten Sitzung am 12.12.2006 entwickelt.

Die Teststellung vom 15. – 25.01. hat nicht die Erwartungen der Teilnehmer erfüllt. Sie war zu ambitioniert und zu umfangreich angelegt. Allerdings hat sie in einigen technischen Punkten wesentliche Klarheit geschaffen.

Das zusätzlich aufgekommene Thema “Abbildung der Organisationsstruktur” wurde in einem Workshop am 22.01.2007 erstmalig mit einem breiten Kreis von Betroffenen thematisiert. Fest steht, dass es sich hierbei um keine Kernaufgabe von IDMone handelt. Es wurde mit den Ateuren ein gemeinsames Positionspapier entworfen und dem Kanzler übergeben. Die Umsetzung und personelle Ausstattung sind jedoch nach wie vor unklar.

Das Advanced Technical Training für den Novell Identity Manager 3 vom 13. – 15.02. wurde von den Beteiligten als sehr lehrreich gewertet. Im Hinblick auf technische Fragen, hat es Klarheit geschaffen. Allerdings wurden auch bestehende Hürden noch stärker sichtbar als zuvor. Zu nennen sind hier zum Einen die Berücksichtigung von Rollen und zum anderen der Themenkomplex “IDM Service-Portal”.

Insgesamt wurde die Zeit zwischen den zwei Lenkungsausschussitzungen intensiv für die interne Abstimmung der Know-How-Stände sowie die Fertigstellung des Fachkonzepts verwendet.

Zum Fachkonzept ist anzumerken, dass das Ziel das Altsystem abzulösen eine erhebliche Umfangserweiterung mit sich bringt. Herr Eggers hat dies Ziel bereits von August auf Dezember 2007 prolongiert. Der in Kapitel 4.7 des Fachkonzepts beschriebene Arbeitsumfang übersteigt die im Projekt derzeit vorhandenen personellen Ressourcen.
Am besten veranschaulicht dies ein Vergleich von Herrn Tröger, der das Bild des Mikadospiels benutzt. Die Schrittweise Migration ähnelt dem Ziehen von Stäbchen. Auf Grund des hohen Integrationsgrades der existierenden Lösung muss man jeweils schauen was wackelt. Eine genaue Abschätzung lässt sich wegen der fehlenden Prozess-Dokumentation nicht treffen. Auch kann die Migration nicht beschleunigt werden, da nur Gert Büttner und Dr. Peter Rygus hierzu in der Lage sind.
Um die Projektdokumentation zu fördern wir Novell Vorlagen für die Dokumentation der Konnektoren liefern.
Insgesamt liegt also ein Zielkonflikt zwischen der zeitnahen Ablösung des Altsystems und der einschränkungsfreien Migration vor.
Nach intensiver Diskussion sind die Lenkungsausschussmitglieder zu dem Schluss gekommen, dass eine Entscheidung hierzu erst getroffen werden kann, wenn die Arbeitspakete im Umfang und zeitlicher Reihenfolge definiert und der Projektplan aktualisiert wurde. Dies zu leisten wird Aufgabe des Feinkonzept-Monats März sein.
Es wurden noch kleinere Änderungen am Fachkonzept vorgenommen, das dann in der vorgelegten Form akzeptiert wurde.
Das Fachkonzept wird nach der Lenkungsausschussitzung unter http://www.rrze.uni-erlangen.de/forschung/laufende-projekte/20070228_IDMone_Fachkonzept_1.0.pdf online zur Verfügung gestellt.

2. Risiko Management – Review der Top Risiken / offene Punkte
Nach der
intensiven Diskussion zum ersten Tagesordnungspunkt stellt Herr Eggers kurz die aktuellen Projektrisiken vor.
a) Kategorie Blocker:
– Personelle Ausstattung (Zielkonflikt Ablösung vs. Umfang)
– Barriefreie Weboberfläche Novell Front-End
– Konsensverfahren
– Abbildung der Organisationsstruktur
– DIT-Struktur
b) Kategorie Critical:
– Ablösung der bisherigen Benutzerverwaltung bis 2007
– Neueinführung Novell IDM
– Anbindung RRZE-Abrechnung

Zum Punkt “Barriefreie Weboberfläche Novell Front-End” ist anzumerken, dass Novell einen aus Ihrer Sicht kompetenten Berater benannt hat, der am Feinkonzept mitarbeiten soll. Auf Grund des wesentlich vergrößerten Funktionsumfanges im Webbereich soll IDMone sofort mit der neusten Version 3.5 des Novell Identity Managers starten.
Wenn fest steht welche Aufwände durch die benötigten Funktionserweiterungen und die Bereitstellung einer barrierefreien Weboberfläche zu erwarten sind, soll bei der nächsten Lenkungsausschussitzung eine Aufgabenverteilung vorgenommen werden.

3.Ausblick bis nächster Termin / Nächster Termin
IDMone bfindet sich derzeit noch im Projektplan allerdings ist – wie oben ausgeführt – eine Planungsüberschreitung absehbar.

Das Projekt wird vom 12. bis 14.03. in einem Feinkonzept-Workshop alle offenen Fragen zusammen tragen, die Arbeitspakete definieren, verteilen und darauf aufbauend einen aktuellen Projektplan erstellen. Danach wird Herr Dr. Rygus versuchen einige offene Punkte auf der Brainshare in Salt Lake City (USA) zu klären.
In einem zweiten Workshop sollen vom 27. bis 29.03. sollen dann evtl. mit den Kollegen aus Würzburg die Detaillierungen zusammengetragen und die Projektplanung finalisiert werden.

Der geplante Entscheidungsworkshop zur IT-Prozessunterstützung wurde nach Rücksprache mit dem Kanzler vertagt, da die Akteure bisher kein entscheidungsförderndes Problembewusstsein entwickelt haben. Es wurde ein neuer Termin Mitte Mai ins Auge gefasst, zu dem ein Blick in das neue IDM-System Fragen aufwerfen und zur Beantwortung drängen soll.
Dieses Entwicklungssystem muss ausdrücklich noch nicht dem CD der FAU entsprechen.
Bis August und damit zum Berichtszeitpunkt an das StMWK wird nur Teilproduktivsystem online sein. Der bisherige Verzeichnisdienst wird parallel laufen müssen.

Der nächster Termin der Lekungsausschussitzung wurde auf den 04.04.2007 von 15 bis 17 Uhr im RRZE festgelegt.

4. Scope-Veränderung
Herr Lippert weist daruafhin, dass bei dem Start des Projekts davon ausgegangen wurde, dass der damals noch nicht eingestellte Projektleiter exklusiv für das Projekt arbeiten würde.
Er sieht derzeit Beeinträchtigungen für IDMone zum Einen im Projektmanagement, da Herr Eggers mit Campus Management, der Arbeit in Arbeitskreisen sowie der Koordination des bayernweiten IDM-Konzepts umfangreiche neue Aufgaben übernommen hat. Dadurch steht Herr Eggers zwangsläufig weniger für inhaltliche Arbeit zur Verfügung, was spürbare Auswirkungen im Projekt zeigt.
Zum Zweiten sieht Herr Lippert durch die im Laufe der Fachkonzeptphase neu hinzugekommenen Projektaufgaben, wie der Anbindung des RRZE-Rechnungswesens und der Abbildung Organisationsstruktur, eine Gefahr für die planungsgemäße Umsetzung des Projekt,

5.Verschiedenes:
Herr Eggers erläutert die Idee eines Sammelbandes IDM. Die Teammitglieder arbeiten derzeit soviele Themen auf, die so oder in ähnlicher Form auch von anderen Projekten geleistet werden müssen. Dies legt die Idee nahe, solche Informationen in einer Form zu dokumentieren, dass diese in einem Sammelband veröffentlicht werden können.
Der Lenkungsausschuss nimmt diese Idee zur Kenntnis allerdings unter der Auflage, dass die Arbeit im Projekt davon nicht beeinträchtigt werden darf.

Nach Ansicht von Herrn Eggers bietet das bayernweite IDM-Konzept für Novell Consulting Deutschland die Chance eine IDM Branchenlösung Universitäten zu entwickeln. Herr Adam ist zwar skeptisch aber durchaus aufgeschlossen und sieht drei alternative
Lösungsansätze:

5.1 Novell Consulting entwickelt generische Produkte stellt diese aber nicht mehr kostenfrei zukünftigen Kunden zur Verfügung, sondern verkauft Consulting Pakete. Dies wird für Novell aus bilanzieller Sicht problematisch.

5.2.
Die Hochschulen mit Consultingverträgen investieren einen gewissen Teil in einen gemeinsamen Pool und lassen Novell Consulting eine generalisierte Lösung entwickeln. Alle investierenden Hochschulen dürfen diese Gemeinschaftsentwicklungen nutzen. Neu hinzukommende Hochschulen müssen Fortentwicklungen finanzieren.

5.3. Es entsteht ein Bundlingprodukt von Hochschulen, dass ein Kernsystem und vorkonfektionierte Treiber samt Dokumentation umfasst und ohne Consulting erworben werden kann. Dies ist mit dem Produktmanagement in Provo zu diskutieren.

Herr Adam hat zugesagt, das Thema aufzugreifen und Novell intern zu kommunizieren.

Nachtrag: Service Provider

Seit etwa zwei Wochen haben wir einen exemplarischen Service Provider laufen, der in der TestFörderation mit unserem Identity Provider kommuniziert und bereits einen einfachen Zugriffsschutz auf Verzeichnisse anbieten kann (zB. für fauXpas o.ä.).
Seit etwa einer Woche schraubt Steffen Büttner an der Einbindung des RRZE News Systems.
Mit Wolfgang Wiese vom Webteam habe ich Kontakt aufgenommen und ihn zur Einbindung des RRZE-Wikis befragt. Er sieht noch grundlegende Probleme, wie etwa zusätzlicher Supportaufwand, Irritation der Benutzer durch Phishing Filter in neueren Browsern, etc. Abgesehen davon möchte er warten, bis das wiki auf leistungsfähigere Server umgezogen ist, die jetzigen scheinen ihm nicht ausreichend zu sein.
Morgen früh gehts nach Berlin, ich bin mal gespannt was der Tag bringt.