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.