Autorisation und VO Management Grid Seminar 2005 Stefan Franke, Benjamin Henne S. Franke, B. Henne 14. Dezember 2005
Outline Überblick Virtuelle Organisation Autorisation Globale Autorisation VOMS Attributzertifikate Lokale Autorisation Autorisationsentscheidung und Erzwingung (LCAS) Isolation und Sandboxing (LCMAPS) Ausblick S. Franke, B. Henne 14. Dezember 2005 Folie 2
Virtuelle Organisation Definition (Wikipedia) Eine Virtuelle Organisation (VO) ist eine Form der Organisation, bei der sich rechtlich unabhängige Unternehmungen und/oder auch Einzelpersonen virtuell für einen gewissen Zeitraum zu einem gemeinsamen Geschäftsverbund zusammenschließen. Gegenüber Dritten bzw. Auftraggebern tritt das Virtuelle Unternehmen wie ein einheitliches Unternehmen auf. Durch die Virtualität ist der physische Standort der einzelnen Teilnehmer nicht von Bedeutung. S. Franke, B. Henne 14. Dezember 2005 Folie 3
Virtuelle Organisation Beispiel VO 2 VO 1 VO 3 Person, Institution o.ä. S. Franke, B. Henne 14. Dezember 2005 Folie 4
Virtuelle Organisation Beispiel (2) Site A Site B Site C VO 3 VO 1 VO 2 S. Franke, B. Henne 14. Dezember 2005 Folie 5
Virtuelle Organisation Vorteile Flexibel Räumlich verteilt Kernkompetenzen einzelner Personen, Institute o.ä. werden genutzt Herausforderungen Schwierig zu kontrollieren Vertrauenswürdigkeit der Partner muss garantiert sein S. Franke, B. Henne 14. Dezember 2005 Folie 6
Autorisation Die Autorisation schützt Ressourcen Nur bestimmten Konsumenten wird das Recht erteilt ausgewählte Ressourcen zu benutzen. Konsumenten: Benutzer, Programme, Geräte, Ressourcen: Daten, Programme, Geräte, Funktionalitäten, Der Autorisationsprozesse entscheidet Welcher Konsument erhält Zugang zu welchen Ressourcen? S. Franke, B. Henne 14. Dezember 2005 Folie 7
Global Security Architecture S. Franke, B. Henne 14. Dezember 2005 Folie 8
Autorisationsmodelle Problem im Grid Überlagerung verschiedener Berechtigungen Lösung durch drei grundlegende Modelle push - Modell Autorisationsdienst verteilt Tokens, Benutzer sammelt diese und erhält Zugang zu Ressourcen Ressource muss nichts über Benutzerrechte im Voraus wissen agent - Modell Benutzer spricht nur mit einem zentralen Autorisations-Server Dieser leitet alle spezifischen Informationen an darunter liegende Ressourcen pull - Modell Bei Benutzeranfragen kontaktiert die Ressource verschiedene Autorisationsdienste Bsp.: GSM Roaming, RADIUS S. Franke, B. Henne 14. Dezember 2005 Folie 9
Autorisationsdienste Attribute Authority (AA) Service AA assoziiert Benutzer mit Attributen (digital signiert) auf Anfrage Benutzer sendet seine Attribute an Ressourcen Ressource wertet Attribute aus Gegenprüfen der lokalen Site-Policy Bsp.: VOMS Policy Assertion Service Ablauf wie oben Benutzer erhält explizite Berechtigungen statt Attribute vom Server Ressource prüft diese gegen lokale Berechtigungen Bsp.: Community Authorization Service (CAS), SAML S. Franke, B. Henne 14. Dezember 2005 Folie 10
Autorisation früher Frühe Version der Globus-Software Lokales grid-mapfile, Benutzer hat Account auf allen benötigten Ressourcen Probleme: Synchronisation in verteilten Umgebungen, skaliert schlecht (pro Benutzer ein Account) VO-LDAP-Server und grid-mapfile Veröffentlichen von VO/Gruppen-Zugehörigkeiten via Verzeichnis-Dienst Grid-mapfile ordnet einem Benutzer dynamisch einen Pool Account zu Problem: Verteilen der Informationen für das grid-mapfile (edg-mkgridmap als Cron-Job) Weitere Probleme Mitgliedschaft in mehreren VOs nicht möglich Es konnten weder VOs noch Gruppen oder Rollen vom Benutzer gewählt werden S. Franke, B. Henne 14. Dezember 2005 Folie 11
Globale Autorisation Globale Autorisation (VO Berechtigungen, VOMS) Grobe und globale Einteilung (VO, Gruppe, Rolle) Festlegung unabhängig von den Ressourcen S. Franke, B. Henne 14. Dezember 2005 Folie 12
Globale Autorisation (2) Realisiert durch Virtual Organization Membership Service (VOMS) Zentrale Datenbank Jedem Benutzer werden VOs, Gruppen, Rollen und Capabilities zugeordnet Benutzer erhält Attribut-Zertifikat via voms-proxy-init (Argumente möglich, um VO und Gruppe auszuwählen) S. Franke, B. Henne 14. Dezember 2005 Folie 13
Virtual Organisation Membership Service (VOMS) Eigenschaften Client-Server-Architektur Ersetzt die alten GLOBUS Befehle (z.b. grid-proxy-init) Benutzer erhält Attribut-Zertifikat vom VOMS-Server (push-modell) Verwendung von Attribut-Zertifikaten Keine direkte Interaktion mit anderen Diensten im Grid VOMS-Informationen nutzbar über eine API S. Franke, B. Henne 14. Dezember 2005 Folie 14
VOMS-Server Besteht aus Autorisations-Datenbank VOMS Core Service (Schnittstelle für Benutzer) User Interface Command Line oder API VOMS Admin Service (Schnittstelle für Administrator) Command Line Interface über SOAP und SSL UI über Web Browser und HTTPS S. Franke, B. Henne 14. Dezember 2005 Folie 15
VOMS-Datenbank Eigenschaften RDBMS, häufig MySQL Management einer oder mehrerer VOs je VOMS-Server Alle gelöschten Einträge werden in parallelen Tabellen gespeichert (zusätzlich deletedby und deletedserial) S. Franke, B. Henne 14. Dezember 2005 Folie 16
VOMS-Core-Service (Command Line) voms Liefert Informationen über die Einstellungen des Servers voms-proxy-init Attribut-Zertifikat erstellen voms-proxy-info Liefert Informationen aus einem VOMS-Proxy-Zertifikat voms-proxy-destroy Zerstört existierendes Proxy-Zertifikat S. Franke, B. Henne 14. Dezember 2005 Folie 17
VOMS-Admin-Service (Command Line) voms-admin-configure Erstellen und Löschen von VOs voms-admin Verwalten von VOs init-voms-admin Starten und beenden des Web-Services von voms-admin voms-ldap-sync Eine VO aus LDAP in die VOMS-DB importieren cron-voms-ldap-sync Cron-Job für voms-ldap-sync voms-db-dump Erzeugt ein DB-Dump für ein Backup voms-db-load Eine VO-DB aus einer Dump-Datei erstellen voms-db-upgrade Eine alte Datenbank umstrukturieren für aktuelle VOMS-Server S. Franke, B. Henne 14. Dezember 2005 Folie 18
Praxis: voms-proxy-init Ablauf des voms-proxy-init User authentifiziert sich mit seinem Zertifikat am VOMS User stellt signierte Anfrage an VOMS VOMS prüft Korrektheit der Anfrage VOMS sendet Informationen signiert zurück (Attribut-Zertifikat) User prüft die empfangenen Informationen (Validierung der Signatur) User erstellt Proxy-Zertifikat VOMS-Informationen in einer nicht kritischen Erweiterung Benutzer kann weitere Authentifizierungs-Informationen hinzufügen (z. B. Kerberos ticket) Schritt 1 bis 5 können vor Schritt 6 mehrfach durchgeführt werden, damit das Proxy-Zertifikat die Informationen mehrerer VOMS-Server enthält. S. Franke, B. Henne 14. Dezember 2005 Folie 19
Attribut-Zertifikate Eigenschaften Basieren auf Zertifikaten nach X.509, verwenden Erweiterungen VOMS-Erweiterungen werden durch OID 1.3.6.1.4.1.8005.100.100 gekennzeichnet Diese Bezeichnung ist eindeutig und für VOMS reserviert Verwenden Fully Qualified Attribute Names (FQAN) <group name>/role=[<role name>][/capability=<capability name>] Vorteile gegenüber sog. Pseudo-Zertifikaten Eindeutige gegenseitige Bedingung innerhalb der Attribute Kein Missverstehen mehr unter verschiedenen Nutzern von Attribut-Zertifikaten ACLs lassen sich besser anwenden S. Franke, B. Henne 14. Dezember 2005 Folie 20
Attribut-Zertifikate (2) Werden aktuell verwendet, in Anlehnung an Attribut-Zertifikate Certificate: Data: [ Zertifikat ] X509v3 extensions: 1.3.6.1.4.1.8005.100.100.5: 0...0...0...0.....0Q.O0I.G0E1.0...U.. GermanGrid1.0...U...UniHannover1.0...U...Thomas Warntjen...Y0W.U0S1.0...U.. GermanGrid1.0...U...UniHannover1&0$..U...voms1.gridlab.uni-hannover.de0..*.H.....:.0"..20051116124033Z..20051117004033Z0c0a. +...Edd.1S0Q.,.*RRZN://voms1.gridlab.unihannover.de:150000!../RRZN/Role=NULL/Capability=NULL0,0...U.8...0...U.#..0...E..-.d..&...Z...0..*.H.....K*.{..K.w.."..\...M..K..U.V...s..8...\0..I...H./.g..o...8$L"[...[f...5=....rjk4...:0=.@..A... 8...9...QA..J..W...F..3. x...=4..y.n.c..&.hxvg......r1.".}.q.!...?q...yba..i.)...r..- ZP...[Q3...npV....+.u...h. X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment 1.3.6.1.4.1.8005.100.100.6: 01 Signature Algorithm: md5withrsaencryption [ Signatur ] S. Franke, B. Henne 14. Dezember 2005 Folie 21
Attribut-Zertifikate (3) [studies@ui1 studies]$ voms-proxy-info all subject : /O=GermanGrid/OU=UniHannover/CN=Stefan Piger/CN=proxy issuer : /O=GermanGrid/OU=UniHannover/CN=Stefan Piger identity : /O=GermanGrid/OU=UniHannover/CN=Stefan Piger type : proxy strength : 512 bits path : /tmp/x509up_u502 timeleft : 11:59:55 === VO RRZN extension information === VO : RRZN subject : /O=GermanGrid/OU=UniHannover/CN=Stefan Piger issuer : /O=GermanGrid/OU=UniHannover/ CN=voms1.gridlab.uni-hannover.de attribute : /RRZN/Role=glite-admin/Capability=NULL attribute : /RRZN/Role=NULL/Capability=NULL timeleft : 12:00:16 S. Franke, B. Henne 14. Dezember 2005 Folie 22
VOMS-Server-Interfaces (API) Drei grundlegende Datenstrukturen data Informationen über Gruppe, Rolle und Capabilities voms Informationen über alle VOMS-Eigenschaften, abgeleitet aus dem Attribut-Zertifikat vomsdata Informationen aus der VOMS-Extension C++ -- API C -- API S. Franke, B. Henne 14. Dezember 2005 Folie 23
Lokale Autorisation Lokale Autorisation Global werden Rollen, etc. der VO-Mitglieder definiert Lokale Richtlinien definieren allgemeine Berechtigungen auf Ressourcen Lokales System muss globale Festlegungen und lokale Richtlinien in Einklang bringen S. Franke, B. Henne 14. Dezember 2005 Folie 24
Lokale Autorisation (2) Autorisationsentscheidungen und ihre Erzwingung Autorisationsentscheidungen Darf Benutzer X die gewünschte Aktion ausführen? Erzwingung der Entscheidung Benutzer X darf nur genau die Aktionen a, b und c auf dem System ausführen Lasse Benutzer X nur auf die erlaubten Ressourcen zugreifen EGEE Authorization Framework legt dieses fest Isolation der Benutzer und Sandboxing Isoliere Benutzer vom genutzten System Isoliere die verschiedenen Benutzer des Systems voreinander Durch Unix Accounts und inhärente Separationsmechanismen S. Franke, B. Henne 14. Dezember 2005 Folie 25
EGEE Authorization Framework Aufgaben Beziehen, Auswerten, Kombinieren und Erzwingen von Sicherheitsrichtlinien Ziele für das Autorisationssystem Leichtgewichtig Einfach zu administrieren und konfigurieren Erweiterbar Flexibel Das System modulare Architektur verschiedene Autorisationsmodule liefern Ergebnis erlauben oder verweigern logische und/oder-verknüpfung der Module liefert Autorisationsentscheidung S. Franke, B. Henne 14. Dezember 2005 Folie 26
EGEE Authorization Framework (2) Bestandteile Policy Enforcement Point (PEP) startet eine Auswertung verketteter Autorisationsmodule, um eine Autorisationsentscheidung zu fällen Policy Administration Point (PAP) stellt Eingriffsmöglichkeit für Administratoren bereit Verschiedene Autorisationsmodule Policy Information Point (PIP) Sammeln und Prüfen von Informationen und Rechten, die mit dem authentifizierten Benutzer assoziiert sind (z. B. VOMS-Informationen) Policy Decision Point (PDP) Aufrufen untergeordneter PDP ermöglicht baumartige Strukturierung Fällen Autorisationsentscheidungen aufgrund von Informationen aus PIP und weiteren Quellen, z. B. Vergleich von Proxy Zertifikat DN mit einer Blacklist S. Franke, B. Henne 14. Dezember 2005 Folie 27
EGEE Authorization Framework (3) S. Franke, B. Henne 14. Dezember 2005 Folie 28
Isolation und Sandboxing durch Unix Accounts Benutzer arbeiteten mit verschiedenen Accounts im System Unterscheidung durch uid und gid Benutzer agieren im eigenen home-verzeichnis (Sandbox) Accounts haben verschiedene Rechte im System Zugriffsrechte nur auf ausgewählte und eigene Dateien Zugriffsrechte auf (ausgewählte) Applikationen Einfache Implementation im Vergleich zur vollständigen Virtualisierung von Ressourcen. Jedoch: Gefährlicher, da keine komplette Isolation möglich. S. Franke, B. Henne 14. Dezember 2005 Folie 29
Autorisation und Isolation in glite Dienste Local Centre Authorization Service (LCAS) Local Credential MAPping Service (LCMAPS) LCAS und LCMAPS sind realisiert als Erweiterung des Gatekeeper auf den CE 0. Job Request erreicht den Gatekeeper über authentifizierten Kanal 1. Autorisation wird durch LCAS geprüft 2. Autorisation: Aktion erlauben oder verbieten 3. Gatekeeper fragt LCMAPS nach Credential Abbildung für den Job im Grid 4. Wenn Credentials abgebildet werden können, wird Job an Batch System gegeben, andernfalls Job-Abbruch mit Authz-Fehler S. Franke, B. Henne 14. Dezember 2005 Folie 30
Local Centre Authorization Service (LCAS) Funktionen Erweitert den Gatekeeper um Zugriffskontrollen Prüft ob Benutzer nötige Credentials hat, um eine Aktion auszuführen Design modularisiert: unabhängige Autorisationsmechanismen als LCAS-Plugins Verschiedene Module (PIP, PDP) erzeugen gemeinsam Autorisationsentscheidung Eigene Module können erstellt und eingesetzte werden Fällt Autorisationsentscheidung aufgrund von Angefragte Ressourcen (definiert in RSL - Ressource Specification Language) Identität des Anfragenden Definierte Berechtigungen für den Anfragenden aus dem Proxy-Zertifikat (VOMS-Informationen: VO, Gruppe, Rolle, Capability) Logging Welche Autorisation wurde durch welche Module wem (nicht) gewährt S. Franke, B. Henne 14. Dezember 2005 Folie 31
LCAS: Autorisationsmodule Standardmodule Erlaubte Benutzer / Whitelist Liste aller Benutzer DN, denen Zugriff zum System gewährt wird. In LCAS 1.1 noch nicht implementiert. Soll grid-mapfile Nutzung ersetzen. Verbannte Benutzer / Blacklist Liste aller Benutzer DN, denen der Zugriff zum System verwehrt wird Öffnungszeiten des Systems Zugang nur zu definierten Zeiten möglich VOMS-Informationen mit lokalen Zugriffsbestimmungen vergleichen Liste erlaubter VO-Gruppe-Rolle-Angaben (VOMS-Attribute) Definitionen in GACL (Grid ACL XML basierend) Definitionen in XACML (extensible Access Control Markup Language ) S. Franke, B. Henne 14. Dezember 2005 Folie 32
LCAS: Autorisationsmodule (3) Geplante Module (nach DJRA3.2) Überprüfung der Lebensdauer der Proxy-Zertifikate Prüft, ob die Lebenszeit eines Proxy Zertifikates (validuntil validfrom) ein lokal gesetztes Maximum nicht überschreitet Zertifikats-Erweiterungen prüfen Prüft, ob Zertifikat-Erweiterungen (z. B. policy OID) einer lokal vordefinierten Liste entsprechen Peer System validieren Validiert Hosts (Agenten) anhand ihres Zertifikates Darf der Agent auf Host X meinen Dienst Y nutzen? Zentrale Widerrufsprüfung von Zertifikaten S. Franke, B. Henne 14. Dezember 2005 Folie 33
Praxis: LCAS- und LCAS-Modul-Konfiguration /etc/lcas/lcas.db LCAS-Konfiguration pluginname=lcas_userban.mod,pluginargs=ban_users.db pluginname=lcas_voms.mod, pluginargs="-vomsdir /etc/grid-security/vomsdir -certdir /etc/grid-security/certificates -authfile /etc/grid-security/grid-mapfile -authformat simple -use_user_dn" /etc/lcas/ban_users.db Enthält DN der gebannten Benutzer VOMS-Modul nutzt aktuell grid-mapfile S. Franke, B. Henne 14. Dezember 2005 Folie 34
Praxis: LCAS- und LCAS-Modul-Konfiguration (2) Beispiel: Lokale Zugriffsbestimmungen für VOMS-Modul in GACL <?xml version="1.0"?> <gacl version="0.0.1"> <entry> <voms-cred> <voms>/o=germangrid/ou=unihannover/cn=stefan Piger</voms> <vo>rrzn</vo> <group>rvs</group> </voms-cred> <allow><read/><write/></allow> <deny><list/></deny> </entry>... S. Franke, B. Henne 14. Dezember 2005 Folie 35
Praxis: LCAS- und LCAS-Modul-Konfiguration (3)... <entry> <person> <dn>/o=germangrid/o=users/o=rvs/cn=jan Wiebelitz</dn> </person> <allow><read/></allow> <deny><list/></deny> </entry> </gacl> GACL unterstützt Angabe von VOMS Credentials (voms-cred) und DN (person) S. Franke, B. Henne 14. Dezember 2005 Folie 36
Local Credential MAPping Service (LCMAPS) Funktionen Als Bestandteil des Gatekeepers realisiert Abbildung von allgemein definierten Rechten für Grid-Job auf lokale Systemrechte Design Modularisiert Beschaffung (acquisition): Sammeln von Informationen über Credentials für Abbildungen Erzwingung (enforcement): Erzwingen der Credentials (durch Abbildungen) Module sorgen gemeinsam für Umsetzung der Credentials im lokalen System Eigene Module können erstellt und eingesetzte werden S. Franke, B. Henne 14. Dezember 2005 Folie 37
LCMAPS: Module Standardmodule Statische Abbildung von Benutzer (DN) auf eine uid/gid basierend auf grid-mapfile Abbildung von Benutzer (DN) auf einen für die Dauer eines Jobs zugeteilten Unix Account (Pool Account Leasing) und eine entsprechende Gruppe Abbilden von VOMS Gruppe, Rolle, Capabilities auf Unix Gruppen z.b. ähnlich dem Prinzip der Pool Accounts Erstellen eines zum Benutzer (DN) passenden AFS Token, falls z. B. lokales home-verzeichnis in einem AFS Dateisystem liegt Setzen der effektiven uid und gid von Prozessen (POSIX in-process enforcement) Aktualisieren von zentralen Benutzerinformationen in einem Verzeichnisdienst Nötig für manche Cluster mit Batch System S. Franke, B. Henne 14. Dezember 2005 Folie 38
LCMAPS: Konfiguration /etc/lcmaps/lcmaps.db Legt fest welche LCMAPS-Module mit welchen Parametern verwendet werden Definiert Abbildungsrichtlinien (policies) Richtlinie als deterministischer endlicher Automat (DEA) mit Modulen als Zustände Richtlinien werden nacheinander abgearbeitet bis eine erfüllt ist Schlägt Prüfung einer Richtlinie fehl, wird die nächste geprüft Beispiel: Zwei Abbildungsrichtlinien und Darstellung der ersten als DEA # policies mypolicy: localaccount -> posix_enf poolaccount poolaccount -> voms voms -> posix_enf standard: poolaccount -> posix_enf S. Franke, B. Henne 14. Dezember 2005 Folie 39
Praxis: Abbildung auf Unix bzw. Pool Account Auf System existieren die Accounts (evtl. mit verschiedenen lokalen Rechten) cgrimm rrzn001 bis rrzn010 gridsem001 bis gridsem020 grid-mapfile "/O=GermanGrid/OU=UniHannover/CN=Christian Grimm" cgrimm "/O=GermanGrid/OU=UniHannover/CN=Stefan Franke".rrzn "/O=GermanGrid/OU=UniHannover/CN=Benjamin Henne". Abbildung der 3 Grid-Nutzer Christian Grimm lokaler Unix Account cgrimm Stefan Franke Zuweisung eines Pool Accounts aus rrzn001 bis rrzn010 Benjamin Henne Zuweisung eines Pool Accounts aus rrzn001 bis rrzn010 oder gridsem001 bis gridsem020 S. Franke, B. Henne 14. Dezember 2005 Folie 40
Praxis: Abbildung von VOMS-Informationen grid-mapfile "/VO=rrzn/GROUP=rvs/ROLE=dozent" cgrimm "/VO=rrzn/GROUP=rvs".gridsem "/VO=rrzn/GROUP=*".rrzn Abbildung Mitglied der VO rrzn mit Gruppe rvs und Rolle dozent wird auf Unix Account cgrimm mit Gruppe rvs wird auf Pool Account aus gridsem001 bis gridsem020 mit beliebiger Gruppe wird auf Pool Account aus rrzn001 bis rrzn010 abgebildet Abbildung auf Unix Gruppen analog über groupmapfile S. Franke, B. Henne 14. Dezember 2005 Folie 41
Anmerkungen zur Autorisation LCAS und LCMAPS realisieren Autorisation nur auf den CE WMS nutzt nur Abbildung von DN auf Unix Accounts WMS kennt keine VO WMS kann nicht zwischen Mitgliedern verschiedener VO differenzieren Authorization Framework kann für andere Grid Services genutzt werden z. B. für GridFTP Nachrüsten der Grid Autorisation bei existierenden (nicht-grid) Services (z. B. ssh) Eventuell möglich über ein Grid-PAM Module (Pluggable Authentication Modules) S. Franke, B. Henne 14. Dezember 2005 Folie 42
Workspace Service (WSS) Motivation Nutzung von Account-Leasing-Mechanismen, wie Pool Accounts, lässt keine individuelle Anpassung des Workspaces eines Nutzers zu Keine Variation in z. B. der Disk Quota möglich Benutzer (VO-Rollen etc.) sollen Parameter ihrer Accounts anpassen können Workspace Service (WSS) Dynamic Account Factory (DAF) Erzeugen individueller Accounts oder Gruppen von Accounts Dynamic Account Service (DAS) Verwalten individueller Einstellungen von Accounts Workspace Erstellen und Verwalten Dynamische Erzeugung von Accounts mittel Unix-Kommando useradd Basierend auf Pool Accounts Mit glite möglich, am RRZN nicht realisiert S. Franke, B. Henne 14. Dezember 2005 Folie 43
Job Repository (JR) Aufgaben Speichert mit aktuellen Grid-Jobs assoziierte Credentials Speichert mit beendeten Grid-Jobs assoziierte Credentials Erhält Informationen von LCMAPS und Job Management System Datenpersistenz (der Credentials) auch nach Beendigung eines Jobs Welche Credentials hatte ein Job und wie wurden sie abgebildet? S. Franke, B. Henne 14. Dezember 2005 Folie 44
Ausblick Autorisation Implementation eines Standalone Authorization Service Kompatibilität zu GT2 Gatekeeper durch LCAS-Plugin, dass diesen Service befragt Ähnliche Implementation für ein neu standardisiertes Credential Mapping (CM) angedacht Isolation und Sandboxing Grid-Jobs in Virtuellen Maschinen? Isolation durch UML oder Xen? S. Franke, B. Henne 14. Dezember 2005 Folie 45
Literatur (1) Papers Authentication and Authorization Mechanisms for Multi-Domain Grid Environments, Journal of Grid Computing (2004) 2: 301-311 http://www.urec.cnrs.fr/img/pdf/articles.04.gridjournal-edg-scg-paper.pdf Managing Dynamic User Communitiers in a Grid of Autonomous Resources, CHEP 2003, La Jolla San Diego http://www.gridpp.ac.uk/papers/chep03_tubt005.pdf Autonomic Management of Large Clusters and Their Integration into the Grid, Journal of Grid Computing (2004) 2: 247 260 http://www.nikhef.nl/grid/lcaslcmaps/publications/edg-wp4_paper.pdf DataGrid Policy Discription Language Module Requirements & design http://www.dutchgrid.nl/datagrid/wp4/lcmaps/edg-lcmaps-0.0.3/pdl_requirements.pdf EGEE Global Security Architecture EU Deliverable DJRA3.1 https://edms.cern.ch/document/487004/ EGEE Site Access Control Architecture DJRA3.2 https://edms.cern.ch/document/523948/ A VOMS Attribute Certificate Profile for Authorization, Vincenzo Ciaschini, April 15, 2004 http://grid-auth.infn.it/docs/ac-rfc.pdf S. Franke, B. Henne 14. Dezember 2005 Folie 46
Literatur (2) Dokumentationen Guide to LCAS http://www.dutchgrid.nl/datagrid/wp4/lcas/ Guide to LCMAPS http://www.dutchgrid.nl/datagrid/wp4/lcmaps/ Guide to Job Repository http://www.nikhef.nl/grid/lcaslcmaps/org.glite.security.lcmaps-plugins-jobrep/ The gridmapdir patch for Globus http://www.gridsite.org/gridmapdir/ The combined installation of (glite-)gatekeeper+lcas+lcmaps and the workspace service http://www.nikhef.nl/grid/lcaslcmaps/installation_notes/install_with_workspace_service S. Franke, B. Henne 14. Dezember 2005 Folie 47