Aufgabe A – Multiple Choice (17 Punkte)
(a) Aussagen zu VO, Zertifikaten, Grid, WS, WSRF, etc.
Hinweis: Da hier keine konkreten Aussagen vorgegeben sind, müssen die Studierenden anhand der Konzepte beurteilen, ob Aussagen (z. B. zur Delegation in virtuellen Organisationen, zur Funktionsweise von Grid-Zertifikaten, zur Implementierung von Web Services und WSRF‑Standards) korrekt sind oder nicht.
Lösungshinweis:
- VOs sind dynamische, oft zeitlich und zweckgebunden gegründete multi-institutionale Organisationen, die in der Regel kein eigenes Ressourcenmanagement betreiben (dies übernehmen die lokalen Provider).
- Zertifikate in Grids basieren meist auf X.509-Standards, wobei Proxy‑Zertifikate von Endnutzern (bzw. deren Clients via Delegation) und nicht von VOs ausgestellt werden.
- Grid-Services (WS) und WSRF (Web Services Resource Framework) sind Standardansätze, um Ressourcen als webservice‑basierte Objekte anzubieten.
(Die exakte Bewertung hängt von den konkret vorliegenden Aussagen ab.)
(b) Welchen Hash-Algorithmus verwendet die RA laut angegebenem Zertifikat?
Die zur Auswahl stehenden Optionen sind:
- sha1WithRSAEncryption
- Eine der Algorithmen in den Extensions
- In Zertifikat nicht angegeben
Lösung:
Typischerweise enthalten Grid‑Zertifikate (und damit auch die Zertifikate von Registration Authorities) als Signaturalgorithmus den Wert sha1WithRSAEncryption.
Antwort: sha1WithRSAEncryption
(c) Wechselseitige Authentifizierung
Aufgabe: Erklären Sie anhand eines Sequenzdiagramms, wie die wechselseitige Authentifizierung abläuft.
Musterlösung (Textuelle Beschreibung):
- Verbindungsinitiierung:
– Der Client sendet eine Verbindungsanfrage an den Server. - Server fordert Authentifizierung:
– Der Server antwortet mit einer Aufforderung zur Authentifizierung, oft verbunden mit der Anforderung, das eigene Zertifikat vorzulegen. - Client sendet sein Zertifikat:
– Der Client schickt sein X.509‑Zertifikat (ggf. inklusive Proxy‑Zertifikat). - Server prüft Client-Zertifikat:
– Der Server validiert die Signatur, prüft das Zertifikat (inklusive Vertrauenskette und ggf. VO‑Attribute). - Server sendet sein Zertifikat:
– Im Rahmen der wechselseitigen Authentifizierung sendet der Server ebenfalls sein Zertifikat an den Client. - Client validiert Server-Zertifikat:
– Der Client überprüft das Serverzertifikat analog. - Abschluss:
– Nach erfolgreicher Validierung ist die wechselseitige Authentifizierung abgeschlossen; beide Parteien können nun über einen sicheren Kanal kommunizieren.
Ein entsprechendes Sequenzdiagramm würde diese Austauschfolgen mit Pfeilen (Client → Server: Anfrage, Server → Client: Zertifikat, …) darstellen.
(d) Nennen Sie vier Eigenschaften einer VO
Antwort:
- Gründung auf bestimmte Zeit: VOs werden meist für ein befristetes Projekt oder Zweck gegründet.
- Gründung zu einem bestimmten Zweck: Die Organisationen kommen zusammen, um ein spezielles Ziel zu erreichen (z. B. eine wissenschaftliche Fragestellung).
- Besteht aus dynamischen multi-institutionalen Organisationen: Die VO vereint Partner aus verschiedenen Institutionen, die sich flexibel zusammenschließen.
- Betreibt kein Ressourcen-Management: Das Ressourcenmanagement wird von den lokalen Provider‑Instanzen übernommen.
(e) Richtiges ankreuzen!
(i) Wobei handelt es sich um ein Informationsmodell?
- BDII
- GLUE
- R-GMA
Begründung: Die GLUE‑Schema spezifiziert die Struktur und Attribute von Grid‑Ressourcen und stellt damit ein Informationsmodell dar.
(ii) Womit werden Ressourcen spezifiziert?
- BDII
- GLUE
- R-GMA
Begründung: Das GLUE‑Schema dient als Standard zur Beschreibung (Spezifikation) von Ressourcen im Grid.
(iii) Was ist als Informationssystem Bestandteil von UMD?
- BDII
- GLUE
- R-GMA
Begründung: In der Unified Middleware Distribution (UMD) wird häufig der BDII (Berkeley Database Information Index) als Informationssystem eingesetzt, das Ressourcendaten gemäß dem GLUE‑Schema sammelt und bereitstellt.
Aufgabe B – Proxy-Zertifikate
Gegeben:
- Proxy-Zertifikat (Ausgangszertifikat):
- Issuer:
…/CN=Christian Straube - Subject:
…/CN=Christian Straube/CN=proxy
- Issuer:
- Abgeleitetes Proxy-Zertifikat:
- Issuer:
…/CN=Christian Straube/CN=proxy - Subject:
…/CN=Christian Straube/CN=proxy/CN=proxy
- Issuer:
Aufgabe: Geben Sie den Common Name (CN) für Issuer und Subject im abgeleiteten Zertifikat an.
Lösung:
- Issuer:
…/CN=Christian Straube/CN=proxy - Subject:
…/CN=Christian Straube/CN=proxy/CN=proxy
Erläuterung: Beim Ableiten eines neuen Proxy-Zertifikats wird der bisherige Subject zum neuen Issuer, und es wird ein zusätzlicher /CN=proxy-Eintrag an den Subject angehängt.
Aufgabe C – WSDL & Job-Ausführung
Gegeben:
- Eine WSDL-Datei,
- Ein Aktivitätsdiagramm zur Job-Ausführung,
- Nummerierte Funktionsaufrufe (z. B.
1 - submitJob(),x - getResourceList(),y - createJob(),z - transferRequest()).
(a) Tabelle ausfüllen: Nummer der Funktion → WSDL-Datei-Sektionen als Parameter
Musterlösung (Beispielhafte Zuordnung):
| Funktionsnummer | Entsprechende WSDL-Sektion | Parameter/Message-Typ |
|---|---|---|
| 1 – submitJob() | <wsdl:operation name="SubmitJob"> | SubmitJobRequest, SubmitJobResponse |
| x – getResourceList() | <wsdl:operation name="GetResourceList"> | GetResourceListRequest, GetResourceListResponse |
| y – createJob() | <wsdl:operation name="CreateJob"> | CreateJobRequest, CreateJobResponse |
| z – transferRequest() | <wsdl:operation name="TransferRequest"> | TransferRequest, TransferResponse |
Erläuterung: Die Zuordnung erfolgt anhand der in der WSDL definierten Operationen und den zugehörigen Nachrichten (Input/Output).
Aufgabe D – Implied Resource Pattern
(a) Was wird beim Implied Resource Pattern vom Client beim Ressource-Abruf angesprochen?
- Ressource
- Instance Service
- Ressource Home
Begründung:
Beim Implied Resource Pattern wird der Ressourceneintrag implizit über die Service-Endpunktadresse angesprochen. Das heißt, der Client ruft nicht explizit einen separaten „Resource Home“ oder einen speziellen „Instance Service“ auf – vielmehr ist die Ressource (der Service, der die Ressource repräsentiert) direkt adressierbar.
Aufgabe E – Factory Pattern
(a) Welche Komponente muss erweitert werden, wenn man im Factory-Pattern einen neuen Service hinzufügen möchte, der eine destroy-Operation durchführt?
- Factory Service
- Instance Service
- Ressource
Begründung:
Die destroy‑Operation gehört zur Verwaltung des Lebenszyklus einer Ressource. Wird ein neuer Service mit Destroy-Funktionalität eingeführt, so muss der Instance Service – der für die Verwaltung und Operationen an der einzelnen Ressource zuständig ist – erweitert werden, um diese Operation zu unterstützen.
(b) Factory-Pattern-Modell
Aufgabe: Beschriften Sie das folgende (gedachte) Diagramm.
Beispielhafte Lösung (Diagramm und Beschreibung):
flowchart TD
A[Client] -->|createResource()| B[Factory Service]
B -->|instanziiert| C[Instance Service]
C -->|erstellt| D[Ressource]
D -->|Rückgabe der Referenz| B
B -->|liefert Referenz| A
A -->|destroyResource()| C
Beschriftung der Komponenten:
- Factory Service: Verantwortlich für die Erzeugung von Ressourceneinheiten (Fabrikmuster).
- Instance Service: Bietet Operationen (z. B. destroy, getResourceProperties) zur Verwaltung der einzelnen Ressource.
- Ressource: Die eigentliche Instanz, die den Service repräsentiert.
Pfeile (Aktionen):
- Client → Factory Service:
createResource() - Factory Service → Instance Service:
instantiateResource() - Instance Service → Ressource:
create() - Instance Service → Factory Service:
returnResourceReference() - Factory Service → Client:
deliverResourceReference() - Client → Instance Service:
destroyResource()
Aufgabe F – Web Services & WS-Resource
(a) Pseudo-XML-SOAP-Inhalt für einen WS-Ressource-Aufruf
Beispielhafte Lösung (z. B. für einen Destroy-Aufruf):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsr="http://example.org/wsresource">
<soapenv:Header/>
<soapenv:Body>
<wsr:Destroy>
<wsr:ResourceID>urn:uuid:12345-abcde</wsr:ResourceID>
</wsr:Destroy>
</soapenv:Body>
</soapenv:Envelope>Erläuterung:
Dies ist ein vereinfachtes Beispiel, in dem der Client über SOAP den WS‑Resource-Service aufruft, um eine destroy‑Operation an einer Ressource (identifiziert durch ResourceID) auszuführen.
Aufgabe G – Grid Monitoring Architecture (GMA)
(a) Beschriften Sie das leere GMA-Modell
Musterlösung (Typische GMA-Komponenten):
- Producer:
– Publiziert Monitoring-Daten (z. B. Status, Performance-Daten). - Aggregator (oder Registry):
– Sammelt und aggregiert die von den Producers veröffentlichten Daten.
– Oft auch als Verzeichnisdienst (Directory) für Monitoring-Daten genutzt. - Consumer:
– Abonniert oder fragt die Monitoring-Daten ab, um z. B. den Systemstatus zu überwachen.
Pfeile beschriften:
- Von Producer zu Aggregator: „publish()“ oder „register data“.
- Von Aggregator zu Consumer: „query()“ bzw. „notify()“ (bei Abonnements).
- Eventuell auch direkte Abfragen vom Consumer an den Producer („pull“).
Hinweis: Die genaue Benennung kann je nach spezifischem GMA-Modell variieren.
Aufgabe H – Zertifikate & Grid-Sicherheit
(a) In welchem Verzeichnis werden bei GT die Zertifikate gespeichert?
Antwort:
~/.globus
(b) Was macht der Befehl voms-proxy-init und warum reicht grid-proxy-init nicht aus?
Antwort:
- voms-proxy-init:
– Dieser Befehl erstellt für den Benutzer ein Proxy‑Zertifikat, das neben der normalen Authentifizierung auch VO‑Attribute (Virtual Organization‑Informationen) enthält. - grid-proxy-init:
– Er erstellt ein „Plain‑Proxy‑Zertifikat“ ohne VO‑Attribute.
Begründung:
In Grid‑Umgebungen sind die VO‑Attribute wichtig, um Zugriffsrechte und Rollen innerhalb der virtuellen Organisation zu definieren. Daher istvoms-proxy-initerforderlich, um alle nötigen Informationen bereitzustellen.