Studienarbeit. Authentifizierungs- und Informationsdienst

Größe: px
Ab Seite anzeigen:

Download "Studienarbeit. Authentifizierungs- und Informationsdienst"

Transkript

1 Fakultät für Informatik Professur für Rechnernetze und verteilte Systeme Studienarbeit Authentifizierungs- und Informationsdienst Verfasser: Jens Wegener 30. Juni 2004 Prüfer: Betreuer: Prof. Dr.-Ing. habil. Uwe Hübner Dipl.-Inf. Ronald Schmidt

2

3 Inhaltsverzeichnis Abkürzungsverzeichnis iii 1 Aufgabenstellung 1 2 Einleitung Motivation Identität und Authentifizierungsverfahren Attribute eines Nutzers Situation und Verbesserungsmöglichkeiten Anforderungen an den Identitätsmanager Datenschutzrechtliche Erwägungen Anwendbares Recht Einwilligung des Nutzers in die Datenweitergabe Form der Einwilligung Anforderungen an die Datenübermittlung Möglichkeit der anonymen und pseudonymen Nutzung Technische Anforderungen Technische Grundlagen Kommunikation zwischen Nutzer, Anbieter und Identitätsmanager Sicherheit der Kommunikation Cookies Vorhandene Ansätze ITS Central Authentication Service Überblick Funktionsweise Single Sign-On Erweiterungen des CAS Microsoft.NET Passport i

4 Inhaltsverzeichnis Überblick Funktionsweise der Authentifizierung Single Sign-On Liberty Alliance Project Überblick Architektur Shibboleth/Internet Überblick Aufbau und Funktionsweise Verfügbare Implementierung Bewertung der betrachteten Ansätze ITS Central Authentication Service Microsoft.NET Passport Liberty Alliance Project Shibboleth Nicht betrachte Ansätze Abgrenzung der weiteren Arbeit Testbetrieb von Shibboleth Vorbemerkungen Installation des Identitätsverwalters Installation des Anbieter-Server Schlüssel und Zertifikate Konfiguration von Shibboleth Konfiguration des Identitätsverwalters Konfiguration des Anbieter-Servers Testergebnisse Offene Fragen Schlussfolgerung 51 Literaturverzeichnis 53 ii

5 Abkürzungsverzeichnis AA AAP AFS AQH AQM ARM ARP BDSG CA CAS DNS GG HS HTML HTTP IP ITS JSP MACE MDStV NAT Attribute Authority Attribute Acceptance Policy Andrew File System Attribute Query Handle Attribute Query Message Attribute Response Message Attribute Release Policy Bundesdatenschutzgesetz Certificate Authority Central Authentication Service Domain Name System Grundgesetz Handle Service Hyper Text Markup Language Hyper Text Transfer Protocol Internet Protocol Information Technology Services Java Server Pages Middleware Architecture Committee for Education Mediendienste-Staatsvertrag Network Address Translation iii

6 Abkürzungsverzeichnis PHP PHP Hypertext Preprocessor PUID Microsoft.NET Passport Unique ID RM Resource Manager SächsDSG.... Sächsisches Datenschutzgesetz SächsHG..... Gesetz über die Hochschulen im Freistaat Sachsen SächsVerf... Verfassung des Freistaates Sachsen SAML Security Assertion Markup Language SHAR Shibboleth Attribute Requester SHIRE Shibboleth Indexical Reference Establisher SSL Secure Socket Layer SSO Single Sign-On TCP Transport Control Protocol TDDSG Teledienste-Datenschutzgesetz TDG Teledienstegesetz TLS Transport Layer Security TUC Technische Universität Chemnitz URI Uniform Resource Identifier URL Uniform Resource Locator URZ Universitätsrechenzentrum WAYF Where Are You From? (-Dienst) World Wide Web XML extensible Markup Language XNS extensible Name Service iv

7 1 Aufgabenstellung An der TU-Chemnitz werden auf verschiedenen Servern dezentral Dienste per HTTP angeboten, die einerseits die Nutzer zuverlässig authentifizieren müssen und andererseits auch persönliche Informationen dieser Nutzer benötigen. Dies führt zu einer Mehrfacherhebung von personenbezogenen Daten, obwohl die zentrale Nutzerdatenbank des Universitätsrechenzentrums bereits viele dieser Informationen enthält und ohne dass die Daten erhebende Stelle auf die Korrektheit der Daten vertrauen kann. Für die dezentrale Authentifizierung wurden bisher mehr oder weniger elegante Hilfskonstruktionen eingesetzt. Diese sind möglicherweise nicht robust gegen Änderungen an dritter Stelle. Außerdem nutzen sie unter Umständen Verfahren, die keinen ausreichenden Schutz der vertraulichen Kennworte gewährleisten. Das Ziel dieser Arbeit ist es, einen Dienst zu schaffen, der als vertrauenswürdiger Vermittler zwischen zentraler Nutzerdatenbank, Daten anfordernder Stelle und Nutzer auftritt und der anfordernden Stelle die Korrektheit der Authentifizierung und der Nutzerdaten zusichert. Besonderes Augenmerk wird auf die damit verbundenen datenschutzrechtlichen Aspekte gelegt. Als Vorarbeit sind vorhandene Ansätze zu recherchieren und zu bewerten, zum Beispiel: Shibboleth/Internet2 (http://shibboleth.internet2.edu) ITS Central Authentication Service (http://www.yale.edu/tp/auth).net Passport (http://www.passport.net) Liberty Alliance (http://www.projectliberty.org) 1

8 1 Aufgabenstellung 2

9 2 Einleitung 2.1 Motivation An der Technischen Universität Chemnitz (TUC) werden über das Internet, vor allem per WWW, verschiedene Dienste angeboten. Dazu zählen zum Beispiel: das Kursverwaltungssystem des Sprachenzentrums KuVeS 1 das Skriptportal des Instituts für Print- und Medientechnik 2 der Skriptshop des Fachschaftsrats Informatik 3 zugriffsbeschränkte Bereitstellung von Lehrmaterialien zum Download 4 private nichtkommerzielle Dienste zur Organisation von Grill 5 - und Pizzabestellungen 6 und zeitlichen Koordination von Gremiumssitzungen 7 und anderen Veranstaltungen 8 Die Bereitstellung dieser Dienste erfolgt dabei jeweils durch Einrichtungen der Universität, einzelne Universitätsmitarbeiter oder Studenten, im Folgenden kurz durch die Anbieter. Demgegenüber stehen Personen, die diese bereitgestellten Dienste in Anspruch nehmen, sie seien im Folgenden kurz als Nutzer bezeichnet. Im Zuge des Trends, bisher konventionell angebotene Dienstleistungen auf etwa (Zugriff nur innerhalb der TUC)

10 2 Einleitung Online-Systeme umzustellen, ist zudem mit einem kontinuierlichen Anstieg der Anzahl solcher Dienste zu rechnen. Die Anbieter benötigen für ihre Dienste Daten über die Nutzer. Für alle Shop -Dienste ist es zum Beispiel erforderlich festzustellen, welcher Nutzer eine bestimmte Bestellung veranlasst hat. Dienste wie das KuVeS fragen zusätzlich Matrikelnummer und Fakultät ab. Für andere Dienste kann es dagegen ausreichend sein, zu prüfen, ob ein Nutzer ein Student der TUC ist. Die benötigten Daten lassen sich damit in zwei Gruppen unterteilen: 1. die Identität des Nutzers 2. andere Daten (Attribute) über einen Nutzer 2.2 Identität und Authentifizierungsverfahren Der Begriff der Identität soll hier im Sinne eines eindeutigen Identifikators des Nutzers verstanden werden, der also jeweils nur genau einer Person zugeordnet ist. Zur Ermittlung dieses Identifikators werden Authentifizierungsverfahren eingesetzt. Es wird meist das vom Universitätsrechenzentrum der TUC vergebene Nutzerkennzeichen 9 und das zugehörige Zugangs- oder AFS-Passwort abgefragt. [30] Bei diesem Authentifizierungsverfahren muss der Nutzer dem Anbieter allerdings dahingehend vertrauen, dass dieser das übergebene Passwort nicht abspeichert und dann ggf. später sogar selbst unter der Identität des Nutzers auftritt. Einige der oben angegebenen Dienste sind zum Beispiel in PHP implementiert. Das Nutzerkennzeichen lässt sich dabei nach erfolgter Authentifizierung mittels $_SERVER[ PHP_AUTH_USER ] auswerten. Ebenso leicht kann aber, in der derzeit an der TUC betriebenen Konfiguration, auch das Passwort des Nutzers per $_SERVER[ PHP_AUTH_PW ] ermittelt werden, ohne dass der Nutzer dies bemerken würde oder verhindern könnte ist TUC-weit eindeutig einer Person zugeordnet 10 natürlich abgesehen davon, bestimmte Dienste nicht zu nutzen 4

11 2.3 Attribute eines Nutzers Vereinzelt findet man auch IP-basierte Authentifizierungsverfahren 11 oder andere anbieterspezifische Nutzer/Passwort-Systeme. 2.3 Attribute eines Nutzers Zu den Attributen eines Nutzers gehören im TUC-Bereich zum Beispiel: Name und Vorname Matrikelnummer Anschrift -Adresse Gruppenzugehörigkeit (Mitarbeiter oder Student der TUC) Fakultätszugehörigkeit (oder sonstige Einrichtung) Telefonnummer Diese Attribute sind zum Teil für die Nutzung der Dienste der Anbieter direkt durch die Nutzer einzugeben. Einige, wie Name, -Adresse und Fakultätszugehörigkeit, können innerhalb der TUC auch über einen LDAP- Server 12 abgefragt werden. Bei anderen Attributen muss ein Anbieter jedoch den vom Nutzer gemachten Angaben vertrauen, versehentliche oder absichtliche Fehleingaben können nicht direkt erkannt werden. Zudem muss ein Nutzer in diesen Fällen seine Daten ggf. wiederholt bei verschiedenen Anbietern eingeben. Viele der im Normalfall benötigten Attribute sind jedoch durch direkte Übernahme aus dem Datenbestand des Studentenamtes ohnehin bereits in der zentralen Nutzerdatenbank des Universitätsrechenzentrums, der MoUSe, gespeichert. [10, Datenübernahme vom Studentenamt] Andere, wie zum Beispiel die Adresse, können über das Nutzermenü 13 der MoUSe direkt vom Nutzer eingegeben werden. Fehleingaben bleiben bei diesen Attributen dann allerdings unerkannt. 11 Eine im Chemnitzer Studentennetz vergebene IP ist jeweils genau einem Nutzer zugeordnet. 12 ldap.tu-chemnitz.de 13 https://mouse.hrz.tu-chemnitz.de/user/ 5

12 2 Einleitung 2.4 Situation und Verbesserungsmöglichkeiten Es ergibt sich die Konstellation, dass eine dritte Instanz, nämlich das Universitätsrechenzentrum, insbesondere durch die MoUSe, über Daten verfügt, die die Anbieter für die Bereitstellung von Diensten benötigen. Sie kann zuverlässig und sicher Nutzer authentifizieren, Attribute über Nutzer bereitstellen und deren Korrektheit im oben beschriebenen Umfang zusichern. Seitens der Nutzer besteht jedoch auch ein regelmäßiges Interesse daran, dass ihre Attribute nicht frei verfügbar abgefragt werden können. Zudem können diese Daten aufgrund rechtlicher Zwänge nicht ohne weiteres an interessierte Anbieter herausgegeben werden. Eine Lösung wäre ein vom Universitätsrechenzentrum betriebener Dienst, der die Bereitstellung und den Zugriff auf die Daten geeignet regelt, im Folgenden nur noch kurz als Identitätsmanager oder auch Identitätsverwalter bezeichnet 14. Er wäre zudem für die korrekte Authentifizierung der Nutzer verantwortlich, ohne dass diese ihr Zugangs- oder AFS-Passwort gegenüber den einzelnen Anbietern offen legen müssen. 14 unter anderem auch zur besseren Unterscheidbarkeit zu den Diensten der Anbieter 6

13 3 Anforderungen an den Identitätsmanager 3.1 Datenschutzrechtliche Erwägungen Anwendbares Recht Grundlage des Datenschutzrechtes auf Bundesebene ist das durch Rechtssprechung des Bundesverfassungsgerichts aus Art. 2 Abs. 1 Grundgesetz (GG) [39] in Verbindung mit Art. 1 Abs. 1 GG abgeleitete Grundrecht auf informationelle Selbstbestimmung. [37] In Sachsen ist ein derartiges Grundrecht explizit in der Verfassung [40] verankert 15 und auf europäischer Ebene existiert eine entsprechende Richtlinie [38], die für die nationale Gesetzgebung bindend ist. Die Ausgestaltung dieses Grundrechts erfolgt für den öffentlichen Bereich auf Bundesebene und für den nicht-öffentlichen Bereich durch das Bundesdatenschutzgesetz (BDSG) 16 [41] und für den öffentlichen Bereich in Sachsen durch das Sächsische Datenschutzgesetz (SächsDSG) [42]. Das SächsDSG gilt insbesondere auch für der Aufsicht des Freistaates Sachsen unterstehenden juristischen Personen des öffentlichen Rechts. 17 Des Weiteren finden sich Regelungen zum Datenschutz in einer Reihe weiterer Gesetze und Verordnungen, die als Spezialregelungen dem BDSG bzw. dem SächsDSG vorgehen. 18 Hinsichtlich der Hochschulen in Sachsen und damit auch der Technischen Universität Chemnitz wäre hier das Gesetz über die Hochschulen im Freistaat Sachsen (SächsHG) 19 [43] zu nennen. 15 vgl. Art. 33 der Verfassung des Freistaates Sachsen (SächsVerf) 16 vgl. 1 Abs. 2 BDSG 17 vgl. 2 Abs. 1 SächsDSG 18 vgl. 1 Abs. 3 BDSG und 2 Abs. 4 SächsDSG 19 konkret 106 SächsHG 7

14 3 Anforderungen an den Identitätsmanager Auf die Dienste der Anbieter kann das Teledienstegesetz (TDG) [44] und damit auch das Teledienste-Datenschutzgesetz (TDDSG) [45] bzw. der Mediendienste-Staatsvertrag (MDStV) [46] anwendbar sein. Die Einhaltung der für sie geltenden rechtlichen Vorschriften ist jedoch alleinige Angelegenheit der Anbieter und bedarf daher hinsichtlich des Identitätsmanagers hier keiner tief greifenden Erörterung Einwilligung des Nutzers in die Datenweitergabe Die in der MoUSe gespeicherten personenbezogenen Daten werden für jeden Studenten zum Teil direkt aus dem Datenbestand des Studentenamtes übernommen (siehe Abschnitt 2.3). Dabei handelt es sich um nach 106 Abs. 1 SächsHG erhobene und weitergegebene 20 Daten. Sie dürfen unter anderem für die Teilnahme an Lehrveranstaltungen und die Nutzung von Hochschuleinrichtungen verarbeitet werden. Inwieweit einzelne in der Einleitung genannte Dienste und Anbieter unter diese Ermächtigung fallen, kann offen bleiben, da sie jedenfalls nicht auf alle dort genannten Beispiele anwendbar ist. Ansonsten ist die Übermittlung und Nutzung dieser Daten im Normalfall 21 nur aufgrund einer Rechtsvorschrift oder mit Einwilligung des Betroffenen, also des Nutzers, zulässig. 22 Mangels entsprechender Rechtsvorschriften für alle abzudeckenden Dienste und Anbieter und im Interesse einer hohen Nutzerakzeptanz erscheint es daher sinnvoll und geboten, dass der Identitätsmanager generell die Einwilligung des Nutzers in die Datenweitergabe einholt, auch wenn dies für Einzelfälle rechtlich nicht zwingend erforderlich sein sollte. Auf welchem Wege die Daten anderer Personen, also der Nicht-Studenten, in die MoUSe gelangen, ist aus der Spezifikation der MoUSe [10] nicht klar ersichtlich. Jedenfalls ist auch hier davon auszugehen, dass eine Weitergabe, wenn überhaupt, jeweils nur bei Einwilligung der betroffenen Person in Betracht kommt. 20 in Verbindung mit 2 Abs. 4 der Benutzungsordnung des Universitätsrechenzentrums der Technischen Universität Chemnitz [47] 21 Ausnahmen, wie zum Beispiel die Gefährdung der öffentlichen Sicherheit, sollen hier nicht näher betrachtet werden. 22 vgl. 106 Abs. 2 SächsHG 8

15 3.1.3 Form der Einwilligung 3.1 Datenschutzrechtliche Erwägungen Ein wichtiger Punkt ist die Frage, ob die Einwilligung zu ihrer Wirksamkeit der Schriftform bedarf, oder ob auch eine Zustimmung in elektronischer Form ausreichend ist. In 106 SächsHG finden sich dazu keine Angaben. Nach BDSG und SächsDSG bedarf die Einwilligung der Schriftform, soweit nicht wegen besonderer Umstände eine andere Form angemessen ist 23. Ob eine Einwilligung über das Internet als besonderer Umstand anzusehen ist, ist umstritten. [4, Seite 13] Das SächsDSG erwähnt 24 die elektronische Form explizit in Verbindung mit einer qualifizierten elektronischen Signatur, ein für den Identitätsmanager untaugliches Verfahren. Diese Arbeit geht im Folgenden davon aus, dass eine einfache elektronische Einwilligung ausreichend ist, sofern sie bestimmten Grundsätzen genügt (siehe unten) und sich der Nutzer geeignet 25 authentifiziert. Bei Annahme einer gegenteiligen Auffassung wäre ein der Einleitung entsprechender Identitätsmanager nicht sinnvoll betreibbar, da der dann damit erforderliche Zusatzaufwand in keinem Verhältnis zum Nutzen mehr stehen würde. Als Anhaltspunkt für Anforderungen an die einfache elektronische Einwilligung kann, auch wenn es hier nicht direkt anwendbar ist, das TDDSG dienen 26 : Sie muss durch eine eindeutige und bewusste Handlung des Nutzers erfolgen. Sie muss protokolliert werden. Der Nutzer muss den Inhalt der Einwilligung jederzeit abrufen können. Auf das Recht auf jederzeitigen Widerruf mit Wirkung für die Zukunft ist hinzuweisen Anforderungen an die Datenübermittlung Insoweit die Übermittlung personenbezogener Daten zulässig ist, hat sie so zu erfolgen, dass die Daten nicht unbefugt gelesen, kopiert, verändert oder 23 vgl. 4a Abs. 1 BDSG und 4 Abs. 4 SächsDSG 24 4 Abs. 5 SächsDSG 25 etwa per URZ-Nutzerkennzeichen und Zugangs- bzw. AFS-Passwort 26 3 Abs. 3 TDDSG in Verbindung mit 4 Abs. 2 und 3 TDDSG 9

16 3 Anforderungen an den Identitätsmanager entfernt werden können Möglichkeit der anonymen und pseudonymen Nutzung In die neuere Gesetzgebung eingeflossen ist das Ziel, personenbezogene Daten möglichst sparsam zu erheben und zu verarbeiten. 28 Soweit es angemessen und technisch möglich ist, ist auch eine anonyme oder pseudonyme Nutzung vorzusehen. 29 Vor allem geht es dabei auch darum, das Mitführen der vollen Identität der Betroffenen während der eigentlichen Datenverarbeitungsvorgänge zu reduzieren. [4, Seite 11] In erster Linie ist es natürlich Aufgabe und Verantwortungsbereich der Anbieter ggf. entsprechende Verfahren einzusetzen. Der Identitätsmanager könnte diese Zielstellung jedoch unterstützen, indem er bei Bedarf ermöglicht, dass nur einzelne Attribute über einen Nutzer, ohne Preisgabe seiner Identität 30, zur Verfügung gestellt werden. 3.2 Technische Anforderungen Neben den Anforderungen, die sich bereits aus datenschutzrechtlichen Erwägungen ergeben, existieren zusätzliche Anforderungen, die hinsichtlich des Identitätsmanagers beachtet werden sollten, auch in technischer Hinsicht. Verfügbarkeit: Der Identitätsmanager muss ausreichend stabil sein. Sicherlich ist es wünschenswert, dass der Identitätsmanager immer verfügbar ist und korrekt funktioniert. Es dürfte in der Praxis jedoch ausreichend sein, wenn seine Ausfallzeiten im Rahmen der üblichen Ausfallzeiten der anderen kritischen Dienste des Universitätsrechenzentrums liegen. 27 vgl. Anlage zu 9 Satz 1 BDSG (BGBl. I 2003, S.88), sinngemäß auch 9 Abs. 2 SächsDSG 28 vgl. 3a BDSG 29 vgl. 3a BDSG und 4 Abs. 6 TDDSG 30 der konkreten Person 10

17 3.2 Technische Anforderungen Geschwindigkeit: Anfragen an den Identitätsmanager sollten möglichst schnell beantwortet werden. Jedenfalls darf die Zusammenarbeit mit dem Identitätsmanager nicht zu übermäßigen 31 Verzögerungen bei der Nutzung der Dienste der Anbieter führen. Wartbarkeit: Der sich durch den Betrieb des Identitätsmanagers unweigerlich ergebende Zusatzaufwand für das Universitätsrechenzentrum sollte möglichst gering sein. Dies erfordert automatisierte Verfahren. 32 Offenheit und Anpassungsfähigkeit: Aufgrund des Umgangs mit personenbezogenen Daten und der sicherheitskritischen Rolle des Identitätsmanagers erscheint die Verfügbarkeit der Implementierung auch im Quellcode, schon zur Prüfung auf mögliche Sicherheitslücken, unabdingbar. Eigene Anpassungen sollten zudem lizenzrechtlich möglich sein, um sich nicht in zu starke Abhängigkeit zu einem etwaigen Hersteller zu begeben. Gleiches gilt hinsichtlich der Verwendung von offenen Protokollen. Komplexität: Eine geringe Komplexität des Identitätsmanagers erscheint anstrebenswert. Komplexe Systeme neigen im Betrieb zu Fehlfunktionen. Mögliche Fehlerquellen können im Vorfeld schwieriger erkannt werden, die Lokalisierung und Behebung von auftretenden Fehlern gestaltet sich aufwändiger. erforderliches Betriebssystem: Bei dem Identitätsmanager handelt es sich offensichtlich um einen sicherheitskritischen Dienst. Daher bedarf auch das zugrunde liegende Betriebssystem einer ständigen Wartung, insbesondere hinsichtlich neu entdeckter und zu beseitigender Sicherheitslücken. Das Universitätsrechenzentrum betreibt derzeit alle kritischen Netzdienste auf der Basis von Linux. 33 Ein zukünftiger Identitätsmanager sollte daher ebenfalls unter Linux, möglichst unabhängig von einer konkreten Distribution, betreibbar sein. Dadurch kann zusätzlicher Administrationsaufwand, der durch den Einsatz eines speziellen 31 mehr als wenige Sekunden 32 auf eine nähere Definition wird verzichtet 33 vgl. 11

18 3 Anforderungen an den Identitätsmanager Betriebssystems nur für den Identitätsmanager entstehen würde, vermieden werden. Kosten: Die durch den Betrieb des Identitätsmanagers anfallenden Kosten sollten möglichst gering sein. Offensichtlich ist der Einsatz gewisser zusätzlicher Hardware-Ressourcen notwendig. Hinsichtlich der Software, also dem eigentlichen Identitätsmanager, verursachen unentgeltlich zur Verfügung gestellte Lösungen keine direkten Kosten. Jedoch scheiden trotzdem kommerzielle Lösungen nicht von vornherein aus. Diese könnten sich im Betrieb, zum Beispiel aufgrund besserer Wartbarkeit, letztendlich als günstiger erweisen. Eigenentwicklungen bedeuten zusätzlichen Aufwand, der sich in zusätzlichen Kosten niederschlägt. Unvergütet durchgeführte Studien- und Diplomarbeiten liefern allenfalls Realisierungsansätze, jedoch gewöhnlich keine Systeme für den sofortigen Produktionseinsatz. Zukunftssicherheit: Der Identitätsmanager sollte zukunftssicher sein. Dies betrifft vor allem die Fragen, wie die Zusammenarbeit mit zukünftigen Betriebssystemen und Anwendungen gewährleistet werden kann, welche Modifikationen dafür voraussichtlich erforderlich sind, welchen Umfang diese haben und vor allem, wer diese durchführt. Eigenentwicklungen und wenig verbreitete Lösungen sind hier wahrscheinlich im Nachteil gegenüber Standardlösungen. Anforderungen auf Nutzerseite: Der Identitätsmanager sollte auf Nutzerseite möglichst geringe Erwartungen hinsichtlich der benötigten Software stellen, insbesondere auch hinsichtlich der Features des eingesetzten Webbrowsers, wobei aber typischerweise zur Verfügung stehende Möglichkeiten 34 als zusätzliche Anforderungen hingenommen werden können. Dagegen ist die Installation zusätzlicher Software schon mangels kaum erreichbarer, breiter Portabilität abzulehnen. 34 etwa Cookies, Java-Script, Java 12

19 4 Technische Grundlagen In nächsten Kapitel werden einige bereits existierende Systeme untersucht. Alle haben ähnliche technische Probleme zu bewältigen, dies betrifft insbesondere die Kommunikation zwischen Nutzer, Anbieter und Identitätsmanager und die Sicherung der Vertraulichkeit und Integrität der Kommunikation. Dabei fällt auf, dass diese Systeme in ihrer Realisierung zum Teil ähnliche Lösungen verwenden, welche in diesem Kapitel vorab betrachtet werden. 4.1 Kommunikation zwischen Nutzer, Anbieter und Identitätsmanager Die Nutzung eines Dienstes eines Anbieters durch einen Nutzer beginnt im Sinne dieser Arbeit typischerweise damit, dass der Nutzer mit seinem WWW-Browser eine zum Dienst des Anbieters gehörende WWW-Seite aufruft. Dabei kommt das Hyper Text Transfer Protocol (HTTP) [7] zum Einsatz. Im Folgenden wird davon ausgegangen, dass dieses, wie im Internet üblich, auf TCP/IP aufsetzt. Begonnen wird mit einer HTTP- GET - Anforderung vom Nutzer an den Anbieter. Der Anbieter benötigt nun weitere Daten über den Nutzer, die er mittels des Identitätsmanagers ermitteln möchte. Vom Nutzer ist ihm nur die derzeitige IP und der Port bekannt, auf dem die Antwort auf die GET -Anforderung erwartet wird. Zur Vereinfachung sei angenommen, dass sich hinter dieser IP, über den Zeitraum des hier beschriebenen Ablaufs, nur genau dieser eine Nutzer befindet. 35 Jedenfalls dann ist der Port für Dritte ohne Bedeutung, 35 Durch die zusätzliche Übertragung geeigneter Kennungen und Schlüssel zwischen den Beteiligten wären auch mehrere Nutzer pro IP möglich, ebenso wie möglicherweise sichergestellt werden könnte, dass sich der Nutzer zwischenzeitlich nicht ändert. 13

20 4 Technische Grundlagen da er zur TCP-Verbindung zwischen Nutzer und Anbieter gehört. Der Anbieter könnte nun direkt mit dem Identitätsmanager kommunizieren 36 und ihm die IP des Nutzers mitteilen, mit dem Wunsch, Daten über diesen Nutzer zu erhalten. Damit der Identitätsmanager Daten über den Nutzer liefern kann, muss er zunächst selbst feststellen, um welchen konkreten Nutzer es sich handelt, der Nutzer muss sich also auf irgendeine Weise gegenüber dem Identitätsmanager authentifizieren. Dazu ist Kommunikation zwischen Nutzer und Identitätsmanager erforderlich. Der Identitätsmanager würde nun zwar die vom Anbieter erhaltene IP des Nutzers kennen und könnte damit theoretisch eine Kommunikationsverbindung zum Nutzer aufbauen. Dann wäre aber auf Seiten des Nutzers spezielle Software nötig, die solche Anfragen eines Identitätsmanagers auf einem vorher bekannten Port entgegennimmt und verarbeitet. Etwaige Firewalls zwischen Identitätsmanager und Nutzer müssten zudem so konfiguriert sein, dass ein Aufbau solcher Verbindungen vom Identitätsmanager zum Nutzer möglich ist (Abbildung 4.1). Wird nutzerseitig NAT eingesetzt, treten offensichtlich weitere, nichttriviale Probleme auf. Nutzer (WWW-Browser) Bearbeitung? 1. GET Anbieter (Dienst) Firewall Durchleitung? 3. Wer bist du? 2. Liefere mir Daten über Nutzer... (Nutzer-IP) (bekannter Port) Identitätsmanager Abbildung 4.1: einfacher Kommunikationsansatz 36 Das Protokoll sei an dieser Stelle offen gelassen. 14

21 4.1 Kommunikation zwischen Nutzer, Anbieter und Identitätsmanager Man wählt daher einen anderen Weg (Abbildung 4.2). Statt direkt eine Verbindung zwischen Anbieter und Identitätsmanager aufzubauen, nutzt man die bereits bestehende Verbindung zwischen Nutzer und Anbieter, indem man als Antwort auf die GET -Anforderung des Nutzers (1.) einen Redirect 37 auf den Identitätsmanager zurückschickt, der Anbieter wird dabei geeignet kodiert mit übergeben (2.). Aufgrund dieses Redirect baut nun der Nutzer selbst eine Verbindung zum Identitätsmanager auf, indem er diesem jetzt eine GET -Anforderung schickt (3.). Nun kann über einen Zwischenschritt 38 die Authentifizierung abgewickelt werden (4.). Danach erfolgt analog, mittels eines weiteren Redirect, die Übergabe von Daten über den Nutzer vom Identitätsmanager an den Anbieter, entweder direkt oder in Form eines so genannten Ticket, das vom Anbieter beim Identitätsmanager eingereicht werden kann, um Nutzerdaten abzufragen (5. und 6.). Nutzer (WWW-Browser) 3. GET 1. GET 2. Redirect 6. GET plus Daten vom Identitätsmanager Anbieter (Dienst) 4. Authentifizierung 5. Redirect Identitätsmanager Abbildung 4.2: verbesserter Kommunikationsansatz 37 Um-/Weiterleitung auf ein neues Ziel 38 Zum Beispiel könnte der Identitätsmanager als Antwort eine HTML-Seite mit einem HTML-Formular zurückschicken, welches der Nutzer mit Nutzerkennzeichen und Passwort auszufüllen hat, und danach zurück an den Identitätsmanager sendet. 15

22 4 Technische Grundlagen Zur technischen Realisierung der Redirects sind verschiedene Möglichkeiten gebräuchlich 39 : HTTP-Redirect: Bei Einsatz des HTTP-Redirect wird die ursprüngliche GET -Anforderung mit einer HTTP-Antwort mit dem Statuscode 302 ( Found ) [7, Abschnitt ] beantwortet, das gewünschte Ziel wird dabei als Location -URI gesetzt, weitere Daten können als Parameter angehängt werden. Der Browser des Nutzers reagiert auf eine solche Antwort normalerweise automatisch mit einer entsprechenden Anfrage an das neue Ziel. FORM-Redirect: Hier wird mittels einer normalen HTTP-Antwort, also Statuscode 200 ( OK ) [7, Abschnitt ], ein gewöhnliches HTML-Dokument ausgeliefert, welches ein HTML-Formular [25, Abschnitt 17.3] enthält. Daten können dabei innerhalb der Formularfelder übergeben werden, geschieht dies mittels INPUT -Elementen vom Typ hidden [25, Abschnitt 17.4] können diese Daten in der normalen Browserdarstellung vor dem Nutzer verborgen werden. Damit wird der Nutzer nicht durch ungewöhnliche Ausgaben irritiert. Die eigentliche Weiterleitung erfolgt über in das HTML-Dokument eingebettete Skriptbefehle, etwa per Java-Script. Werden diese vom Browser des Nutzers nicht unterstützt, so muss der Nutzer das Versenden des Formulars manuell auslösen. SCRIPT-Redirect: Auch hier wird ein gewöhnliches HTML-Dokument zurückgeliefert, wobei aber auf die Einbettung eines Formulars verzichtet wird. Stattdessen wird wieder über Scriptbefehle eine Weiterleitung veranlasst, wobei Daten direkt als Parameter der Ziel-URL übergeben werden können. Diese URL, einschließlich ihrer Parameter, sollte in einem <noscript> -Bereich [25, Abschnitt ] wiederholt werden, damit der Nutzer die URL manuell aufrufen kann, falls sein Browser die Scriptbefehle nicht unterstützt. 39 Die Benennung ist willkürlich gewählt, allein mit dem Zweck einer kurzen sprachlichen Unterscheidungsmöglichkeit im Rahmen dieser Arbeit. 16

23 4.2 Sicherheit der Kommunikation Nach Abschluss dieser initialen Kommunikationsschritte kennt also der Anbieter bereits die gewünschten Nutzerdaten oder ihm steht ein Ticket zur Verfügung, anhand dessen er diese beim Identitätsmanager abfragen kann. Insbesondere ist der Identitätsmanager in der Lage, anhand des Tickets auf den konkreten Nutzer zu schließen. Weitere Kommunikation zwischen Anbieter und Identitätsmanager bedarf daher nicht mehr dem Umweg über den Nutzer, sie kann auch direkt stattfinden. 4.2 Sicherheit der Kommunikation Um die Zuverlässigkeit des Gesamtsystems zu gewährleisten, ist es notwendig, es gegen Angriffe zu schützen, insbesondere muss dazu die Integrität und Vertraulichkeit der Kommunikation sichergestellt werden. Dies dient im Fall der Übermittlung von Nutzerdaten zudem datenschutzrechtlichen Zielen, vgl. Abschnitt Die Sicherung der Kommunikationsverbindungen erfolgt gewöhnlich mittels Secure Socket Layer (SSL) [24] bzw. der Weiterentwicklung Transport Layer Security (TLS) [3]. Vor allem in Kombination mit dem HTTP- Protokoll sind diese Verfahren weit verbreitet (HTTPS). Vertrauliche Kommunikation wird durch den Einsatz von symmetrischer Verschlüsselung erreicht. Das Verschlüsselungsverfahren und die Schlüssellänge wird von den beiden Beteiligten im Zuge des Aufbaus der Kommunikationsverbindung ausgehandelt, der eigentliche Schlüssel wird über ein übliches Schlüsselaustauschverfahren, in der Regel RSA key exchange, gewonnen. Dazu authentifiziert sich mindestens der Server (das Ziel der Verbindung) gegenüber dem Klient (der Initiator der Verbindung) unter Verwendung von Zertifikaten. Die Integrität der Kommunikation wird auf der Basis von schlüsselabhängigen Einweg-Hashfunktionen (Message Authentication Codes) gewährleistet. Veränderungen durch Dritte können so leicht erkannt werden. [31] Zu beachten ist, dass mittels SSL/TLS nur Punkt-zu-Punkt-Verbindung geschützt sind. Insbesondere könnte der Nutzer Daten, welche mittels Redirect zwischen Anbieter und Identitätsmanager über ihn weitergeleitet werden, einsehen und unbemerkt verändern. Damit verbundene Probleme lassen sich bei Bedarf durch den Einsatz von zusätzlicher Verschlüsselung, Signaturen, Einmalcodes, etc. auf höherer Ebene vermeiden. 17

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter

Technische Universität München. SAML/Shibboleth. Ein Vortrag von Florian Mutter SAML/Shibboleth Ein Vortrag von Florian Mutter Security Assertion Markup Language XML-basierter Standard für den Austausch von Authentifizierungs-, Attributs- Berechtigungsinformationen Seit 2001 von OASIS

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

Anlage 3 Verfahrensbeschreibung

Anlage 3 Verfahrensbeschreibung Anlage 3 Verfahrensbeschreibung Stand September 2015 1 INHALTSVERZEICHNIS 1 EINLEITUNG... 2 2 SYSTEMVORAUSSETZUNGEN... 3 2.1 Technische Voraussetzung beim Kunden... 3 2.2 Ausstattung des Clients... 3 3

Mehr

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language.

Inhalt Einführung Was ist SAML Wozu braucht man SAML Wo wird SAML verwendet kleine Demo SAML. Security Assertion Markup Language. Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo Security Assertion Markup Language Björn Rathjens Inhalt Einführung Was ist Wozu braucht man Wo wird verwendet kleine Demo 1 Einführung

Mehr

Daten, die Sie uns geben (Geschäftsbeziehung, Anfragen, Nutzung eine unsere Dienstleistungen)

Daten, die Sie uns geben (Geschäftsbeziehung, Anfragen, Nutzung eine unsere Dienstleistungen) Datenschutzerklärung der Etacs GmbH Die Etacs GmbH wird den Anforderungen des Bundesdatenschutzgesetzes (BDSG) gerecht.personenbezogene Daten, d.h Angaben, mittels derer eine natürliche Person unmittelbar

Mehr

Schwachstellenanalyse 2013

Schwachstellenanalyse 2013 Schwachstellenanalyse 2013 Sicherheitslücken und Schwachstellen in Onlineshops Andre C. Faßbender Schwachstellenforschung Faßbender 09.01.2014 Inhaltsverzeichnis 1. Abstract... 3 2. Konfiguration der getesteten

Mehr

Datenschutzbestimmungen der MUH GmbH

Datenschutzbestimmungen der MUH GmbH Datenschutzerklärung MUH Seite 1 Datenschutzbestimmungen der MUH GmbH Stand: 20.06.2012 1. Unsere Privatsphäre Grundsätze 1.1 Bei der MUH nehmen wir den Schutz Ihrer persönlichen Daten sehr ernst und halten

Mehr

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken In diesem Tutorial zeigen wir Ihnen, wie Sie im Mozilla Thunderbird E-Mailclient ein POP3-Konto einrichten. Wir haben bei der Erstellung des Tutorials die Version 2.0.0.6 verwendet. Schritt 1: Auswahl

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

estos XMPP Proxy 5.1.30.33611

estos XMPP Proxy 5.1.30.33611 estos XMPP Proxy 5.1.30.33611 1 Willkommen zum estos XMPP Proxy... 4 1.1 WAN Einstellungen... 4 1.2 LAN Einstellungen... 5 1.3 Konfiguration des Zertifikats... 6 1.4 Diagnose... 6 1.5 Proxy Dienst... 7

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

Mehr

Federated Identity Management

Federated Identity Management Federated Identity Management Verwendung von SAML, Liberty und XACML in einem Inter Campus Szenario d.marinescu@gmx.de 1 Fachbereich Informatik Inhalt Grundlagen Analyse Design Implementierung Demo Zusammenfassung

Mehr

Datenschutzerklärung von SL-Software

Datenschutzerklärung von SL-Software Datenschutzerklärung von SL-Software Software und Büroservice Christine Schremmer, Inhaberin Christine Schremmer, Odenwaldring 13, 63500 Seligenstadt (nachfolgend SL-Software bzw. Wir genannt) ist als

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 7: Web Services IV Exkurs über Sicherheitsanforderungen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha

Mehr

Datenschutzerklärung für RENA Internet-Auftritt

Datenschutzerklärung für RENA Internet-Auftritt Datenschutzerklärung für RENA Internet-Auftritt Vielen Dank für Ihr Interesse an unserem Internetauftritt und unserem Unternehmen. Wir legen großen Wert auf den Schutz Ihrer Daten und die Wahrung Ihrer

Mehr

Secure Socket Layer (SSL) - Zertifikate

Secure Socket Layer (SSL) - Zertifikate e Einführung Zur Übertragung sensibler Daten über das Internet wurde das SSL-Protokoll entwickelt. SSL steht für Secure Socket Layer (dt. "sichere Sockelschicht") das von der Firma Netscape und RSA Data

Mehr

Ein technischer Überblick

Ein technischer Überblick Wie funktioniert Shibboleth? Ein technischer Überblick 3. AAR-Workshop Freiburg, 10. Oktober 2006 Franck Borel, UB Freiburg E-Mail: borel@ub.uni-freiburg.de Übersicht Was ist Shibboleth? Warum Shibboleth?

Mehr

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de

Grundlagen. AAI, Web-SSO, Metadaten und Föderationen. Wolfgang Pempe, DFN-Verein pempe@dfn.de Grundlagen AAI, Web-SSO, Metadaten und Föderationen Wolfgang Pempe, DFN-Verein pempe@dfn.de DFN-AAI IdP-Workshop, 24./25. Juni 2015, HS Amberg-Weiden Was ist DFN-AAI? AAI Authentifizierung Autorisierung

Mehr

Authentication im Web

Authentication im Web Authentication im Web Weiterführende Themen zu Internet- und WWW-Technologien 11.07.2011, Kai Fabian Inhalt 2 1. Begriffsabgrenzung 2. HTTP Basic Authentication (RFC 2617) 3. Single Sign-on-Techniken 3.1.

Mehr

V 1.3. Stand: 15.09.2014

V 1.3. Stand: 15.09.2014 Datenschutz der V 1.3 Stand: 15.09.2014 Seite 1 von 5 Datenschutz der Präambel Personal-Planer.de verpflichtet sich, Ihre Privatsphäre und Ihre persönlichen Daten zu schützen. Ihre personenbezogenen Daten

Mehr

Installation des Zertifikats am Beispiel eines Exchange-Mail-Servers. Voraussetzungen. Zertifikate importieren. Outlook-Webaccess

Installation des Zertifikats am Beispiel eines Exchange-Mail-Servers. Voraussetzungen. Zertifikate importieren. Outlook-Webaccess HS-Anhalt (FH) Fachbereich EMW Seite 1 von 6 Stand 04.02.2008 Installation des Zertifikats am Beispiel eines Exchange-Mail-Servers Bedingt durch die verschiedenen Transportprotokolle und Zugriffsmethoden

Mehr

Nutzerbeirat 2012 Bonn 20.11.2012

Nutzerbeirat 2012 Bonn 20.11.2012 Der neue Personalausweis Einsatzmöglichkeiten in der Lucom Interaction Platform Nutzerbeirat 2012 Bonn 20.11.2012 Henning Meinhardt Leiter Software Entwicklung Ab Version 3.2.2 unterstützt die LIP den

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST 2. Interaktive Web Seiten GET und POST Die Übertragungsmethoden GET und POST sind im http Protokoll definiert: POST: gibt an, dass sich weitere Daten im Körper der übertragenen Nachricht befinden: z.b.

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

Babelprojekt.com Datenschutzhinweise

Babelprojekt.com Datenschutzhinweise Babelprojekt.com Datenschutzhinweise Datenschutzrichtlinie runterladen Letzte Aktualisierung: 24. Apr. 2015 Willkommen zur Webseite des Babelprojekt Kft. Babelprojekt bittet Sie darum, vor der Nutzung

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Identity Management. Nutzen Konzepte Standards. Dr. Oliver Stiemerling

Identity Management. Nutzen Konzepte Standards. Dr. Oliver Stiemerling Identity Management Nutzen Konzepte Standards Dr. Oliver Stiemerling ecambria systems GmbH Hospeltstr. 35a 50825 Köln Tel.: 0221 595527-0 Fax.: 0221 595527-5 os@ecambria-systems.com http://www.ecambria-systems.com

Mehr

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht

Mehr

Datenschutzerklärung. 1. Allgemeine Hinweise

Datenschutzerklärung. 1. Allgemeine Hinweise Datenschutzerklärung Wir freuen uns über Ihr Interesse an unserem Online-Angebot. Der Schutz Ihrer Privatsphäre ist für uns sehr wichtig. Wir legen großen Wert auf den Schutz Ihrer personenbezogenen Daten

Mehr

Datenschutzerklärung Ihre Daten sind bei uns sicher

Datenschutzerklärung Ihre Daten sind bei uns sicher Datenschutzerklärung für die Angebote des GSI SLV- Fachkräftezentrums Datenschutzerklärung Ihre Daten sind bei uns sicher Datenschutz ist Vertrauenssache und Ihr Vertrauen ist uns wichtig. Wir respektieren

Mehr

Sichere Abwicklung von Geschäftsvorgängen im Internet

Sichere Abwicklung von Geschäftsvorgängen im Internet Sichere Abwicklung von Geschäftsvorgängen im Internet Diplomarbeit von Peter Hild Theoretische Grundlagen der Kryptologie Vorhandene Sicherheitskonzepte für das WWW Bewertung dieser Konzepte Simulation

Mehr

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler

Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Secure Sockets Layer (SSL) Prof. Dr. P. Trommler Übersicht Internetsicherheit Protokoll Sitzungen Schlüssel und Algorithmen vereinbaren Exportversionen Public Keys Protokollnachrichten 29.10.2003 Prof.

Mehr

Secure Mail. Leitfaden für Kunden & Partner der Libera AG. Zürich, 11. November 2013

Secure Mail. Leitfaden für Kunden & Partner der Libera AG. Zürich, 11. November 2013 Secure Mail Leitfaden für Kunden & Partner der Libera AG Zürich, 11. November 2013 Aeschengraben 10 Postfach CH-4010 Basel Telefon +41 61 205 74 00 Telefax +41 61 205 74 99 Stockerstrasse 34 Postfach CH-8022

Mehr

MSXFORUM - Exchange Server 2003 > SSL Aktivierung für OWA 2003

MSXFORUM - Exchange Server 2003 > SSL Aktivierung für OWA 2003 Page 1 of 23 SSL Aktivierung für OWA 2003 Kategorie : Exchange Server 2003 Veröffentlicht von webmaster am 20.05.2005 Die Aktivierung von SSL, für Outlook Web Access 2003 (OWA), kann mit einem selbst ausgestellten

Mehr

Neuerungen bei Shibboleth 2

Neuerungen bei Shibboleth 2 Neuerungen bei Shibboleth 2 Shibboleth-Workshop BW Stuttgart, 7. Februar 2008 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht Aktueller Status Kommunikation IdP

Mehr

SSL/TLS und SSL-Zertifikate

SSL/TLS und SSL-Zertifikate SSL/TLS und SSL-Zertifikate Konzepte von Betriebssystem-Komponenten Informatik Lehrstuhl 4 16.06.10 KvBK Wolfgang Hüttenhofer sethur_blackcoat@web.de Motivation Sichere, verschlüsselte End-to-End Verbindung

Mehr

Muster für ein Impressum und eine Datenschutzerkläi'uyy nw \ni(tviivkpoiicm z/tzhilhamv UzhAm.hjn In Uayuti

Muster für ein Impressum und eine Datenschutzerkläi'uyy nw \ni(tviivkpoiicm z/tzhilhamv UzhAm.hjn In Uayuti Muster für ein Impressum und eine Datenschutzerkläi'uyy nw \ni(tviivkpoiicm z/tzhilhamv UzhAm.hjn In Uayuti liopii'eßöyrri Herausgeber Name, Hausanschrift und Postanschrift der Behörde (vollständige ladungsfähige

Mehr

Aufsetzen Ihres HIN Abos

Aufsetzen Ihres HIN Abos Aufsetzen Ihres HIN Abos HIN Health Info Net AG Pflanzschulstrasse 3 8400 Winterthur Support 0848 830 740 Fax 052 235 02 72 support@hin.ch www.hin.ch HIN Health Info Net AG Grand-Rue 38 2034 Peseux Support

Mehr

Information über die Secure E-Mail

Information über die Secure E-Mail Information über die Secure E-Mail Ihre Möglichkeiten Der Austausch von verschlüsselten E-Mails kann auf 3 Arten erfolgen 1. über das Webmail-Portal: Direkt empfangen und senden Sie vertrauliche Informationen

Mehr

Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur

Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur Abschlussvortrag zur Diplomarbeit Aufbau und Analyse einer Shibboleth/GridShib-Infrastruktur Stefan Marienfeld Fachgebiet Distributed Virtual Reality (DVR) Lehrgebiet Rechnernetze Stefan Marienfeld Gliederung

Mehr

Konfigurieren eines Webservers

Konfigurieren eines Webservers Unterrichtseinheit 12: Konfigurieren eines Webservers Erleichterung der Organisation und des Verwaltens von Webinhalten im Intranet und Internet. Übersicht über IIS: Der IIS-Dienst arbeitet mit folgenden

Mehr

Organisationsübergreifendes Single Sign On mit shibboleth. Tobias Marquart Universität Basel

Organisationsübergreifendes Single Sign On mit shibboleth. Tobias Marquart Universität Basel Organisationsübergreifendes Single Sign On mit shibboleth Tobias Marquart Universität Basel Überblick Einordnung von Shibboleth, Abgrenzung zu OpenID Organisatorische und technische Komponenten einer Federation

Mehr

Identity and Access Management for Complex Research Data Workflows

Identity and Access Management for Complex Research Data Workflows Identity and Access Management for Complex Research Data Workflows Richard Zahoransky, Saher Semaan, Klaus Rechert richard.zahoransky@rz.uni-freiburg.de, semaan@uni-freiburg.de, klaus.rechert@rz.uni-freiburg.de

Mehr

Datenschutzerklärung. Datum: 16.12.2014. Version: 1.1. Datum: 16.12.2014. Version: 1.1

Datenschutzerklärung. Datum: 16.12.2014. Version: 1.1. Datum: 16.12.2014. Version: 1.1 Datenschutzerklärung Datum: 16.12.2014 Version: 1.1 Datum: 16.12.2014 Version: 1.1 Verantwortliche Stelle im Sinne des Bundesdatenschutzgesetzes ist: Deutsch-Iranische Krebshilfe e. V. Frankfurter Ring

Mehr

Kurzeinführung VPN. Veranstaltung. Rechnernetze II

Kurzeinführung VPN. Veranstaltung. Rechnernetze II Kurzeinführung VPN Veranstaltung Rechnernetze II Übersicht Was bedeutet VPN? VPN Typen VPN Anforderungen Was sind VPNs? Virtuelles Privates Netzwerk Mehrere entfernte lokale Netzwerke werden wie ein zusammenhängendes

Mehr

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse

SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Fakultät Informatik Institut für Systemarchitektur Professur für Rechnernetze SNMP 1 -basierte dynamische Netzwerkkonfiguration und analyse Versuchsvorgaben (Aufgabenstellung) Der neu zu gestaltende Versuch

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

Internet Datasafe Sicherheitstechnische Herausforderungen

Internet Datasafe Sicherheitstechnische Herausforderungen ERFA-Tagung 14.9.2010 Internet Datasafe Sicherheitstechnische Herausforderungen Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte Wissenschaften

Mehr

Enterprise Web-SSO mit CAS und OpenSSO

Enterprise Web-SSO mit CAS und OpenSSO Enterprise Web-SSO mit CAS und OpenSSO Agenda Gründe für SSO Web-SSO selbst gemacht Enterprise Web-SSO mit CAS Enterprise Web-SSO mit SUN OpenSSO Federation-Management Zusammenfassung Gründe für SSO Logins

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Sichere E-Mail-Kommunikation mit fat

Sichere E-Mail-Kommunikation mit fat Sichere E-Mail-Kommunikation mit fat Inhalt Über das Verfahren... 1 Eine sichere E-Mail lesen... 2 Eine sichere E-Mail auf Ihrem PC abspeichern... 8 Eine sichere Antwort-E-Mail verschicken... 8 Einem fat-mitarbeiter

Mehr

Das Kerberos-Protokoll

Das Kerberos-Protokoll Konzepte von Betriebssystemkomponenten Schwerpunkt Authentifizierung Das Kerberos-Protokoll Referent: Guido Söldner Überblick über Kerberos Network Authentication Protocol Am MIT Mitte der 80er Jahre entwickelt

Mehr

Datenschutzbestimmungen

Datenschutzbestimmungen Datenschutzbestimmungen mein-pulsschlag.de Stand 22. April 2015 Version 1.1 Inhaltsverzeichnis 1. Die Identität der verantwortlichen Stelle...3 2. Unsere Grundprinzipien der Verarbeitung Ihrer personenbezogenen

Mehr

Single Sign-On Step 1

Single Sign-On Step 1 Single Sign-On Step 1 Novell Tour 2006 Stefan Stiehl Senior Technology Specialist sstiehl@novell.com Holger Dopp Senior Consultant hdopp@novell.com Was ist Single Sign-On? Eine Befugnisverwaltungstechnologie,

Mehr

Microsoft ISA Server 2006

Microsoft ISA Server 2006 Microsoft ISA Server 2006 Leitfaden für Installation, Einrichtung und Wartung ISBN 3-446-40963-7 Leseprobe Weitere Informationen oder Bestellungen unter http://www.hanser.de/3-446-40963-7 sowie im Buchhandel

Mehr

Web-Single-Sign-On in der LUH

Web-Single-Sign-On in der LUH Web-Single-Sign-On in der LUH Begriffsklärung Technischer Ablauf Umsetzung an der LUH Vor- und Nachteile Sascha Klopp Begriffsklärung Single Sign-on: Benutzer meldet sich zu Beginn seiner Sitzung an und

Mehr

S Kreis- und Stadtsparkasse

S Kreis- und Stadtsparkasse S Kreis- und Stadtsparkasse Kaufbeuren im September 2011 Informationen zum sicheren E-Mailverkehr Mit diesem Schreiben wollen wir Ihnen Inhalt: 1. die Gründe für die Einführung von Sichere E-Mail näher

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo.

Virtuelle Netze. Virtuelle Netze von Simon Knierim und Benjamin Skirlo 1 Von 10-16.04.07. Simon Knierim & Benjamin Skirlo. 1 Von 10-16.04.07 Virtuelle Netze Simon Knierim & Benjamin Skirlo für Herrn Herrman Schulzentrum Bremen Vegesack Berufliche Schulen für Metall- und Elektrotechnik 2 Von 10-16.04.07 Inhaltsverzeichnis Allgemeines...

Mehr

Gefahren aus dem Internet 6 Aktive Angriffe April 2010

Gefahren aus dem Internet 6 Aktive Angriffe April 2010 6 Aktive Angriffe Lernziele Sie können grob erklären, wie ein Angreifer in Ihren Computer eindringen kann. Sie können herausfinden, welche Ports auf Ihrem Computer offen sind. Sie wissen, warum der Einsatz

Mehr

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/ Einführung Was ist Unison? Unison ist ein Dateisynchronisationsprogramm für Windows und Unix. Es teilt sich viele Funktionen mit anderen Programmen, wie z.b. CVS und rsync. Folgend einige Vorteile des

Mehr

IntelliShare E-Mail-Verschlüsselung. IntelliShare - Anwenderhandbuch. Inhalt. Sicherheit. Echtheit. Vertraulichkeit.

IntelliShare E-Mail-Verschlüsselung. IntelliShare - Anwenderhandbuch. Inhalt. Sicherheit. Echtheit. Vertraulichkeit. IntelliShare E-Mail-Verschlüsselung IntelliShare - Anwenderhandbuch Sicherheit. Echtheit. Vertraulichkeit. Inhalt Vorwort... 2 Soe versenden Sie Daten mit IntelliShare:... 2 Datenversand mit dem IntelliShare

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.0-09.05.2011 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Dezentrales Identity Management für Web- und Desktop-Anwendungen

Dezentrales Identity Management für Web- und Desktop-Anwendungen Dezentrales Identity Management für Web- und Desktop-Anwendungen Sebastian Rieger, Thorsten Hindermann srieger1@gwdg.de, thinder@gwdg.de Gesellschaft für wissenschaftliche Datenverarbeitung mbh Göttingen,

Mehr

Dokumentation Softwareprojekt AlumniDatenbank

Dokumentation Softwareprojekt AlumniDatenbank Dokumentation Softwareprojekt AlumniDatenbank an der Hochschule Anhalt (FH) Hochschule für angewandte Wissenschaften Fachbereich Informatik 13. Februar 2007 Betreuer (HS Anhalt): Prof. Dr. Detlef Klöditz

Mehr

BeamYourScreen Sicherheit

BeamYourScreen Sicherheit BeamYourScreen Sicherheit Inhalt BeamYourScreen Sicherheit... 1 Das Wichtigste im Überblick... 3 Sicherheit der Inhalte... 3 Sicherheit der Benutzeroberfläche... 3 Sicherheit der Infrastruktur... 3 Im

Mehr

OFTP2 - Checkliste für die Implementierung

OFTP2 - Checkliste für die Implementierung connect. move. share. Whitepaper OFTP2 - Checkliste für die Implementierung Die reibungslose Integration des neuen Odette-Standards OFTP2 in den Datenaustausch- Workflow setzt einige Anpassungen der Systemumgebung

Mehr

IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung

IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung IA&DT Sharepoint Extranet mit IA&DT Single Sign On (SSO) Authentifizierung Inhalt SSO Account... 1 Erstkontakt mit dem System (Internet / Kundensicht)... 2 Erstkontakt mit dem System (Intranet)... 3 Funktionen

Mehr

Datenschutzbestimmungen

Datenschutzbestimmungen Datenschutzbestimmungen Im folgenden Text möchten wir Ihnen erklären, welche personenbezogenen Daten wir zu welchen Zwecken erheben, speichern und nutzen. Datenschutz bei www.in-muenchen.de Im folgenden

Mehr

E-Mail-Programm HOWTO. zum Einrichten von E-Mail-Konten

E-Mail-Programm HOWTO. zum Einrichten von E-Mail-Konten E-Mail-Programm HOWTO zum Einrichten von E-Mail-Konten Stand: 01.09.2014 Inhaltsverzeichnis 1. Vorwort... 4 2. Einrichtung der Konten in den E-Mail-Programmen... 5 2.1 Thunderbird...4 2.2 Outlook 2007...6

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

Installationsanleitung

Installationsanleitung 1 Inhalt 1 Inhalt 1 2 Sicherheitshinweise 2 2.1 Allgemeine Richtlinien und Empfehlungen 2 2.2 Allgemeine Sicherheitskriterien 2 3 Zugriffsmöglichkeiten 3 3.1 Browserbasierte Zugriffe auf Dienste im BVN

Mehr

Nachnutzung des Windows Login in einer SAML-basierten. Föderation mittels Shibboleth Kerberos Login Handler

Nachnutzung des Windows Login in einer SAML-basierten. Föderation mittels Shibboleth Kerberos Login Handler Nachnutzung des Windows Login in einer SAML-basierten Föderation mittels Shibboleth Kerberos Login Handler 56. DFN-Betriebstagung, Forum AAI Berlin, 13. März 2012 Peter Gietz, Martin Haase, DAASI International

Mehr

Richtlinie zur.tirol WHOIS-Politik

Richtlinie zur.tirol WHOIS-Politik Richtlinie zur.tirol WHOIS-Politik Die vorliegende Policy soll nach österreichischem Rechtsverständnis ausgelegt werden. Im Streitfall ist die deutsche Version der Policy einer Übersetzung vorrangig. Inhalt

Mehr

IT-Security on Cloud Computing

IT-Security on Cloud Computing Abbildung 1: IT-Sicherheit des Cloud Computing Name, Vorname: Ebert, Philipp Geb.: 23.06.1993 Studiengang: Angewandte Informatik, 3. FS Beruf: IT-Systemelektroniker Abgabedatum: 08.12.2014 Kurzfassung

Mehr

Workshop Sicherheit im Netz KZO Wetzikon. Peter Skrotzky, 4. Dezember 2013

Workshop Sicherheit im Netz KZO Wetzikon. Peter Skrotzky, 4. Dezember 2013 Workshop Sicherheit im Netz KZO Wetzikon Peter Skrotzky, 4. Dezember 2013 Zentrale Fragen! Wie kann sich jemand zu meinem Computer Zugriff verschaffen?! Wie kann jemand meine Daten abhören oder manipulieren?!

Mehr

Problem: keine sichere Verbindung zwischen öffentlichen Schlüssel und der tatsächlichen Identität des Erstellers der Signatur.

Problem: keine sichere Verbindung zwischen öffentlichen Schlüssel und der tatsächlichen Identität des Erstellers der Signatur. Referat im Proseminar Electronic Commerce Thema: Anwendungen von Kryptographie für E-Commerce Betreuer: Michael Galler Stoffsammlung/Grobgliederung Problem der Sicherheit des E-Commerce - nötig für Sicherheitsgarantie:

Mehr

Ev.-Luth. Landeskirche Mecklenburgs Datenschutzbeauftragter

Ev.-Luth. Landeskirche Mecklenburgs Datenschutzbeauftragter Ev.-Luth. Landeskirche Mecklenburgs Datenschutzbeauftragter Goethestraße 27 18209 Bad Doberan Telefon: 038203/77690 Telefax: 038203/776928 Datenschutzbeauftragter Schütte, Goethestraße 27, 18209 Bad Doberan

Mehr

SSL Algorithmen und Anwendung

SSL Algorithmen und Anwendung SSL Algorithmen und Anwendung Stefan Pfab sisspfab@stud.uni-erlangen.de Abstract Viele Anwendungen erfordern nicht nur eine eindeutige und zuverlässige Identifizierung der an einer Kommunikation beteiligten

Mehr

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF

XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF XML-Sicherheitsdienste für das Netzwerk der Global Biodiversity Information Facility GBIF Dipl.-Inf. Lutz Suhrbier Prof. Dr.-Ing. Robert Tolksdorf Dipl.-Inf. Ekaterina Langer Freie Universität Berlin Institut

Mehr

email, Applikationen, Services Alexander Prosser

email, Applikationen, Services Alexander Prosser email, Applikationen, Services Alexander Prosser WWW für Menschen und Maschinen SEITE 2 (C) ALEXANDER PROSSER WWW für Menschen (1) Mensch gibt Adresse ein, z.b. evoting.at oder klickt Link an (2) Server

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet

DNSSEC. Was ist DNSSEC? Wieso braucht man DNSSEC? Für ein sicheres Internet SEC Für ein sicheres Internet Was ist SEC? SEC ist eine Erweiterung des Domain Namen Systems (), die dazu dient, die Echtheit (Authentizität) und die Voll ständig keit (Integrität) der Daten von - Antworten

Mehr

Bedienungsanleitung Datenaustausch per SSL-Website

Bedienungsanleitung Datenaustausch per SSL-Website Bedienungsanleitung Datenaustausch per SSL-Website Ein bewährter Service wird noch besser Um sowohl Ihrem Bedarf nach sicherer Datenübertragung als auch den erhöhten Anforderungen an die Datenschutzbestimmungen

Mehr

Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur.

Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur. MIKOGO SICHERHEIT Inhaltsverzeichnis Das Wichtigste im Überblick 3 Sicherheit der Inhalte Sicherheit der Benutzeroberfläche Sicherheit der Infrastruktur Seite 2. Im Einzelnen 4 Komponenten der Applikation

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

dvv.virtuelle Poststelle

dvv.virtuelle Poststelle Allgemeine Information zu unseren Angeboten über die dvv.virtuelle Poststelle 1 Ausgangssituation Der Einsatz von E-Mail als Kommunikations-Medium ist in der öffentlichen Verwaltung längst selbstverständliche

Mehr

Containerformat Spezifikation

Containerformat Spezifikation Containerformat Spezifikation Version 1.1-21.02.2014 Inhaltsverzeichnis 0 Einführung... 4 0.1 Referenzierte Dokumente... 4 0.2 Abkürzungen... 4 1 Containerformat... 5 1.1 Aufbau des Container-Headers...

Mehr

Datenschutzhinweis - SCHIESSER Online Shops

Datenschutzhinweis - SCHIESSER Online Shops Datenschutzhinweis - SCHIESSER Online Shops Wir freuen uns über Ihr Interesse an unserem Online Shop, SCHIESSER Online Shop und unserem Unternehmen, der SCHIESSER AG (www.schiesser.com). Wir möchten, dass

Mehr

XML Signature Wrapping: Die Kunst SAML Assertions zu fälschen. 19. DFN Workshop Sicherheit in vernetzten Systemen Hamburg, 22.02.

XML Signature Wrapping: Die Kunst SAML Assertions zu fälschen. 19. DFN Workshop Sicherheit in vernetzten Systemen Hamburg, 22.02. XML Wrapping: Die Kunst SAML s zu fälschen Andreas Mayer Adolf Würth GmbH & Co. KG Künzelsau-Gaisbach Prof. Dr. Jörg Schwenk Lehrstuhl für Netz- und Datensicherheit Ruhr-Universität Bochum 19. DFN Workshop

Mehr

Datenempfang von crossinx

Datenempfang von crossinx Datenempfang von crossinx Datenempfang.doc Seite 1 von 6 Inhaltsverzeichnis 1 Einführung... 3 2 AS2... 3 3 SFTP... 3 4 FTP (via VPN)... 4 5 FTPS... 4 6 Email (ggf. verschlüsselt)... 5 7 Portalzugang über

Mehr

Sparda-Bank West eg. b. Von teilnehmenden Händlern bereitgestellte personenbezogene Daten in Verbindung mit Ihrer Nutzung der Sparda MasterPass Wallet

Sparda-Bank West eg. b. Von teilnehmenden Händlern bereitgestellte personenbezogene Daten in Verbindung mit Ihrer Nutzung der Sparda MasterPass Wallet Sparda-Bank West eg Datenschutzbestimmungen für die Sparda MasterPass Wallet Stand: August 2015 Die Sparda-Bank West eg ( Bank ) respektiert Ihre Privatsphäre und verpflichtet sich daher auf diese Datenschutzbestimmungen.

Mehr

Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung

Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung Das Problem Die Abkündigungen seitens Microsoft von Forefront Threat Management Gateway (TMG) und

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

Anwendungsbeschreibung Tobit David.fx Client Web

Anwendungsbeschreibung Tobit David.fx Client Web Anwendungsbeschreibung Tobit David.fx Client Web Stand: Oktober 2009 ...Inhalt Inhalt Inhalt...1-2 1.) Vorabinformation...1-3 2.) Starten des David.fx Client Web im Browser...2-3 3.) Arbeiten mit E-Mails...3-11

Mehr