Home

Diplomarbeit Sicheres Outsourcing mit verteilten Webservices

1. HMO01 HM04 Apache Software Foundation Security Manager HOW TO URL http jakarta apache org tomcat tomcat 5 0 doc security manager howto html Apache Software Foundation The Valve Component 2004 URL http jakarta apache org tomcat tomcat 5 0 doc config valve html The Apache Software Foundation Jakarta Struts 2004 URL http struts apache org Batya Friedman Jr Peter H Khan und Daniel C Howe Trust online Commun ACM 43 12 34 40 2000 URL http doi acm org 10 1145 355112 355120 B Fraser RFC 2196 Site Security Handbook 1997 URL http www faqs org rfcs rfc2196 html Jeffrey E F Friedl Mastering Regular Expressions O REILLY 1997 Bundesamt f r Sicherheit in der Informationstechnik IT Sicherheitshandbuch Bundes amt fiir Sicherheit in der Informationstechnik 1992 Bundesamt fiir Sicherheit in der Informationstechnik IT Sicherheitskriterien und Evalu ierung nach ITSEC 1997 URL http www bsi bund de zertifiz itkrit itsec htm Bundesamt f r Sicherheit in der Informationstechnik BSI Studien 2003 URL http www bsi bund de literat studien index htm Bundesamt fiir Sicherheit in der Informationstechnik Grundschutzhandbuch 2003 URL http www bsi de gshb Bundesamt f r Sicherheit in der Informationstechnik BS7799 Part 1 Vergleich mit dem IT Grundschutzhandbuch 2004 URL http www bsi bund de gshb deutsch aktuell bs7799 htm Institute for Telecommunication Sci
2. PA EPAUIPA permissions R 2 jeder Rolle r wird eine Menge von Rechten zugeordnet permissions R 2 erweiterte Relation um Rollenhirarchie permissions r op t A r op t EPA A ti CurrentState t op PossibleOperations permissions x ri op ti Er lt rclir ont EPA A ti S t A CurrentState t op PossibleOperations Hierbei ist zu beachten dass der Besitzer einer Instanz auch einen Zustands wechsel durchf hren darf Durch das System muss dies sichergestellt werden In der Implementierung Kapitel 8 5 wird eine weitere Eigenschaft dieser De finition verwendet Der Benutzer kann gleichzeitig in mehreren Workflows Tasks sein Da in der Definition von Mengen gesprochen wird ist die Unabh ngigkeit der Tasks erzwungen und ein paralleles Verwenden von zwei Workflows ist ge stattet ohne die Sicherheitseigenschaften des Modells zu verletzen 58 5 Authentifikation im Webumfeld Die Authentifikation eines Subjektes spielt im Webumfeld eine sehr wichtige Rolle da auf Basis der Authentifikationsdaten die Identifikation eines Benutzers vorge nommen wird sowie der Zugriff auf Resourcen gestattet wird Authentifikation wird in 5596 beschrieben als Authentication establishes the identity of one party to another Most commonly authentication establishes the identity of a user to some part of the system Der Begriff Authentifikation bedeutet also generell dass
3. authOperations if _authenticatedSubject null return try authenticate catch LoginException ex throw new AuthenticationException ex private void authenticate throws LoginException LoginContext lc new LoginContext Sample new TextCallbackHandler le login _ authenticatedSubject Ic getSubject public static class AuthenticationException extends RuntimeException public AuthenticationException Exception cause super cause Listing 10 authentication Aspect Bevor die main Methode des ver nderten Programms ausgef hrt werden kann wird kontrolliert ob der Benutzer sich authentifiziert hat Falls dem nicht so ist so wird versucht eine Authentifikation zu erreichen Wenn die Authentifikation fehlschl gt so wird ein Fehler erzeugt und weitergereicht Dies wird durch den before Advice beschrieben 3 2 3 Policy Enforcement Policy Enforcement ist ein Konzept zur Durchsetzung von Regeln innerhalb ei nes Projektes Richtlinien k nnen hiermit bei der Programmentwicklung nicht nur schriftlich oder m ndlich den Entwicklern mitgeteilt werden sondern in Regeln gefasst und durch Aspecte formuliert werden Diese Regeln werden dann durch den Compiler berwacht und durch Compile Time Declarations siehe 3 1 1 be schrieben Eine sehr einfache Regel k nnte zum Beispiel sein dass der 1og Befehl aus Per formencegr nden nicht mehr verwendet werden soll
4. Die Liberty Alliance ist ein Zusammenschluss von verschiedenen Organisationen und Firmen der im September 2001 gegr ndet wurde Ziel des B ndnisses ist der Aufbau eines offenen Standards f r Federated Identity Management Zu einem solchen Standard geh rt im Einzelnen e einen offenen Single Sign On Standard sowie e eine network identity federated identy Spezifikation zu definieren e Gesch ften zu erm glichen Beziehungen zu ihren Kunden selbst ohne Dritte handhaben zu k nnen und e Benutzern zu erm glichen dass Sie ber ihre Privatsph re und Sicherheit ihrer network identity bestimmen k nnen Nach LAP03c versteht die Liberty Alliance unter digitalen Indentit tsinfor mationen bei Liberty Alliance digital identity genannt die Online Identit t en eines Benutzers Hierzu geh ren die drei AAAs also Authentifikations Autorisations und Abrechnungsdaten sowie pers nliche Daten personalisierte Online Einstellungen und Benutzergewohnheiten beim Einkaufen und Einkaufsvorlieben des Benut zers Diese Daten sind in bisherigen Systemen weit verstreut ber die einzelnen isolierten Accounts auf den speziellen Internetseiten Seine Identit tsinformationen soll der Benutzer selbst verwalten und sicher Organisationen seiner Wahl mitteilen k nnen Das Architekturmodell das f r die http www projectliberty org 2 SINGLE SIGN ON 19 Absicherung und korrekte Verwendung dieser Daten zust ndig ist wird von de
5. categoryld es 0 ra sqlQuery sqlUser sqlPassword connectURL FISH org apache struts action mapping instance regEx sqlQuery sqlUser sqlPassword connectURL base_0_0_0 ActionConfigfpath she org apache struts action MODULE regEx sqlQuery sqlUser sqlPassword connectURL base_0_0_0_0 ora apachestruts conti org apache struts action MESSAGE regEx sqlQuery sqlUser sqlPassword connectURL a org apache struts util p Abbildung 45 Bearbeitung eines States workflow generator workflow editor role management user management Create XML Description Role Management role E Add Role 2 Abbildung 46 role management workflow generator workflow editor role management user management Create XML Description Role Management roel EM HE k Add Role Abbildung 47 Ubersicht der Rollen 9 BEISPIELABLAUF DES DEMONSTRATORS workflow generator workflow editor role management user management Create XML Description Role Management Role to be edit rolel Authentication Workfl paral Method Abort Save Reset Abbildung 48 Rollenbearbeitung workflow generator workflow editor role management user management Create XML Description User Management user Add User Abbildung 49 User Management workflow generator workflow editor role management user management Create XML Description User Management user2 _edt al user ER Pa Add User Abbildung 50 Ubersicht der Benutzer
6. 121 122 Workflow generator workflow editor role management user management Create XML Description User Management Edit Preferences for User userl Roles IDP Name of IDP jos Application specific User Password on and Password IDP User re SC FirmCode po Password ed SC UserCode 13 Abort Save Reset Abbildung 51 Benutzer Bearbeitungsmaske workflow generator workflow editor role management user management Create XML Description Download XML Description Abbildung 52 Erzeugung der XML Beschreibung 9 2 Manuelles Bearbeiten der Beschreibung Nachdem im Webtool die Beschreibung erzeugt wurde kann sie manuell nach bearbeitet werden Dieses Beispiel beschr nkt sich auf die in Listing 34 gezeigte Zeile Durch sie wird die Basisseite der Workflows festgelegt In den Parametern url userParameter und passwordParameter sind die lokale Loginseite und die Na men der Parameter hinterlegt in denen der Benutzername und das dazugeh rige Passwort bergeben wird lt applicationLogin url shop signon shtml userParameter username passwordParameter password basePage jpetstore shop index shtml gt Listing 34 nderung an der xml Datei 9 3 Konvertierung in eine relationale Datenbank Die Konvertierung der XML Beschreibung in eine relationale Datenbank findet durch das Tool db tool statt Hierzu muss die Sicherheitsdatenbank gestartet sein und mittels des Programms db_tool sh mit der XML
7. Aufgrund der gerade geschilderten Probleme mit Cookies ist der Cookie basierte Ansatz nur optional im Liberty Protokoll vorhanden Um das Intro duction Problem zu l sen wird entweder ein Standard IDP fest vorgegeben oder aber dem Benutzer ein Liste der IDPs pr sentiert aus der er sich dann seinen favorisierten IDP ausw hlen kann Authentication Assertion Damit sich ein Principal bei einem Service Pro vider ausweisen kann muss er eine Authentication Assertion von einem Identity Provider vorweisen Diese wird nach ID FF in einer SAML 1 1 Nachricht ver packt Das SAML Security Assertion Markup Language Protokoll definiert nach HM04 ein Framework um Sicherheitsinformationen zwischen Online Gesch fts partnern auszutauschen SAML definiert dabei drei Typen von Assertions Au thentication Assertion sagt aus dass ein Subjekt authentifiziert wurde Attribute Assertion spezifiert gewisse Details eines Benutzers und Authorization Decision 26 gibt an was ein Benutzer machen darf Beim ID FF Protokoll wird nur die Au thentication Assertion verwendet und dient dazu dass ein SP eine Anfrage an den IDP stellen kann und vom IDP eine Antwort bekommt in der beschrieben ist welcher Principal zu welchem Zeitpunkt mit welcher Methode authentifiziert wurde Diese Authentication Assertion ist dabei die Antwort Nr 6 7 in Abbil dung 2 auf ein Authentication Request vom SP Authentication Assertion Authentication Statement Authenti
8. Hashtable newFSMStates new Hashtable Vector roles database getRoles user String sessionId request getRequestedSessionId for Enumeration rolenames roles elements rolenames hasMoreElements String rolename String rolenames nextElement for Enumeration workflows database getWorkflows rolename elements workflows hasMoreElements String workflow String workflows nextElement FSMState state try state database getActualWorkflowState sessionId workflow catch SQLException eil database updateFSMState sessionId workflow base state database getActualWorkflowState sessionId workflow String nextState state allowedTransition className methodName request if nextState null nextState new String base newFSMStates put workflow nextState for Enumeration en newFSMStates keys en hasMoreElements String key String en nextElement database updateFSMState sessionId key String newFSMStates get key return database existsValidWorkflow sessionId catch SQLException ei return false Listing 24 Auszug aus dem securityMonitor 8 7 HtmlRewriter Aspect Der HtmlRewriterAspect hat folgende Aufgaben e Darstellen der erzeugten Debugmeldungen des Security Aspect und des IDP Dies macht es f r den Entwickler berfl ssig in einem getrennten Pro gramm die erzeugten Meldungen zu untersuchen e E
9. Target Program Instruction h i i i 1 Interpreter Reference Monitor i i H H H i Abbildung 14 Referenzmonitor im Interpreter integriert Wie Fred Schneider in Sch03 feststellt ist fiir die Implementierung eines Referenzmonitors der Ansatz eines Program Rewriter Abb 15 sehr erfolgs versprechend Dieser modifiziert jedes Objekt bevor es zur Ausf hrung kommt Aufgrund dieses Ansatzes werden Tests der Ausf hrungsrechte auf Basis der Me thoden der bergebenen Parameter und der jeweiligen Ausf hrungsrechte des Benutzers erm glicht So kann auf einfache Art eine feink rnige Zugriffskontrolle im Nachhinein integriert werden 4 2 Sicherheitsstrategie 1975 ver ffentlichten Jerome Saltzer und Michael Schroeder folgende Idee in SS75 4 REFERENZMONITOR ol Abbildung 15 Inline Referenzmonitor Least privilege Every program and every user of the system should operate using the least set of privileges necessary to complete the job LI Weiter f hren sie aus dass durch das Prinzip der minimalen Rechte zwei verschie dene Ziele erreicht werden Zum Einen reduzieren sich die Sch den die durch einen Unfall oder Fehler passieren k nnen Zum Anderen wird die Menge der poten ziellen Interaktionen zwischen Programmen auf das Minimum reduziert welches n tig ist die gew nschten F higkeiten des Systems zu erzielen Dadurch wird die Anzahl der zu berwachenden Programme minimiert Weiter schreiben
10. gt proceed gt neue Webseite Abbildung 23 Ablauf einer Anmeldung f hrung des Single Sign On zum Tragen kommen werden im Kapitel 2 2 ab Seite 18 beschrieben Der in Abbildung 23 skizzierte Abblauf zeigt dass das Sicherheitsmodul bzw SecurityAspect die zentrale Rolle in diesem Konzept einnimmt Alle Ma nahmen wie Authentifikation Reauthentifikation und Autorisation werden durch den Se curityAspect entweder ausgel st oder durchgef hrt Um eine bessere Verwend 82 barkeit des Konzepts zu erreichen erzeugt er ebenfalls Fehlermeldungen und kann bei Bedarf auch eine Anmeldung des Benutzers an der zu schtitzenden Applikation durchf hren Besonders der letzt genannte Punkt ist f r eine hohe Unabh ngigkeit des SecurityAspect von der Applikation notwendig Die Authentifikation wird nicht durch den SecurityAspect direkt durchge f hrt sondern durch das Liberty Single Sign On Framework Der SecurityAspect f hrt eine HTML Weiterleitung zu einem Identity Provider IDP durch Dieser fragt nach einem Benutzernamen und einem dazu passenden Passwort Danach wird wieder zu dem SecurityAspect weitergeleitet Falls die Anmeldung erfolg reich ist wird gepr ft in Abh ngigkeit der Rollenmitgliedschaft ob ein Hardwa retoken abgefragt werden muss Falls eine Rolle der der Benutzer zugeh rig ist eine entsprechende berpr fung fordert wird wieder an den IDP weitergeleitet so dass der IDP auf die Existenz des Tok
11. 68 Authentifikation Ein Authentifikationsverfahren mit dem Wibu Key wird in AGO1 beschrieben Hierbei handelt es sich um ein Challenge Response Verfahren Bevor der Client Rechner Zugriff auf eine Webseite t tigen kann schickt der Ser ver Verifier dem Client Claimant eine Challenge die der Client Rechner mit einer Response beantworten muss Der Server schickt dem Client in der Challen ge oder auch Authentication Request Data genannt einen zuf lligen Selection Code und einen zuf lligen String als Challenge Der Client Rechner verschl sselt den zuf lligen String mit Hilfe des Selection Codes als Schl ssel mit dem Wibu Key Das Ergebnis wird dann als Response zur ck an den Server geschickt Der Server muss jetzt seine Challenge selbst mit dem an den Server Rechner ange schlossenen Wibu Key verschl sseln und die beiden Ergebnisse vergleichen Falls sie identisch sind ist der Benutzer authentifiziert API Die Interaktion mit der API vom Wibu Key verl uft wie detailliert in AG03 beschrieben Zuerst muss mittels der Funktion WkbOpen2 der Zugriff auf den Wibu Key initialisiert werden Hierbei werden die Parameter Firm Code und User Code bergeben Falls der Zugriff funktioniert k nnen mittels der Funk tion WkbCrypt2 Daten verschl sselt werden Dieser Funktion muss der Selection Code sowie die zu verschl sselnden Daten bergeben werden Als R ckgabewert erh lt man die mit dem Feal Algorithmus verschl sselten Daten bei dene
12. 8 Nachfragen bei IDP gt 1 9 Antwort des IDP La 10 Webseite generieren 11 HTTP Antwort Abbildung 2 Single Sign On and Federation den Browser des Benutzer dem SP 6 7 mit einer Authentication Assertion s u SAML Artifact siche Kapitel 2 4 auf Seite 25 oder einer Fehlermel dung Falls mit einer SAML Artifact eine Zufallszahl die auf eine beim IDP gespeicherte SAML Assertion deutet geantwortet wurde fragt 8 der SP beim IDP mit dem Artifact nach der SAML Assertion Der IDP antwortet 9 dem SP und schickt ihm die Assertion Wenn die Assertion richtig ausgestellt wurde kann der SP die Webseite generieren 10 und dem Browser des Benutzers schicken 11 Der gerade beschriebene Protokollablauf soll m glichst von einer breiten Basis an Browsern unterst tzt werden sodass das Protokoll nur einige Sub Protokolle und M glichkeiten verwendet die von viele Browser unterst tzt wird Zu diesen M glichkeiten geh ren Web Redirects und die Verwendung von Cookies sowie das Verpacken von Nachrichten mit Hilfe von SAML und SOAP Auf diese Sub Protokolle und M glichkeiten wird im folgenden kurz eingegangen Web Redirects Web Redirects werden bei Liberty ber den HTTP Befehl 302 Temporary Redirect oder ber HTML Form POST basierten Redirects reali siert In Abbildung 3 ist dargestellt wie Web Redirect funktioniert Der Browser des Benutzers schickt eine HTTP Anfrage z B an den Service Provider 1
13. Alliance ein zusatzliches Gewicht da damit ein weiterer wichtiger Industriean bieter beigetreten ist Es gibt eine gro e Nachfrage der Industrie an Systemen zur Identity Federation In immer mehr Produkten werden Konzepte zur Identity Federation integriert Die API von SourcelD Java hat die Implementierung des Liberty Protokolls in eine Applikation erleichtert Allerdings erforderte die Integration eine sehr gro e Einarbeitungszeit und ein genaues Verst ndnis des Liberty Protokolls Mit SourcelD Java ist es nicht auf die Schnelle m glich eine Web Applikation um Identity Federations zu erweitern Die Tatsache dass es sehr wenig Literatur und Austauschm glichkeiten mit anderen Entwicklern gibt erschwerte die Arbeit mit SourcelD Java wesentlich Es w re w nschenswert wenn in Zukunft das Open Source Project SourcelD Java mehr den Open Source Gedanken aufnimmt und auch andere Entwickler an der Arbeit an SourceID mit einbezieht Es ist zu hoffen das hier das neue Project SourcelD Liberty welches einen eigenst ndigen Server darstellt in diesem Punkt besser durchdacht ist Ausblick Es ergaben sich w hrend der Arbeit an dem Demonstrator weite re Ideen die keinen Eingang in die Implementation gefunden haben Folgende Auflistung gibt einen berblick Audit Ein Audit stellt die Protokollierung aller Handlungen dar die ein Mit arbeiter mit der Software ausf hren kann Eine solches Mitschreiben in eine Datenbank kann leicht als ein
14. Dies ist in Abbildung 12 dargestellt if core concern System Abbildung 12 Schema des Weaver Die dritte M glichkeit unterscheidet sich stark von den bisher gezeigten L sun gen Hier wird nicht das Programm ver ndert sondern ein spezieller class Loader eingesetzt der das Weaving w hrend der Programmausf hrung durchf hrt Die ses Verfahren wird zum Beispiel vom Aspectwerkzframework als hot deployment Vas04 bezeichnet Wie auf der Webseite von Aspectwerkz Vas04 hervorgeho ben wird besteht mit Hilfe dieses Konzepts die M glichkeit dynamisch Aspecte hinzuzuf gen zu entfernen oder zu ndern 42 3 2 Einsatzbeispiele Im folgenden wird durch einige Beispiele der Einsatz von AspectJ innerhalb der Diplomarbeit motiviert Dabei soll gezeigt werden wie stark ein Programm in seiner Struktur durch den Einsatz von AOP vereinfacht wird Die Beispiele lehnen sich an die Beispiele von Ramnivas Laddad aus Lad03 an 3 2 1 Logging Das Logging Beispiel das schon in der Einleitung zu diesem Kapitel Verwendung fand sollnun durch einen Aspekt umschrieben werden In der Diplomarbeit findet der Aspect wie in Listing 9 gezeigt Verwendung import java wutil logging x import org aspectj lang import org apache commons logging Log import org apache commons logging LogFactory aspect loggingAspect private int test 0 private Logger _logger Logger getLogger trace private static Log l
15. glichen Reauthentifikation durch ein Verfahren nach Besitz Dies sollte ein Token sein dass m glichst einfach an vielen Rechnern mit Internetanschluss anschliefbar ist Um eine einfache Integration in einem Tomcat basierten Iden tity Provider zu gew hleisten muss eine Java Schnittstelle zu diesem Token zur Verfiigung stehen Eine der wenigen Tokens die diese Anforderungen erfiillen ist der Wibu Key AG der Firma Wibu Systems Der Wibu Key wird haupts chlich als Kopierschutzsystem fiir Software eingesetzt kann aber auch als Authentifi kationssystem dienen AGO1 nach A Schmidt auch beim BMWA im Einsatz Details Der Wibu Key beherrscht eine symmetrische Verschliisselung nach dem FEAL Algorithmus mit 64 Bit Schl sseln Den Wibu Key gibt es nicht nur als USB Version sondern auch als COM LPT PCMCIA etc Somit ist der Wibu Key an fast jeden Computer anschliefbar Der Nachfolger des Wibu Key vom Hause Wibu Systems der Codemeter hat wesentlich bessere Verschliisselungs kapazitaten als der Wibu Key allerdings gab es fiir den Codemeter Mitte 2004 noch keine Java API sodass er fiir unseren Demonstrator nicht in Frage kam Der Firm Code und User Code sind die wichtigsten Eintr ge im Wibu Key Diese werden tiber ein Programmiertool fest in den Wibu Key eingespeichert Der Firm Code ist eine 24 Bit Zahl die jedem Kunden von Wibu Systems zu geteilt wird Es wird dabei garantiert dass jeder Firm Code nur einmal verge ben wird AG04 Dies
16. rigen Autorisations und Authenti fikationsdaten erm glicht Der Einsatz eines bestehenden Formats wie es in Form von SAML vorliegt wurde verworfen da dort keine einfache Repr sentation der Workflows m glich gewesen w re Somit w ren zwei Beschreibungsdateien ben tigt worden Dies erschien als ein zu grosser Aufwand f r den relativ begrenzten gew nschten Sprachumfang Die erzeugte XML Datei entspricht einer Modellierungssprache die zwischen dem Generator und dem Interpreter Verwendung findet Es besteht dadurch die manuelle M glichkeit die Korrektheit der Beschreibung zu kontrollieren Abbil dung 27 Beschreibung Beschreibung automatisch umwandeln erzeugen verwenden Abbildung 27 Verwendung der XML Beschreibung A Der Aufbau unterteilt sich grob in vier Bereiche e den Workflows e den Benutzern e den Rollen 94 e dem applikationsspezifischen Bereich Durch die Workflows werden Arbeitsabl ufe spezifiziert wie dies in Kapitel 4 3 beschrieben ist Jeder Zustand der Statusmaschine wird beschrieben ber einen Namen die zugeordnete Javaklasse und den Uberg ngen zu anderen Zust nden Dies wird durch Listing 18 ausgedriickt lt xsd complexType name statesType gt lt xsd sequence gt i lt xsd element name state type stateType minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd complex Type gt lt xsd complexType name stateType gt lt xsd sequence gt lt x
17. www rsasecurity com rsalabs node asp id 2254 LACO3 Liberty ID FF Authentication Context Specification 11 August 2003 URL http www projectliberty org specs liberty authentication context v1 2 pdf Lad03 Ramnivas Laddad AspectJ in Action Practical Aspect Oriented Programming Manning Publications Co 2003 LAP03a Liberty Alliance Project White Paper Liberty Alliance Es WS Federation A Comparative Overview 14 Oktober 2003 URL https www projectliberty org resources whitepapers wsfed liberty overview 10 13 03 pdf LAP03b Liberty Alliance Project Identity Systems and Liberty Specification Version 1 1 Interope rability 2003 URL http www projectliberty org resources whitepapers Liberty and 3rd Party Identity Systems White Paper pdf LAP03c Liberty Alliance Project Liberty ID FF Architecture Overview Version 1 2 2003 URL http www projectliberty org specs liberty idff arch overview v1 2 pdf Lew03 J Lewis Enterprise Identity Management Datenschutz und Datensicherheit Seiten 533 535 2003 LGK 99 Charlie Lai Li Gong Larry Koved Anthony Nadalin und Roland Schemers User Au thentication and Authorization in the Java Platform In 15th Annual Computer Security Applications Conference Seiten 285 290 IEEE Computer Society Press 1999 URL http java sun com security jaas doc acsac html Meg04 David Megginson SAX Simple API for XML 2004 URL http www saxproject org Meh04 Michael
18. Alliance s u das schon l nger im Einsatz ist LAP03a Auch ein wichtiger Bau stein des ID FF die Anonymit t eines Benutzers ist im WS Federation nur ein optionaler Bestandteil Zum Thema Intellectual Property Rights IPRS schreiben die Autoren der Spezifikation the authors do not grant either expressly or impliedly a license to any intellectual property including patents they own or control Dies bedeutet ein unkalkulierbares Risiko fiir Implementierer da die Kosten ftir eine m gliche Implementierung dieser Spezifikation in ein Produkt und daraus resultierende Kosten fiir den Verkauf eines solchen Produktes nicht bekannt sind 2 1 3 Shibboleth Die Architektur von Shibboleth sorgt fiir den sicheren Austausch von Autorisa tionsinformationen zwischen Universit tsinstitutionen Shibboleth is an initiative by Internet2 member universities to develop and deploy new middleware technologies that can facilitate inter institutional collaboration and access to digital content Int Die Motivation fiir Shibboleth liegt haupts chlich in der M glichkeit das Tei len von digitalen Resourcen unterschiedlichster Institutionen fiir Wissenschaftler ber das Internet zu erm glichen LAP03b Es soll einem Nutzer z B einem Studenten m glich sein Zugriff auf eine Ressource von einer anderen Universit t 16 oder Institution zu bekommen Bisher musste diesem Studenten dafiir ein zwei ter Account bei der anderen Institution eingericht
19. Als Antwort 2 bekommt er den Status Code 302 mit einer neuen URI gesendet In dieser URI sind weitere Parameter enthalten unter anderem auch die R ck 24 Service Identity Provider Provider Benutzer Browser Abbildung 3 Web Redirects kehradresse des SPs Vom Browser wird erwartet dass er der Aufforderung nach kommt und die angegebene URI aufruft 3 Der Identity Provider kann aus den Informationen in der URI erkennen dass die Anfrage urspr nglich von dem Ser vice Provider kommt und kann dem Browser wiederum ber den Status Code 302 4 zur ck zum Service Provider senden 5 und zus tzlich weitere Informationen bergeben Somit ist mit Hilfe des Browsers ein Kommunikationskanal zwischen SP und IDP aufgebaut Beim POST basiertem Redirect bekommt der Browser ein HTML Formular bertragen 2 bei dem der Submit Button mit einer URI mit Paramtern ver kn pft ist Wenn auf SUBMIT geklickt wird bekommt der empfangende Server die URI mittels der HTTP POST Methode gesendet 3 und kann den urspr ng lichen Absender erkennen und dem Browser wiederum ein HTML Formular schi cken 4 und seine Parameter in der URI mit einschlie en Der Browser macht wiederum ein HTTP POST 5 und kontaktiert den ersten Server ber die Ein bindung eines JavaScripts in das Formular kann der Vorgang automatisiert wer den sodass der Benutzer nicht auf SUBMIT klicken muss Nach LAP03c ist Web Redirection kein ideales Kommunikatio
20. B automatisch ausgeloggt werden oder Vergesslichkeitslisten f r jeden Benutzer erstellt und Ma nahmen zur Schulung dieser Benutzer ergriffen werden Bei der Realisierung dieses proaktiven Applets sind wir auf Probleme mit dem Konzept des Liberty ID FF Protokolls siehe Kapitel 2 3 gesto en Ein Kontakt zwischen dem Client Rechner und dem 114 Identity Provider besteht beim Single Sign On Konzept des Liberty ID FF Pro tokolls nur zu Authentifikationszwecken Somit ist dem Identity Provider zwar bekannt wann zuletzt eine Reauthentifikation stattgefunden hat ihm ist aber nicht bekannt ob der Benutzer in letzter Zeit aktiv war oder nicht Dies kann nur ein Service Provider wissen da der Benutzer nur direkt mit den Seiten des Service Providers arbeitet Um nun sowohl den Service Provider als auch den Identity Provider zu integrieren wird das proaktive Applet beim Aufbau jeder Seite des Service Providers durch den HtmlRewriterAspect siehe 8 7 gestartet Jede Seite die vom Service Provider d h im Falle unseres Demonstrators von JPetstore generiert wird wird vom HtmlRewriterAspect vor Ubertragung an den Clientrechner ver ndert In den Quelltext wird ein Link auf das Applet bei dem Identity Provider gesetzt Der Grund fiir das Nachladen des Applet direkt vom Identity Provider liegt darin dass ber diesen Weg eine einfache Applet Server Kommunikation zum IDP aufgebaut werden kann Bei Ubertragung einer zweiten Webseite vom Service Provider w
21. Beschreibung als Pa rameter wird die Sicherheitsdatenbank aufgebaut 9 4 Produktiveinsatz Nachdem die Sicherheitsdatenbank erstellt wurde muss die abzusichernde Web Applikation in dem Fall unseres Demonstrators der JPetstore erweitert werden 9 BEISPIELABLAUF DES DEMONSTRATORS 123 Hierzu geh ren die Einstellungen die fiir die Einbindung des Liberty Protokoll mittels SourceID get tigt werden miissen sowie die Einbindung der Aspecte HTMLRewriter und Security Aspect Die Details werden im folgenden erl utert Einbinden von SourcelD F r die Konfiguration von SourceID m ssen die drei Dateien web xml sourceid sso xml und sourceid sso providers xml geandert werden Die n tigen Anderungen sind in Kapitel 2 6 beschrieben Zus tzlich be n tigt SourcelD einige jar Dateien im lib Verzeichnis der Applikation Diese sind e axis jar e castor 0 9 4 2 xml jar e commons discovery jar e commons httpclient jar e commons logging jar e jaxrpc jar e saaj jar e sourceid sso jar e xml apis jar e xmlsec jar Da jeder Provider in einem Circle of Trust ein eigenes Zertifikat fiir die Signie rung von Liberty Nachrichten ben tigt mu f r SourcelD ein solches Zertifikat erstellt werden Dieses Zertifikat wird in einer Datei gespeichert und der Da teiname in die Datei sourceid sso xml eingetragen HTMLRewriter Zur Einbindung des HTMLRewriters reicht es das Build Script des HTMLRewriters auszuf hren Das Build Script f hrt da
22. D Logout Page Smartcard Page 3 Process Reque 4 AccountHandler 3 End Request La 6 1 Abbildung 8 IDP Interaktion Applikation amp SourceID API die nach au en offenen Schnittstellen in der web xml die Angabe ber den AccountHandler und die IDP Rolle von sourceID wird in der sourceid sso xml angegeben Der Ablauf der Kommunikation zwischen der SourceID Java API und der Ap plikation auf der IDP Seite ist in Abbildung 8 dargestellt Im Normalfall kommt eine Anforderung von einem SP an den IDP zur Authentifikation eines Subjekts Die Aufforderung 1 geht dabei direkt an die in der web xml spezifierten offe nen Schnittstelle von SourcelD Java Dort wird sie berpr ft und die Kontrolle an die Login Seiten der IDP Applikation bergeben 2 Hier f hrt die Applika tion je nach Anforderung im Authentication Request des SP die Authentifikati on durch Hiernach wird die Kontrolle wieder an SourceID mit der Angabe der lokalen Benutzerkennung bergeben 3 SourcelD berpr ft nun ob es eine fe deration zwischen der lokalen Benutzerkennung und der Benutzerkennung auf der anfragenden SP Seite gibt Hierf r wird der AccountHandler der Applikation aufgerufen 4 Der AccountHandler berpr ft die lokalen Datenbank nach der ein getragenen federation und bergibt das Ergebnis wieder zur ck an SourcelD 5 SourcelD generiert nun die Antwort f r den SP und tr gt als Benutzerkennung das Pseudonym ein das ihm der Acco
23. EEN a ELA JAAS u T a SE A e aa em R 13 14 14 15 15 16 16 17 18 19 22 28 30 36 37 38 Al 42 42 42 43 44 44 44 45 46 49 49 50 53 54 5 2 Anforderungen un u au nn an na a A 5 2 1 Authentifikationsverfahren 5 2 2 Reauthentifikation e oo WIESEN a a eS Serverabsicherung SN secu enra eSa heed a Sede ed ada HY 6 2 Sicherheitsma nahmen auf Betriebssystemebene 6 3 Tomcats Sicherheitskonzept 6 4 Beurteilung von Sicherheit ib seu a o ss Konzept und Sicherheitsbetrachtung Tal DODD n t e e a ble a ne gg Ta Feinkonzepte lt as cid as pa Oraa en re 7 3 Sicherheitsbetrachtung des Konzepts Spezifikation und Implementierung OA eet ue bale Be db A ne AE 8 2 AML Beschreibung oros ee 0 a am a ek 8 3 Sicherheitsdatenbank o nenn BA Datenb nktool u ud za aria a E 8 5 SecurityAspect ann erh RR o IE 8 7 HtmlRewriterAspect ec ra Nena Soe firu 53 Identity Provider soccer sia 8 8 1 Kanalverschl sselung lt lt S0 A RAI SUL Wirren A E ew a E ee oe ee See A SAD ProAktivApplat 238 8 tae a a O aan Beispielablauf des Demonstrators 9 1 Erzeugen der Sicherheitsbeschreibung 9 2 Manuelles Bearbeiten der Beschreibung 9 3 Konvertierung in eine relationale Datenbank OF Prod ktivensatz o o sos aaa dra 10 Fazit und Ausblick A Erkl rung zur Diplomarbe
24. JAAS ist nicht nur auf den Tomcat beschr nkt sondern bietet die M glichkeit sicher festzustellen wer gerade Java Code ausf hrt egal ob der Code in einer Applikation einem Applet einem Bean oder einem Servlet l uft Sun04 Mit diesem Framework ist es m glich fast beliebige Authentifikationsmodule einzubauen so z B Kerbe ros JNDI etc Allerdings gibt es f r die Anbindung des Liberty Protokolls noch keine Spezifikation f r JAAS SourcelD bietet nur die M glichkeit das Liberty Protokoll direkt an eine Applikation anzubinden JAAS bernimmt die Authentifikation eines Benutzers bietet aber f r die Zugriffskontrolle nur eingeschr nkte M glichkeiten Dies ist zwar ber den dekla 62 rative Ansatz von JAAS m glich womit aber die Sicherheitsaspekte nicht von der eigentlichen Applikation getrennt sind 5 2 Anforderungen Das Single Sign On System vom Tomcat bezieht sich nur auf Applikationen die innerhalb dieses einen Tomcatservers laufen Da aber Applikationen auch ber mehrere Server verteilt sein k nnen ist f r solche dieses System nicht geeignet Ein weiteres Problem ist die geringe Auswahl an Authentifikationverfahren beim Tomcat Au er dem Authentifikationsverfahren per SSL sind alle anderen mit recht gro en Sicherheitsproblemen behaftet Falls eine Applikation eine andere Methode w nscht kann auch hier das System vom Tomcatserver nicht verwen det werden Weiterhin ist die Integration einer Single Sign On Funktiona
25. Liberty Alliance Spezifizierungen ist die Liberty Identity Services Interface Specifications Diese ist noch nicht komplett abgeschlossen und soll aufbauend auf ID WSF die M glichkeit von personenbezo genen Profilen wie Kalender Adressb cher etc bieten mit denen die Grundlage f r ein weites Feld von Anwendungsf llen bereitet wird Da das Liberty Protokoll f r sehr viele Programme offen sein will basiert es auf den Standardprotokollen der webbasierten Systeme Dazu geh ren HTTP SSL SOAP und SAML Zus tzlich stehen die Funktionen des Browsers und des Web Servers zur Verf gung Da aber auch hier eine breite Basis an Browsern und Servern unterst tzt werden soll werden nur M glichkeiten eingebunden die schon in sehr vielen Browsern bzw Servern integriert sind Die Besonderheiten und Schwachstellen der verwendeten Subprotokolle und Funktionen werden im Folgenden genauer betrachtet 2 3 Schliisselkomponenten von Liberty Nach Proa sind die Schl sselrollen des Liberty ID FF 20 Principal Beim ID FF Protokoll wird der Benutzer als Principal bezeichnet der mit mindestens zwei Diensten in Kontakt steht IDP Ein m glicher Dienst ist der Identity Provider IDP Dieser ist ein An bieter der mit mehreren anderen Anbietern Gesch ftsbeziehungen hat z B eine Fluggesellschaft die mit verschiedenen Autovermietungsfirmen und Hotels ko operiert Der IDP baut dabei den Circle of Trust s u letztlich tiber vertragliche Bezi
26. Rights BO test International Organization for Standardization Pi iste eae cae Informationstechnologie NK RE Information Technology Security Evaluation Citeria A say Java 2 Enterprise Edition JAAS ua Java Authentication and Authorization Service TARS ni ae der Java Authorization and Authentication Service 136 INDIE 222 Java Naming and Directory Interface JRE nations Java Runtime Environment JSP sr Java Server Pages NISI susto National Institute of Standards and Technology PIN ias Personal Identification Number RAID A Redundant Array of Inexpensive Disks RBAG rios Role Based Access Control REC ce Internet Requests for Comments SAML ara Security Assertion Markup Language SAX areas af Simple API for XML SOAP nui Simple Object Access Protocol a A area nee Service Provider SOL codi Structured Query language o DRE ESEL DE HE Secure Socket Layer AO BEI Single Sign On TESEC vs Trusted Computer Systems Evaluation Criteria A Three Letter Acronyms E AAA Transport Layer Security URD carnero Unified Resource Identifier NSG roscas World Wide Web Consortium WBEM a Web Based Enterprise Management XM p Yeas r extensible markup language XOD tata Cross site Scripting LIO nt Zero Interaction Authentication E LITERATURVERZEICHNIS 137 E Literaturverzeichnis Literatur 97997 ISO TEC 9798 1 Information technology Security techniques Entity authentication Part 1 1997 AA04 Information Systems Audit und Control Associ
27. SSL siehe Kapitel 2 5 Nach Eck01 Kapitel 12 3 4 ist SSL ein de facto Standard f r sichere HTTP Verbindungen Die Authentifikation der Kommunikationspartner wird im Demonstrator dazu verwendet dass sich der Identity Provider dem Clientrechner gegen ber ausweist Hiermit kann der Benutzer sicher sein mit welchen Servern er in Interaktion steht Eine zus tzliche Authentifizierung des Client Rechners ber SSL wird im Rahmen dieser Diplomarbeit nicht betrachtet Dies k nnte eine weitere unter vielen M glichkeiten sein die Authentizit t eines Benutzers im Rahmen eines Identity Providers festzustellen Liberty Alliance schreibt in seiner Spezifikation Liberty Id FF Bindings and Profile Specification CK03 vor dass bei dem Wunsch nach Nachrichteninte grit t und Vertraulichkeit SSL Version 3 0 verwendet werden muss vgl Kapitel 2 5 Die Intergration von SSL f r die Liberty Protokoll Nachrichten ist mit Hilfe von SourcelD realisierbar Es muss bei einer Applikation daf r gesorgt werden dass die Einspringpunkte von SourcelD des Liberty Protokolls ausschlie lich per SSL erreichbar sind Somit hat man die Vertraulichkeit und Integrit t der Nach richten durch SSL sichergestellt Dies muss nat rlich bei allen Beteiligten des Circle of Trust geschehen da sonst z B die Nachrichten nur vom Provider A zum Client Rechner per SSL abgesichert sind und weiter zum Provider B nicht per SSL abgesichert sind und somit die Vertraulichkeit und
28. Servers zugegriffen IDP Client IDP Applikation HTTP SSL Browser Applet Wibukey Wibukey Hardware Hardware Abbildung 37 Wibukey 8 10 ProAktivApplet Proaktivit t wird in diesem Demonstrator innerhalb eines Applets verwendet Das Applet l uft auf Seiten des Client Rechners und dient zur berwachung des Benuters und der periodischen zero interaction siehe Kapitel 5 2 2 Reau thentifikation Nach einer initialen Authentifikation mit Benutzername und Pass wort werden weitere Reauthentifikationen ohne Interaktion des Benutzers durch das berpr fen des Wibu Keys durchgef hrt Hieraus ergibt sich die Gefahr ei ner m glichen Vergesslichkeit beim Benutzer Er k nnte das Vorhandensein des Wibu Keys am Rechner vergessen und somit Angreifern z B erm glichen inner halb einer Mittagspause bei der der Benutzer seinen Computer verl sst Zugang zu dem System durch diesen Rechner zu bekommen vgl Kapitel 5 2 2 Um genau dieses Problem zu adressieren haben wir in unserem Demonstra tor ein proaktives Applet eingebaut Dieses Applet l uft auf dem Client Rechner des Benutzers und berpr ft das Vorhandensein des Wibu Keys im System Falls der Wibu Key vorhanden ist der Benutzer im System eingeloggt ist und der Be nutzer eine gewisse Zeitspanne inaktiv war bekommt er eine Warnung und der Identity Provider wird informiert dass der Benutzer die letzte Zeit inaktiv war Somit k nnte der Benutzer vom Identity Provider z
29. Sitzungsschl ssel f r die Kommunikation eines Principals mit einem Dienst vgl Eck03 Kapitel 10 5 4 2 1 5 Radius RADIUS Remote Authentication Dial In User Service RWL 00 ist ein Proto koll zur Authentifikation von Benutzern die ber einen Einwahldienst Zugang er langen wollen Diese Einwahldienste sind Service Provider die dem Benutzer ber ihre Einwahlknoten Zugang zum Internet gew hren Da sich ein Benutzer ber unterschiedliche Knoten einw hlen kann bergibt der Benutzer seine Authenti fikationsdaten dem Einwahlknoten der diese an einen zentralen RADIUS Server weiterleitet Die Authentifikationsdaten werden vom RADIUS Server berpr ft und der Einwahlknoten ber das Ergebnis dieser berpr fung informiert RADIUS ist eine vereinfachte Implementierung der AAA Architektur dies ist eine Architektur um Authentifikationen Autorisationen und Abrechnungen von Benutzern durchf hren zu k nnen 2 SINGLE SIGN ON 17 2 1 6 Vergleich Ein Single Sign On System muf es erm glichen eine AAA Architektur authenti cation autorisation accounting zu unterst tzen Es muss die M glichkeit bieten vgl VCF 00 Eck03 Kapitel 10 5 1 e eine Authentifikation eines Benutzers mit beliebigen Authentifikationsver fahren durchf hren zu k nnen e eine Zugriffskontrolle auf der Seite eines Provider zu erm glichen e eine abschlie ende Abrechnung der vom Benutzer genutzten Dienste erm g lichen Im Umfeld von Elect
30. Surv 28 1 241 243 1996 URL http doi acm org 10 1145 234313 234412 Suzanne Smith und Sara Stoecklin What we can learn from extreme programming J Comput Small Coll 17 2 144 151 2001 sslext The Struts SSL Extension for HTTP HTTPS switching 2004 URL http sslext sourceforge net Pagadala J Suresh und Palaniyappan Thiagarajan JAR files revealed 1985 URL http www 106 ibm com developerworks java library j jar E LITERATURVERZEICHNIS 143 STA85 SUN85 Sun04 SZ03 TCo3 Ten00 Tri04 Vas04 VCF 00 Voe00 Vog04 VVKo3 W3C00 w3c04 Wik WJP03 Woe04 DEPARTMENT OF DEFENSE STANDARD TRUSTED COM PUTER SYSTEM EVALUATION CRITERIA 1985 URL http www radium ncsc mil tpep library rainbow 5200 28 STD html SUN jarsigner JAR Signing and Verification Tool 1985 URL http java sun com j2se 1 3 docs tooldocs win32 jarsigner html Sun Java Authentication and Authorization Service JAAS Overview 2004 URL http java sun com products jaas overview html Pawel Slowikowski und Krzysztof Zielinski Comparison Study of Aspect oriented and Container Managed Security AAOS2003 Analysis of Aspect Oriented Software 2003 Peter Thompson und Darryl Champagne Liberty ID FF Implementation Guidlines 2003 URL http www projectliberty org specs David Tennenhouse Proactive computing Commun ACM 43 5 43 50 2000 URL http doi acm org 10
31. Um nun dem Benutzer die M glichkeit zu geben auf eine durch ihn erzeugte Fehleingabe zu reagieren er k nnte ja unabsichtlich in einen verbotenen Bereich gegangen sein wird im FSMState der jeweils letzte Zustand der Workflows hin terlegt Falls nun alle Workflows in den Zustand Base bergegangen sind so wird ein Schritt zur ckgegangen Der SecurityAspect bekommt damit die M g lichkeit eine Fehlerseite anzuzeigen und durch Bet tigen des Backbuttons kommt der Benutzer zu der letzten Maske zur ck ohne dass sich der Zustand der Appli kation ver ndert hat Durch diese starke Eingrenzung der Funktionalit t wird der eigentliche Code des Referenzmonitors relativ kurz und somit auch gut kontrollierbar Dies wird durch Listing 24 demonstriert welches den kompletten Funktionsumfang der Me thode isValidAccess beinhaltet Wie beschrieben werden hier im ersten Schritt die Rollen des Benutzers bestimmt um dann in n chsten Schritt die Workflows zu ermitteln Nun wird jeder Workflow weitergeschrieben also in einen Folgezustand gef hrt oder auf Base falls es aufgrund der Eingabe des Benutzers keinen er laubten Folgezustand gibt Die neuen Zust nde werden danach in die Datenbank 104 geschrieben Aufgrund des neuen Datenbankzustands wird erst am Ende entschie den ob der gew nschte neue Zustand erreicht werden kann Falls alle Workflows im Zustand Base stehen wird der Zustand abgelehnt und ein false als Antwort gegeben
32. an der xml Datei 122 D ABK RZUNGSVERZEICHNIS 135 D Abk rzungsverzeichnis Abk rzungsverzeichnis AAA hs ood otk etka Authentication Autorisation Accounting ACDB gegen Access Control Database AGID A Atomicity Consistency Isolation Durability BO seth gain ee AspectJ Compiler POI sa Aspect Oriented Programming API ans es Application Programming Interface POE Ue o a Application Service Provider BMWA Bundesministerium fur Wirtschaft und Arbeit BAD is whats ds Berkeley Software Design BOL eebe ces Bundesamt fur Sicherheit in der Informationstechnik CA we Certification Authority COBIE cdas Control Objectives for Information and related Technology EE Alec as Data Encryption Standard DOM cuales aras Document Object Model FEAL us aus Fast Data Encipherment Algorithm FIFO tas First In First Out ESM tica Finite State Machine GMITS 223 224 guidelines for the management of IT Security GSHB A Grundschutzhandbuch des BSI HTML eres Hypertext Markup Language HTTP casas Hypertext Transport Protocol HTTPS spas Secure Hypertext Transport Protocol MAA International Business Machines Corporation IDE cue ese Identity Federation Framework IR as Identity Services Interface Specifications ID WSF dades Identity Web Services Framework MAS ai Identity Database ras pe bo Identity Provider AE Intrusion Detection System UE International Engineering Consortium IEC AA Input Output IPRS AA Intellectual Property
33. angibt Dieser Authentification Request wird dann an den SourcelD SSO Authenticators bermittelt 2 SourceID bernimmt jetzt die Anfrage und nimmt die Kommu nikation mit dem angegebenen Identity Provider ber web redirects auf Falls die Authentifikation positiv verlief berpr ft SourcelD Java ber den Aufruf 3 des AccountHandlers ob es zu dem vom IDP angegeben Pseudonym einen Eintrag 34 Application SourceID API 1 Y Request Authentication Process Authentication Federation 9 Federation Logout Logout from IDP sso authnRequest Forwarding to IDP AccountHandler 2 4 Process answer from IDP Success Failure 6 M Abbildung 7 SP Interaktion Applikation amp SourceID API in der Datenbank gibt Der AccountHandler liefert im positiven Fall die lokale Benutzerkennung des Subjekts zur ck 4 Danach wird die Kontrolle wieder zu r ck an die Applikation gegeben 5 Hierbei wird je nach gelungener oder nicht gelungener Authentifikation die Success Page oder Failure Page der Applikation aufgerufen Im Fehlerfall bekommt die Applikation eine Fehlermeldung bermit telt warum die Authentifikation fehlgeschlagen ist Das Anlegen einer neuen Federation zwischen einem Account bei der Appli kation und einem Account bei einem Identity Provider funktioniert dabei auf die gleiche Weise wie in Abbildung 7 ber den SP nur wird hierbei a
34. bei Tomcat bzw einem application container wird von der Java Servlet Spezifikation Cow01 unterschieden in deklarative Sicherheit und programmative Sicherheit e Deklarative Sicherheit Bei der deklarativen Sicherheit wird die Konfiguration der Zugriffskontrol le im deployment descriptor vorgenommen Dies hat den Vorteil dass die Sicherheitsstruktur einer Applikation auferhalb der eigentlichen Applika tion spezifiziert wird Im deployment descriptor werden die n tigen Spe zifikationen zu Rollen Zugriffskontrolle und Authentifikation angegeben Die Uberpriifung der Sicherheitsangaben im laufenden Betrieb wird vom Tomcat direkt bernommen e Programmative Sicherheit Falls die M glichkeiten der deklarativen Sicherheit nicht ausreichen kann die programmatische Sicherheit zus tzlich verwendet werden Hierbei kann innerhalb einer Applikation auf die Sicherheitskonfiguration zugegriffen wer den Die API vom Tomcat Container bietet die Funktionen getRemoteUser isUserInRole und getUserPrincipal Uber diese Funktionen hat der Pro grammierer die Moglichkeit eigene Sicherheitsfunktionen einzubauen Diese betreffen dabei aber nur die Zugriffskontrolle da die Authentifikation wei terhin vom Tomcatserver bernommen wird 5 1 3 JAAS Das Java Authorization and Authentication Service JAAS Framework LGK 99 wurde von SUN 1999 spezifiziert Dieses Framework ist eine Erweiterung der Authentifikations und Autorisationsm glichkeiten f r Java
35. cccp boca way wR SS 39 5 Beispiel f r before Advice e 40 6 Beispiel f r before Advice e 40 7 Beispiel f r eine Introduction 40 8 Beispiel f r eine Compile Time Declaration 40 9 LOPERA MES o ic a Bk wa eee NR a 42 10 authentication Aspect s ceid eda da idioat dianik 42 11 Keine log Befehle Aspect 43 12 nderungen an der build xml 2 2 6 45 8400 005403 44 13 nderungen an der web xml 44 14 Compilerparameter ia se ss urls a a 45 15 Beispiel eines XSS Angriffs a oa aaa T2 16 Beispiel eines SQL Injection Angriffs 12 17 nderungen an der server ml 92 18 Definition von Zust nden 2 cc u css ds 94 19 Definition eines bergangs 94 20 Definition eines Benutzers o 95 21 Aufruf der Authentifikation 00 99 22 Aufruf der Authentifikation oaoa 99 23 Kontrolle der Autorisation 100 24 Auszug aus dem securityMonitor oaao 104 25 nderungen an der web xml 104 26 nderungen an der web xml 105 27 Auszug aus der sourceid sso xml 2 222 222 22 nenn 107 28 nderungen an der server xml 0 0 00 een 109 29 nderungen an der struts config xml 22 2 222 2 110 30 nderungen an einer JSP Seite o onen 110 31 nderungen an der struts config xml 22 2 2222 110 32 Auszug aus der sourceid sso xml 2 2 2 22 22 een 115 33 Anderung an der serverxml ENEE AN RS 116 34 nderung
36. dass die Daten die dem HTML Form bergeben werden ungefiltert an die Applikation weitergereicht werden Die Eingabe von or 0 0 kann somit zu folgender resultierender SQL Abfrage f hren Select count from users where username or 0 0 and password limit 1 Listing 16 Beispiel eines SQL Injection Angriffs Da das eine SQL Abfrage an dieser Stelle beendet und der String somit nicht mehr vollst ndig ausgewertet wird hat sich der Angreifer erfolgreich an dem Server angemeldet In Woe04 wird das Thema ausf hrlich disku tiert Command Injection Bei diesem Angriff wird der Server dazu gebracht an der Shell Befehle auszuf hren Dieses Problem kann in jedem Programm gefunden werden dass auf Kommandozeilenprogramme zur ckgreift Im Tomcatumfeld tritt dieses Problem nicht auf solange nicht CGIServlet verwendet wird oder die Applikation selber entsprechende Tools verwendet 6 SERVERABSICHERUNG 73 Als ein gutes Mittel gegen diese Angriffe wird in JF03 das HTTP Request Fil tering angef hrt Hierbei wird die Interaktion zwischen Server und Client kon trolliert unter Verwendung der Tomcat Valves vgl Fou04a Es ist nat rlich auch m glich eine entsprechende Kontrolle in AspectJ zu implementieren Ein Ansatz der hier Verwendung finden kann ist ein modifizierter HTMLRewriter der im Kapitel 8 7 vorgestellt wird Die Idee ist es einen Filter vor die Methoden doGet doPost und doPut zu setzen so dass d
37. den Benutzer informiert 7 2 Feinkonzepte Im Folgenden werden einige Details des vorgestellten Konzepts n her betrachtet Das Sicherheitsmodul wird durch den Security Aspect in AspectJ vgl Kapitel 3 implementiert Ver nderung der Wirtsapplikation Jede Kommunikation der Wirtsapplika tion wird durch die in dieser Diplomarbeit entwickelten Aspecte verarbeitet Die benutzerseitigen Eingaben werden wie in Abbildung 22 zu sehen durch den Se curity Aspect behandelt Die durch die Wirtsapplikation erzeugten Antwortseiten werden durch den HTMLRewriter bearbeitet 7 KONZEPT UND SICHERHEITSBETRACHTUNG 81 Abbildung 22 Aspecte verbunden mit der Wirtsapplikation Wirts applikation n ZS Oo G J JUM HTNWLH Zusammenspiel des Sicherheitsmoduls mit der Wirtsapplikation In Abbildung 23 wird die Kommunikation skizziert die bei der ersten Anmeldung am zu sch tzenden Programm stattfindet Es ist zu sehen dass jeder Kontakt durch den securityAspect entgegengenommen wird Dieser entscheidet ob eine Authentifikation oder Reauthentifikation ben tigt wird und ob der Zugriff auf das zu sch tzende System gew hrt wird Die genauen Abl ufe die f r die Durch Client securityAspect IDP Webapplikation i I L HTTP Request Redirect zum IDP HTTP Request 1 gt Frage nach Name und Passwort l bermittlung der Eingaben I I Redirect zur Applikation du d I HTTP Request _1 _
38. dienen in dem die ausgew hl ten Artikel gespeichert werden k nnen Cookies dienen einem Server somit zur Speicherung von Zustandsinformationen auf der Browserseite Allerdings sind viele Browser aus sicherheitstechnischen Gr nden so konfigu riert dass sie Cookies entweder berhaupt nicht zulassen oder nur auf den Server beschr nken der das Cookie gesetzt hat Diese Beschr nkung basiert dabei auf dem DNS Namen des Servers Somit ist es nicht m glich dass ein zweiter Server mit einem anderen DNS Namen auf das Cookies zugreifen kann Wenn es in ei nem Circle of Trust mehrere IDPs gibt k nnte man in einem Cookie speichern welcher IDP vom Benutzer bevorzugt wird Dieses Problem wird als das Introduc tion Problem bezeichnet siehe LAPOSc Da aber ein Cookie nicht von einem zweiten Server mit unterschiedlichem DNS Namen gelesen werden kann kann ein zweiter SP nicht von einem anderen SP erfahren welcher IDP der Standard IDP des Benutzers ist Eine M glichkeit dieses Problem zu l sen ist dass alle Dienste in dem Circle of Trust eine Unterdomains zu einer gemeinsamen Hauptdomain besitzen Also z B car airline com und room airline com Somit k nnte ein ge meinsames Cookie unter airline com angemeldet werden auf das alle zugreifen k nnen Da aber mittlerweile die Internetadresse ein fester Bestandteil einer Fir ma ist kann man nicht davon ausgehen dass die Dienste in einem Circle of Trust unter einer Hauptdomain zusammenfassbar sind
39. doi acm org 10 1145 644527 644533 Ram98 Raghu Ramakrishnan Database management systems McGraw Hill Inc 1998 Rob04 Paul Roberts Vendors team on WS Federation standard 2004 URL http www infoworld com article 04 05 25 HNwsfed_1 html 142 RWO03a R W03b RWL 00 San98 SBWo1 SCFY96 Sch03 Sch04 SLZ 04 SNS88 S004 sou03 SPP 04 S875 SS96 sso1 SSLOA ST85 J Rouault und T Wason Liberty Bindings and Profiles Specification 2003 URL http www projectliberty org specs R Wright 2003 CSI FBI computer security survey 2003 URL http www security fsu edu docs FBI2003 C Rigney S Willens Livingston A Rubens Merit W Simpson und Daydreamer RFC 2865 Remote Authentication Dial In User Service RADIUS 2000 URL http www faqs org rfcs rfc2865 html R Sandhu Role based access control In Advances in Computers Jgg 46 Seiten 237 286 M Zelkowitz Eds Academic 1998 Anjana Susarla Anitesh Barua und Andrew B Whinston Myths about Outsourcing to Application Service Providers 2001 R Sandhu E J Coyne H L Feinstein und C E Youman Rolebased access control mo dels IEEE Computer Volume 29 1996 Fred B Schneider Least Privilege and More j EEE SEC PRIV 1 5 55 59 September Oktober 2003 URL http csdl computer org comp mags sp 2003 05 j5055abs htm http csdl computer org d1 mags sp 2003 05 j5055 pdf Marc
40. erreicht werden kann Dies k nnen doppelte Netzger te sein RAID Strategien bei den Festplatten siehe BDR86 bis hin zu doppelten Ser vern die eine failover Strategie besitzen Dies wird zum Beispiel vom Linux High Availability Project Pro85a als Ziel verfolgt Der Standort des Servers sollte trocken sein und keine Wasserleitungen oder hnliches in der N he haben Daneben sollte auch an Brandschutzma nahmen eine Notstromversorgung physikalische Barrieren und hnliches gedacht werden Eine ausf hrliche Betrachtung der Standortproblematik findet sich im sp ter vor gestellten Grundschutzhandbuch des BSI f5id103b Wichtig in einem Schadensfall ist es dass eine klare Kompetenzenverteilung besteht die sicherstellt dass das System schnellst m glich wieder einsatzbereit ist Ein anderer wichtiger Punkt ist die Regelung des Zutritts zu den Servern Ein direkter physikalischer Zugriff stellt eine gro e Gefahr f r die Verf gbarkeit und Integrit t des Dienstes dar Zum Einen besteht die Gefahr der physikalischen Be sch digung bzw Zerst rung der Hardware aber auch des Diebstahls der Hardware oder der Daten die auf der Hardware gespeichert sind Nicht vergessen werden darf die Manipulation von Hardware Software und Daten Aus dieser Betrach tung ergibt sich die Notwendigkeit einer Zutrittsbeschr nkung zu den R umen in denen sich die Hardware befindet 70 6 2 Sicherheitsma nahmen auf Betriebssystemebene Die Ma nahmen
41. ist vgl Kapitel 10 Da die ben tigten Daten zur Verschl sselung bzw das Ergebnis ber das Internet bertragen werden ist es sinnvoll diese Daten mit einer Kanalverschl s selung abzusichern siehe Seite 107 damit kein Angreifer in den Besitz von Klartext Kryptotext Paare kommt und einen known plaintext Angriff durchf h ren kann Die Integration des Wibu Keys im Identity Provider wird im Prinzip ber zwei Webseiten bzw zwei Action Classes get tigt Die erste Action Class logi nAction java generiert die beiden zuf lligen Werte Diese beiden Werte und die Parametern User Code und Firm Code werden der JSP Seite logonWibukey App let jsp bergeben in der das Applet eingebettet ist Das Applet l st nach dem Verschl sseln der RAND eine Weiterleitung zu der responseAction java aus und bergibt dieser das Ergebnis Hier wird auf Seiten des Servers die API des Wibu Keys mit den gleichen Parametern aufgerufen und die beiden Ergebnisse vergli chen Falls das Ergebnis positiv ist wird ein AuthnContext Object siehe Kapitel 2 4 erzeugt und der Service Provider mit diesem Object ber die Art der erfolg ten Authentifikation benachrichtigt 8 9 1 Wibukey Applet Das Applet WibukeyApplet java ist wie schon beschrieben in die JSP Seite logonWibukeyApplet jsp eingebettet Das Applet bekommt als Parameter alle n tigen Informationen bergeben Das bertragen des Applets bzw der JSP Seite wird nur mittels Kanalabsicherung SSL vom Iden
42. liefert die Datenbasis der Authentifika tion Die zweite wird vom SecurityAspect bzw dem Referenzmonitor verwendet und liefert alle Informationen die der Authorisation Reauthentifikation sowie der Anmeldung am Wirtssystem dienen Diese Datenbanken sind getrennt da sie getrennten Aufgaben dienen und auch auf weit entfernten Rechnern liegen Desweiteren kann sich die Administration des IDP dem SP entziehen so dass hier auch eine klare Trennung von Verantwortlichkeiten n tig ist Die verwendete Datenbankstruktur auf die der Sicherheitsmonitor zur ck greift wird in der Abbildung 29 dargestellt Abbildung 30 zeigt die Tabelle die verwendet wird um die Informationen f r eine Anmeldung eines Benutzers an der zu sch tzenden Applikation zu verwahren Alle angelegten Tabellen sind bis auf userState sessionId und FSMState als nur lesend zu verstehen Somit teilt sich die Verwendung in die Repr sentation der User Rollen und Workflows sowie in die persistente Speicherung des Zustandes jeder aktiven Session Ein Workflow wird in der Datenbank durch die Tabellen workflow workflow States und actionClass dargestellt Jeder Workflow besitzt einen Namen und eine ID zu der dann durch workflowStates die Zust nde eines Workflows zugeordnet werden Es existiert f r jeden Constraint eines bergangs aus einem Zustand in einen Folgezustand eine Zeile in der Tabelle Der aktuelle Zustand wird in der FSMState erfasst in der zu jeder Sessionld gespeic
43. lt xsd element name applicationPassword type xsd string minOccurs 0 maxOccurs 1 gt lt xsd element name sp type xsd string minOccurs 1 maxOccurs 1 gt lt xsd element name idpNameldentifier type xsd string minOccurs 1 maxOccurs 1 gt lt xsd element name spNameldentifier type xsd string minOccurs 1 maxOccurs 1 gt lt xsd sequence gt lt xsd attribute name name type xsd string gt lt xsd complex Type gt userType gt Listing 20 Definition eines Benutzers Das Bindeglied von Workflows und Benutzern sind die Rollen Eine Rolle be steht aus einem Namen und den Workflows die zu dieser Rolle zusammengefasst werden Der Zusammenhang zwischen Benutzer Rolle Workflow und den Authentifi kationsmethoden und Authentifikationsdaten wird in Abbildung 28 dargestellt authentic ation methods User assignment Workflow assignment authenti cation values Abbildung 28 Zusammenhang von Usern Rollen und Workflows Im applikationsspezifischem Bereich ist hinterlegt wo die Basisseite der Applikation zu finden ist Hierzu wird die URL der Seite verwendet Ausserdem finden sich dort die Parameternamen in denen der Applikationsbenutzername und das dazugeh rige Passwort vom Logindialog der Applikation erwartet wer den 8 3 Sicherheitsdatenbank Der in 8 6 beschriebene Sicherheitsmonitor ben tigt eine globale Datenquelle auf deren Basis er seine Entscheidungen tri
44. mit unzurei chender Vertrauenswiirdigkeit dar Darauf aufbauend definieren sich die h heren Stufen El Die Sicherheitsanforderungen miissen formuliert sein Es muss eine Sicher heitsstrategie existieren und die Bedrohungen fiir das System sind erfasst E2 Es wird eine Testdokumentation gefordert und eine Bewertung der Tests im Hinblick auf die geforderten Sicherheitsanforderungen E3 Es werden strengere Anforderungen an die Implementierung gestellt Es muss der Zusammenhang zwischen der Implementierung und dem Feinentwurf hergestellt werden E4 Ein formales Sicherheitsmodell der Sicherheitseigenschaften wird gefordert Ausserdem muss der Architekturentwurf und der Feinentwurf in einer se miformalen Notation beschrieben sein E5 Ab dieser Stufe wird eine erkl rende Dokumentation des Systems gefordert Es muss der Zusammenhang zwischen Quellcode und dem Feinentwurf er kl rend dargestellt werden E6 F r die h chste Evaluationsstufe werden mathematisch fundierte Beweisver fahren gefordert Neben der Stufe ist noch die Qualit t entscheidend Diese wird in niedrig mittel und hoch eingestuft Somit wird ein System durch ein Paar welches aus Evalua tionsstufe und Qualit t besteht beurteilt 7 KONZEPT UND SICHERHEITSBETRACHTUNG 77 7 Konzept und Sicherheitsbetrachtung Die in den vorherigen Kapiteln vorgestellten Techniken sollen innerhalb eines Gesamtkonzeptes miteinander verbunden werden so dass eine beliebige in Ja va pr
45. response request return null Listing 23 Kontrolle der Autorisation Um den Benutzer vor einem doppelten Login zu bewahren am IDP und an der Applikation meldet der SecurityAspect den authentifizierten Benutzer an der Wirtsapplikation an Hierzu ist in der Datenbank hinterlegt welcher Benutzer name und Passwort gegen ber der Applikation f r diesen Benutzer verwendet werden muss Desweiteren ist hinterlegt in welchen Parametern diese Daten ber geben werden m ssen In Abbildung 33 wird die Abfolge der beschriebenen Prozesse dargestellt Bei jedem Zugriff auf den Server durch den Benutzer wird zuerst der Referenzmonitor gestartet Falls dies nicht m glich sein sollte und dieser einen Fehler bergibt wird direkt der weitere Ablauf unterbunden und eine Fehlerseite erzeugt Grund hierf r kann in der aktuellen Implementierung haupts chlich ein Fehlen der Datenbank sein Direkt darauf wird gepr ft ob der IDP einen Fehler zur ckgegeben hat securityAspe ct Einstieg 8 SPEZIFIKATION UND IMPLEMENTIERUNG DP Fehler Neln liegt vor Ja zur ck zur Ja BasePagg Nein existiert bin Nein Benutzema me Si Hardwaretoken Reauthentifikation ApplicationLogin Zugriff erlaubt Nein Methode Workflowreset Fehler webseite Redirect und SourcelD gt Fehler webseite ausf hren Abbildung 33 Flussdiagram
46. schl sseln und an die Authentifikationsdaten des Benutzers zu kommen Um am Tomcat Server die Benutzung von SSL zu aktivieren m ssen mehrere Vorbereitungen getroffen werden Als erstes muss in der Datei server xml der Connector f r SSL aktiviert werden Dies wird durch das Einf gen des in Listing 28 gezeigten Connectors realisiert lt Connector port 8443 maxThreads 150 minSpareThreads 25 maxSpareThreads 75 enableLookups false disableUploadTimeout true acceptCount 100 debug 0 scheme https secure true clientAuth false sslProtocol TLS keystoreFile keystore gt Listing 28 nderungen an der server xml Wichtig dabei ist die Angabe des Ports und des keystoreFile Als Port wurde im Demonstrator nicht der SSL Standardport 443 verwendet sondern der Port 8443 Die Angabe des keystoreFile zeigt auf die Datei die die zur SSL Authentifikation verwendeten Schl sselpaare enth lt Hier wurde ein selbstsigniertes Zertifikat ver wendet Anleitungen zum keystoreFile sind in Hor04 und Pro04 zu finden Mit dem Hinzuf gen dieses Connectors ist es prinzipiell m glich alle Kommunika tion zwischen einem Client Rechner und einem Tomcat Server sowohl ber das normale HTTP Protokoll als auch ber SSL abgesichertes HTTP Protokoll ab zuwickeln Um sicherzustellen dass die bertragung der Webseiten des Identity Provi ders per SSL abgesichert sind wird bei dem Demonstrator sslext SSL04 ver wendet Dies ist eine Erwei
47. sselnamen sowie einem zugeh rigen Wert und stellt direkt die Eingaben des Benutzers an der Browseroberfl che dar Diese Parameter stellen somit die Eingaben an die Applikation dar und ver ndern den Zustand der zu sch tzenden Applikation Der SecurityAspect erweitert den normalen Ablauf der Applikation um die Autorisation Authentifikation dem Anmelden des Benutzers bei der Applikation sowie die M glichkeit Autorisations und Authentifikationsfehler abzufangen und 8 SPEZIFIKATION UND IMPLEMENTIERUNG 99 SecurityAspect Originalmethode Abbildung 32 Der Securityaspect umhiillt die Methoden dem Benutzer anzuzeigen In einem begrenzten Rahmen kann der Benutzer auch auf einen Fehler reagieren Die Authentifikation wird durch einen Aufruf des IDP realisiert wie in Lis ting 21 dargestellt wird Falls noch kein Benutzer durch SourcelD gesetzt wurde wird ein Forward an die authnRequest Klasse durchgefiihrt vgl Kapitel 2 6 Die se f hrt dann eine Authentifikation des Benutzers wie in Kapitel 2 3 beschrieben durch user String session getAttribute org sourceid sso userID if user null callPasswordIDP session request response return null Listing 21 Aufruf der Authentifikation Im Listing 22 werden verschiedene Attribute definiert und dann als authnRequest an den IDP weitergeleitet Nach dem Zur ckkommen sind verschiedene Werte im response Object fest gesetzt so dass es hier n tig ist den Ablauf zu
48. symmetrischen Kryptosystemen ist dass ein Server der Verifier der f r die Authentifikation zust ndig ist alle Schl ssel der beteiligten claimants speichern muss Dieser Server ist deshalb besonders gegen Angriffe abzusichern Asymmetrische Kryptosysteme oder auch Public Key Kryptosysteme ba sieren auf zwei Schl sseln einen ffentlichen und einen geheimen Privaten Diese 64 haben die Eigenschaft dass alle Offentlichen frei zur Verfiigung gestellt sind und die Privaten geheim sind und man aus dem ffentlichen nicht ohne sehr gro en Aufwand auf den Privaten schlie en kann So gibt es nicht wie bei der symmetri schen Kryptographie ein gemeinsames Geheimnis das auf beiden Seiten gesch tzt werden muss und die geheimen privaten Schl ssel m ssen auch nie bertragen werden Au erdem ist es nur dem Besitzer des privaten Schl ssels m glich eine mit dem ffentlichen Schl ssel verschl sselte Nachricht zu entschl sseln Weiter hin kann auch ein Signieren einer Nachricht stattfinden indem eine Nachricht mit dem privaten Schl ssel verschl sselt wird und jeder der im Besitz des passenden ffentlichen Schl ssels ist kann die Nachricht entschl sseln und wei dass nur der jenige im Besitz des privaten Schl ssels die Nachricht verschl sseln konnte Die Authentifikation bei einem asymmetrischen Kryptosystem l uft dabei so ab dass der Verifier dem Claimant eine Zufallszahl schickt und der Claimant diese Zufall zahl mit seinem
49. und e Vertraulichkeit gemacht werden Das Sicherheitssystem von Tomcat ist Benutzer Rollen basiert Ein Benutzer kann zu mehreren Rollen geh ren als auch eine Rolle mehrere Benutzer bein halten Die Benutzernamen und Rollen werden in den Konfigurationsdateien an gegeben Da die Benutzer und Rollen f r alle Applikationen die innerhalb eines Tomcat Containers laufen gelten wird ein Single Sign On System definiert cat Zu einer Webapplikation k nnen Sicherheitskriterien passend zu den Rollen und Benutzern festgelegt werden Die Authentifikation sowie die Zuordnung eines Be nutzer zu einer Rolle wird vom Tomcatsystem bernommen 5 1 1 Authentifikation In der Java Servlet Spezifikation Cow01 ist angegeben dass es 4 M glichkeiten gibt wie sich ein Benutzer authentifizieren kann Diese sind e HTTP Basic Authentication e HTTP Digest Authentication e Form Based Authentication 60 e HTTPS Client Authentication Das HTTP Basic Verfahren ist ein sehr einfaches Authentifikationsverfahren das in der HTTP 1 0 Spezifikation BLFF definiert ist Der Web Browser des Be nutzers fragt nach Aufforderung des Servers den Benutzer nach Benutzernamen und Passwort Das Ergebnis wird dann vom Browser im Klartext an den Ser ver geschickt Diese Art der Authentifikation ist nicht sehr sicher Man k nnte zwar durch die Benutzung einer Kanalabsicherung wie HTTPS verhindern das die Antwort im Klartext bertragen wird allerdings werden Benutzer
50. wird die Ausf hrung der Methode gekapselt Call Hier sind alle Methoden selektiert welche eine bestimmte Methode aufru fen Im Unterschied zum vorherigen Join Point wird jetzt nicht die Methode an sich sondern ihre Aufrufe gekapselt Constructor Beim Constructor Join Point handelt es sich um einen Call oder Execution Join Point der auf den Constructor einer Klasse angewendet wird 3 ASPEKTORIENTIERTE PROGRAMMIERUNG 39 Field Access Ein Join Point der die Lese und Schreibzugriffe auf eine Spei cherstruktur kapselt Exception Handler Execution Dieser liegt vor wenn der Code eines Error handlers gekapselt wird Class Initialization Um Aktionen zum Ladezeitpunkt einer Klasse einzuweben kann der Class Initialization Join Point verwendet werden Object Initialization Zum Zeitpunkt der Initialisierung also der Erzeugung einer Klasse greift dieser Join Point Object Pre Initialization Kurz bevor eine Klasse erzeugt wird wird dieser Join Point gesetzt Normalerweise ist dies der Zeitpunkt wenn super Aufrufe stattfinden Advice Execution Um einen Advice als Ausf hrungszeitpunkt eines Advices zu erfassen kann dieser Join Point verwendet werden R Laddad zeigt in Lad03 S 50 weitere Beispiele und Anwendungsm glichkeiten der verschiedenen Join Points Pointcut Durch einen Pointcut wird ein spezieller Join Point im Programm ablauf definiert und mit einem Namen versehen Ein Join Point besteht aus einem Pointcut Type
51. 09Certificate xmlns ds http www w3 org 2000 09 xmldsig gt MIICaDCCAd O lt ds X509Certificate gt lt ds X509Data gt lt ds KeyInfo gt lt lib AssertionConsumerServiceURL gt http localhost 8080 jpetstore sso authnRequest lt lib AssertionConsumerServiceURL gt 2 SINGLE SIGN ON 33 lt lib SoapEndpoint gt http localhost 8080 jpetstore sso soap endpoint lt lib SoapEndpoint gt lt lib SingleLogoutServiceURL gt http localhost 8080 jpetstore sso logout lt lib SingleLogoutServiceURL gt lt lib SingleLogoutServiceReturnURL gt http localhost 8080 jpetstore sso logout lt lib SingleLogoutServiceReturnURL gt lt lib FederationTerminationServiceURL gt http localhost 8080 jpetstore sso fedterm lt lib FederationTerminationServiceURL gt lt lib FederationTerminationServiceReturnURL gt http localhost 8080 jpetstore sso fedterm lt lib FederationTerminationServiceReturn URL gt lt lib SPDescriptor gt Listing 2 Auszug aus der sourceid sso providers xml Wie in Listing 2 zu sehen werden die eindeutigen Namen der Partner mit dem Punkt lt lib ProviderID gt sowie deren ffentlichen Schl ssel ihrer Zerti fikate unter lt ds KeyInfo gt gespeichert Au erdem werden die Adressen der Schnittstellen der beteiligten Partner gespeichert Somit ist sichergestellt dass keine unautorisierte Person sich als ein Beteiligter des Circle of Trust ausgeben kann da zu jedem beteiligtem Partner dessen ffentli
52. 1145 332833 332837 Inc Tripwire Tripwire 2004 URL http www tripwire org Alexandre Vasseur Aspectwerkz Website 2004 URL http aspectwerkz codehaus org J Vollbrecht P Calhoun S Farrell L Gommans G Gross B de Bruijn C de Laat M Holdrege und D Spence RFC 2904 AAA Authorization Framework 2000 URL http www faqs org rfcs rfc2904 html Markus Voelter Aspectj Oriented Programming in Java 2000 URL http www voelter de data articles aop aop html Marko Vogel Identity management Kosten und Nutzen D A CH Security 2004 Giovanni Vigna Fredrik Valeur und Richard A Kemmerer Designing and implemen ting a family of intrusion detection systems In Proceedings of the 9th European soft ware engineering conference held jointly with 11th ACM SIGSOFT international sym posium on Foundations of software engineering Seiten 88 97 ACM Press 2003 URL http doi acm org 10 1145 940071 940084 W3C Simple Object Access Protocol SOAP 1 1 2000 URL http www w3c org TR SOAP w3c XML Schema 2004 URL http www w3 org XML Schema the free encyclopedia Wikipedia Three tier computing URL http en wikipedia org wiki Three tier_ computing Bart De Win Wouter Joosen und Frank Piessens AOSD amp Security a practical assess ment February 28 2003 Thomas Woelfer Cross Site Scripting und SQL Injection 2004 URL http www tecchannel de internet 1423 1 html
53. Ablauf gezeigt Dort wird bereits in Betracht gezogen dass das System sp ter den eigentlichen Methodenaufruf kapselt also test rigths als Zustand eingef hrt wird Formal beschrieben besitzt Abbildung 18 Beispielworkflow das RBAC96 Modell folgende Komponenten U Menge von Benutzern R Menge von Rollen P Menge von Rechten UA CU x R Zuordnung User Rollen RH C R x R partielle Ordnung auf den Rollen lt PAC Rx P Zuordnung Rollen Rechte permissions R 2P jeder Rolle r wird eine Menge von Rechten zugeordnet permissions R 2 erweiterte Relation um Rollenhirarchie permissions r p P p ri PA permissions r p P ar lt ri p r PAJ In K502 wird diese grundlegende Definition in zwei Stufen erweitert um Workflows und States verwenden zu k nnen In der ersten Erweiterung werden die sog Tasks eingef hrt die den Workflows entsprechen Zu diesen Tasks wer den Operationen definiert In dieser Erweiterung ist lediglich ein Ausf hren als Operation sinnvoll Neben den Tasks gibt es noch die Instanzen der Tasks sowie eine Abbildungsfunktion S die den Zusammenhang zwischen den Tasks und den Instanzen herstellt Das Modell das sich aus diesen Voraussetzungen ergibt sieht wie folgt aus 56 U R RH UA werden unver ndert aus der RBAC96 Definition ber nommen OP execute TT Menge von Tasks Workflows TI Menge von Instan
54. Applikationsserver und der Applikation dar durch die die Be nutzereingaben der Applikation bergeben werden Innerhalb des Aspectes werden alle Aktionen die zur Authentifikation und Autorisation notwendig sind ausgel st und soweit es im SecurityAspect m glich ist auch durchge f hrt e Feststellen ob sich der Benutzer bereits angemeldet hat Falls dies nicht passiert ist wird der Benutzer an den IDP weitergeleitet e Den Benutzer bei der Applikation anmelden e Feststellen ob eine Reauthentifikation n tig ist e Kontrollieren ob die vom Benutzer gew nschte Aktion zul ssig ist HtmlRewriter Dieser Aspect wie er auf Seite 104 beschrieben wird dient der dynamischen Einbettung der Debuginformationen sowie des ProAktivApp lets in eine erzeugte Webseite Dazu ver ndert der Aspect die durch die JSP Klassen der Wirtsapplikation erzeugten HTML Seiten Identity Provider Der Identity Provider ist ein Single Sign On Server und stellt die Dienste im Rahmen des Frameworks f r die Authentifikation eines Be nutzers zur Verf gung Dieses Framework wurde durch folgende Module aufgebaut bzw erweitert so dass spezielle Authentifikationsverfahren zur Verf gung stehen sowie ein proaktives Verfahren welches den Benutzer an seinen Hardwaretoken erinnert e Integration eines Identity Providers in eine Struts Umgebung Seite 105 e Einbindung einer Kanalabsicherung Seite 107 e Einbindung des Wibukeys als Authentifikationsverfahren Sei
55. Aspect in AspectJ formuliert werden Es wurde davon Abstand genommen da die rechtliche Betrachtung dieses Themenkomplexes au erhalb des Fokus dieser Diplomarbeit liegt Tech nisch gesehen ist dieses Logbuch lediglich eine Tabelle in der Datenbank in der zu dem Benutzernamen die Eingaben mit den entsprechenden Klassen gespeichert werden Komplexer ist es auf diesem Logbuch Auswertungen ber das Benutzerverhalten durchzuf hren Insbesonere k nnte man Aus wertungen ber die zeitliche Dauer eines Workflows sowie die bearbeiteten Workflows eines Benutzers anstellen Zus tzlich k nnte man aus den Auf zeichnungen Auswertungen ber die ausgef hrten Workflows machen um somit die darunterliegende abgesicherte Software zu optimieren Chinese Wall Ein Benutzer kann beliebig h ufig an dem System angemeldet sein und auch unterschiedlichste Aufgaben ausf hren Chinese Wall bedeu tet hier eine dynamische Begrenzung dieser Freiheit In einer komplexeren Beschreibungssprache k nnten hierf r Anforderungen eingef gt werden so dass ein Mitarbeiter sich z B nur einmal anmelden oder immer nur Vor g nge einer Firma bearbeiten darf Validierung der Methodenaufrufe Der SecurityAspect dieser Diplomarbeit stellt in seiner jetzigen Form ein Schutz in der Breite dar Es wird jeweils 10 FAZIT UND AUSBLICK 129 die ActionClass des Struts Framework gekapselt die die weiteren Aktionen auf die Eingabe ausl st Ein erg nzendes Modell k nnte hier ansetzen
56. Der entsprechende Aspect wird in Listing 11 gezeigt import java util logging public aspect DetectLogUsage declare warning call void Logger log Consider_Logger logp _instead Listing 11 Keine log Befehle Aspect Dieser Aspect hat zur Folge dass bei der Compilation des Systems f r jede Ver wendung des log Befehls eine Warnung erzeugt wird In Lad03 werden weitere Beispiele hierf r vorgestellt 44 3 2 4 Exception Softening Ein weiteres Konzept ist das Exception Softening Java unterscheidet zwei Ka tegorien von Fehlern Bei einer checked Exception wird bereits zur Compilation kontrolliert ob dieser Fehler abgefangen oder explizit ber den throw Befehl weitergereicht wird Eine unchecked Exception hingegen kann nicht daraufhin berpr ft werden Sie ist von Typ RuntimeException oder Error und wird nicht explizit berpr ft durch den Compiler Exception Softening erlaubt es Exceptions zu verwenden ohne diese in der Methode in der der Fehler entsteht behandeln zu m ssen 3 3 Verwendung in Ant Ein automatisches Weaven innerhalb eines Ant Build Prozesses ist m glich in dem der normale Java Compiler durch durch den AspectJ eigenen Compiler aus getauscht wird Dies erfordert lediglich wenige Zeilen in der build xml die in Lis ting 12 gezeigt werden Nun kann als Compilertag auch iajc verwendet werden welches den AspctJ Compiler ajc als Compiler aufruft lt taskdef resourc
57. Dieses Verfahren vergleicht das zu schiitzende Teilsystem mit Musterl sungen die sich fiir hochschutzbediirftige Systeme etabliert haben Im GSHB f5id103b wird ausgef hrt Typische h herwertige Ma nahmen im Bereich der IT Systeme sind der Einsatz von zertifizierten Betriebssystemen oder von spe ziellen Sicherheitsversionen der Betriebssysteme der Einsatz von Authentisierungstoken oder sogar die Isolation der IT Systeme Im Bereich der Kommunikationsverbindungen kommen beispiels weise folgende h herwertige Ma nahmen zum Einsatz Kappung von Au enverbindungen Leitungs oder Ende zu Ende Verschl s selung gepanzerte Kabeltrassen oder druck berwachte Kabel redundante Kommunikationsstrecken oder redundante Kabelf h rung sowie Einsatz von mehrstufigen Firewalls kombiniert mit In trusion Detection Tools Im Bereich der infrastrukturellen Sicher heit k nnen beispielsweise Vereinzelungsschleusen Brandl sch technik Video berwachung Zutrittskontrollsysteme und Einbruch meldeanlagen bis hin zu Backup Rechenzentren eingesetzt wer den Hierzu existieren Schutzklassenmodelle des BSI f r thematisch eingegrenzte Bereiche 76 Durch die Einf hrung der ITSEC Kriterien wurde ein harmonisiertes Regelwerk zwischen Gro britannien Frankreich den Niederlanden und Deutschland geschaf fen Es gibt sieben Evaluationsstufen EO bis E6 durch die der Grad an Vertrauen ausgedr ckt wird den ein System erreicht hat EO stellt ein System
58. Diplomarbeit Sicheres Outsourcing mit verteilten Webservices Konzepte der Zugriffskontrolle und ihre Umsetzung in aspektorientierter Programmierung Prof Dr Claudia Eckert Fachgebiet Sicherheit in der Informationstechnik Fachbereich Informatik Betreuer Dr Andreas U Schmidt Thomas Rauch Nicolai Kuntze 17 Februar 2005 Copyright 2005 Nicolai Kuntze Thomas Rauch Alle Rechte vorbehalten Gesetzt in Vorwort 3 Vorwort Im M rz 2003 wurde von Frau Prof Eckert und der Firma Guard24 eine Di plomarbeit ausgeschrieben deren Inhalt die Entwicklung und Umsetzung eines Sicherheitskonzepts fiir eine webbasierte ASP Logistiksoftware war Der Hinter grund dieser Ausschreibung war der Wunsch der Firma Guard24 eine neue Logis tiksoftware entwickeln zu lassen die alle Gesch ftsprozesse der Firma inklusive dem Kontakt zu Endkunden Logistikpartnern und andere Firmen umfassen soll Als Plattform wurde J2EE favorisiert und der Betrieb durch eine externe Server farm angestrebt Es sollte untersucht werden wie eine hohe Betriebssicherheit und ein optimaler Schutz der Daten erreicht werden k nnen unter Einbeziehung der hohen Anzahl an Schnittstellen zu Drittanbietern Von diesem Szenario ausgehend haben wir im April 2004 angefangen ein abstrahiertes Modell zu entwerfen und eine Sicherheitsarchitektur zu entwickeln Hierbei standen eine maximale Unabh ngigkeit des Entwurfs von der zu sch tzen den Applikation und eine hoh
59. E SIGN ON 27 SOAP Message Abbildung 5 Struktur einer SOAP SAML Nachricht AuthnContext Ein essentieller Bestandteil des Liberty Protokolls ist die ge naue Angabe der Authentifikationsmethode Diese Angabe muss sowohl vom Ser vice Provider als auch vom Identity Provider get tigt werden Der Service Pro vider gibt dem Identity Provider vor welche Authentifikationsmethoden er ak zeptiert Der Identity Provider w hlt sich aus den vorgegebenen Methoden eine Methode heraus und fiihrt diese mit dem Subjekt durch Der IDP muss dem SP in seiner Antwort genaue Angaben machen mit welcher Methode er das Subjekt authentifiziert hat Die Spezifikation dieser Authentifikationsmethoden ist in der Liberty ID FF Authentication Context Specification LAC03 des Liberty Proto kolls angegeben Diese Spezifikation soll es in erster Linie den Service Providern erm glichen die vom Identity Provider durchgefiihrte Authentifikationmethoden bewerten zu k nnen Der Identity Provider kann mit Hilfe dieser Spezifikation genaue Angaben ber den initialen Identifizierungmechanismus den eingesetzen Mechanismus zur Verhinderung von Kompromittierung von Berechtigungsnach weisen bzw die Art der Speicherung der Nachweise machen Au erdem k nnen genaue Angaben ber die Authentifikationsmechanismen und deren Absicherung gemacht werden Anhand dieser Angaben ist es dem Service Provider m glich eine Sicherheitsbewertung durchzuf hren inwieweit er der vom Identity Pr
60. IDP alle Dienste der f derierten SPs direkt nutzen Falls es transitive Beziehungen ber mehrere Circles of Trust gibt funktioniert simplified Sign On auch Da es zur Zeit im Kontext von Webservices normal ist sich ber eine Kombination aus Benutzernamen und Passwort zu authentifizieren liegt hierauf auch das Hauptaugenmerk des Liber ty ID FF Protokolls Liberty limitiert sein Protokoll dabei nicht nur auf diese Methode sondern hat das Protokoll f r weitere Wege der Authentifikation offen gelassen Single logout Das Liberty ID FF Protokoll bietet au erdem die M glichkeit des single logout Hierbei kann sich der Benutzer auf den Webseiten des gerade an gezeigten Providers ausloggen und ist automatisch bei allen Providern innerhalb des Circle of Trust abgemeldet Dies bringt den Vorteil dass sich der Benutzer zum Beenden seiner Sitzung nicht bei allen Service Providern einzeln abmelden muss Pseudonym Das Liberty ID FF Protokoll verwendet nicht wie viele andere Ans tze global eindeutige IDs zur Authentifikation sondern es werden Pseud onyme f r die Verkn pfung von Accounts verwenden Zwei Accounts bei unter 22 schiedlichen Providern eines Circle of Trust werden verkn pft indem beide Seiten jeweils ein beliebiges Pseudonym f r den Account generieren dieses unter dem jeweiligen Account lokal speichern und dem Gegen ber senden Somit muss im mer nur das Pseudonym bertragen werden und es sind nur die zwei beteiligten Prov
61. IS Inhaltsverzeichnis 1 Einleitung 2 Single Sign On 2 1 2 2 2 3 2 4 23 2 6 Identity Management in bisherigen Systemen Sekt NEL Pe soor A SS He AR BEE er 2 1 2 Web Services Federation Language WS Federation 213 BIDEN s s srs sg orati epii A AR chen ged e e e a E a AA E LS VARIO 644 2446 4464 priista MERA MOS 2 5 2 we ae oe He ee BOS ea ERA ee HS Schl sselkomponenten von Liberty Protokollauibau 24 0 o2hcec28c 654452 5h 248 8 Sicherheitsbetrachtung oaoa Source s s 2 4 a hear e a e ee A 3 Aspektorientierte Programmierung 3 1 3 2 3 3 3 4 3 5 3 6 The Sprache III SL Des RIIIE ler delia Der Weaver i cada pas En dee Einsatzbespiele 22 ccu o caeca snaga ade A ses mune eies ra rer ir 3 2 2 Sicherheit f r eine einzelne Anwendung 3 2 3 Policy Enforcement lt lt lt 3 24 Exception Serene c cs 44422 4454 trotes NOTICE A AA eS ER SE Integration in Tome cesae2P esa tees weeded es Vorteile und Probleme 2 2 624464444654 4485 Javosicherheit 6 4 za Ae eS ara 4 Referenzmonitor 4 1 4 2 4 3 4 4 Implementierung eines Referenzmonitors Sicherheitsstrategie o oa a a WOW o ccu so a a EE Kombination aus Workflows und RBAC 5 Authentifikation im Webumfeld 5 1 d Karte o nica gie a eee REE Ee ES 5 11 Authentifikation cs cv su raor er and ern 3 12 Zuprifisk ntrolle s e ed ese ee e
62. Integrit t auf der zweiten Strecke nicht gegeben ist Au erdem muss beachtet werden dass die Nachrich ten zwar auf dem Weg vertraulich und integer sind aber beim Client Browser umgepackt werden m ssen und somit hier offen sind Da wir f r diesen Demons trator selbstsignierte Zertifikate verwenden und SourcelD bei bertragung der 8 SPEZIFIKATION UND IMPLEMENTIERUNG 109 Nachrichten per SSL eine Uberpriifung des SSL Zertifikat vornimmt konnten wir den Austausch der Liberty Nachrichten nicht per SSL absichern Bei Verwendung von nicht selbst zertifizierten Zertifikaten deren Zertifizierungsstelle in der Java Zertifikatsdatenbank eingetragen ist sollte dieses Problem beseitigt sein Zur Absicherung der oben genannten Ubertragungen zwischen dem Identity Provider und dem Client Rechner wird in dem Demonstrator SSL verwendet Zu Anfang einer Kommunikation zwischen einem Client Rechner und dem Identity Provider wird die Authentifikationsm glichkeit von SSL verwendet Dies erm g licht dem Benutzer am Client Rechner die Identit t des Identity Providers zu berpr fen damit er nicht f lschlicherweise seine Authentifikationsdaten an Drit te tibermittelt Weiterhin ist durch die Kanalabsicherung zwischen dem Identity Provider und dem Client Rechner die Vertraulichkeit und Integrit t der Nach richten gew hrleistet Somit ist es einem Angreifer nur erschwert m glich die Datenpakete zwischen dem Client Rechner und dem Identity Provider zu ent
63. Internet Cafe Computer verwen den Die oben beschriebenen Single Sign On Protokolle basieren fast alle auf zu s tzlicher Infrastruktur Es m ssen extra Server aufgebaut und teilweise extra Cli entsoftware installiert sein um das entsprechende Protokoll abwickeln zu k nnen 18 Das Net Passport Protokoll funktioniert auf der Client Seite mit den Boardmit teln des Browsers ben tigt aber zwingend den Passport Server von Microsoft zur Authentifikation des Benutzers Das WS Protokoll erf llt viele der oben genann ten Punkte ist aber noch in der Entwicklungsphase und konkurriert mit bereits etablierten Protokollen Das Kerberos Protokoll ben tigt zur Kommunikation auf allen Seiten kompatible Software und ist somit nicht mit den Boardmitteln eines Browsers verwendbar Radius bietet zwar die M glichkeit einen Benutzer ber eine Webschnittstelle an einen Radius Server anzumelden allerdings ist es nicht speziell f r den Einsatz in Electronic Commerce Applikationen ausgelegt Auch verf gt es nicht ber die M glichkeit der Pseudonymisierung eines Benutzers Das Shibboleth Protokoll ist in einer rein webbasierten Umgebung lauff hig ist aber durch die starke Ausrichtung auf den universit ren Bereich nicht f r Electronic Commerce Applikationen geeignet Ein Protokoll das schon etabliert ist und den gesamten Anforderungskatalog aufgreift und umsetzt ist das Liberty Protokoll und wird im folgenden genauer erl utert 2 2 Liberty Alliance
64. J Saltzer und M Schroeder if a mechanism can provide firewalls the principle of least privileges provides a rationale for where to install the firewalls Unter Ber cksichtigung dieses Grundsatzes wurden verschiedene Sicherheitsmo delle entwickelt Die bekanntesten sind das hierarchisch rollenbasierte Modell RBAC das Chinese Wall Modell und Zugriffsmatrix Modelle wie z B Bell LaPadula Wir verwenden im Rahmen dieser Diplomarbeit das RBAC Role Based Ac cess Control Modell Dieses bietet verschiedene Vorteile gegentiber anderen Mo dellen Er ist durch die Trennung der Rechte von den Benutzern wesentlich fle xibler in seiner Anwendung und Rechte k nnen feingranular vergeben werden Ohne diese beiden Eigenschaften Flexibilitat und Feingranularitat besteht stets das Risiko das ein Benutzer mehr Rechte einger umt bekommt als dies vorgese hen ist vgl ANSI04 RBAC wurde erstmals 1992 von D F Ferraiolo und D R Kuhn in FK92 beschrieben Die Zuordnung der Benutzer zu den Rollen geschieht durch einen Administrator Eine Rolle wird in FK92 wie folgt beschrieben Roles are group oriented For each role a set of transactions al located the role is maintained A transaction can be thought of as a transformation procedure 1 a program or portion of a program plus a set of associated data items In addition each role has an associated set of individual members As a result RBACs provide a means of na ming and de
65. L abgesichert Das Applet greift ber TCP IP auf eine lokale Applikation zu die den Kontakt mit dem WibuKey herstellt Es muss berpr ft werden inwieweit eine externe Anwendung zugriff auf den TCP Port hat und welche Konsequenzen sich daraus ergeben siehe 8 9 1 Neben den Angriffspunkten auf das Konzept m ssen auch die verwendeten Tech nologien auf Schwachstellen untersucht werden werden In dem betrachteten Kon zept wird als Schl sseltechnologie die aspektorientierte Programmierung in Form 88 von AspectJ verwendet Eine Sicherheitsanalyse von AspectJ muss den Weg wie ein Aspect in ein Programm eingef gt wird und das Ergebnis dieses Deployments betrachten Bei der Betrachtung des Ergebnisses des Deployments k nnen die in Kapi tel 3 6 getroffenen Aussagen zur Sicherheit von Java herangezogen werden Ein Programm welches durch Aspecte ver ndert wurde ist wieder ein normales Java programm Dieses wird durch jede Java Konforme Laufzeitumgebung ausgef hrt und ben tigt an dieser keine speziellen Anderungen Somit bestehen alle Aussa gen zur Sicherheit von Java weiter Ein Programm wird in einer Sandbox isoliert ausgefiihrt und erh lt lediglich die Rechte auf Resourcen die explizit vergeben sind Dies setzt voraus dass der SecurityManager von Java aktiviert und kor rekt eingestellt ist Eine globale Freigabe aller Resourcen fiir alle Javaprogramme ist m glich und hebelt dieses Konzept aus Die Pr fungen ber die Korrektheit de
66. Limit von 2000 Euro besteht so muss dies als Regel definiert werden die die spezielle Eingabe 2000 Euro ersetzt Die spezielle Eingabe ist durch die exemplarische Benutzung erzeugt worden Als Mittel zur Formulierung dieser Regeln kommen regul re Ausdr cke zur Anwendung Weitere M glichkeiten ergeben sich durch eine Interaktion von Sicherheitsmo dul und Wirtsapplikation da hierdurch das Sicherheitsmodul auf interne Zust n de der Wirtsapplikation reagieren und in Abh ngigkeit von diesen Zust nden den Resourcenzugang beschr nken kann Gesamtkonzept Das Zusammenwirken der vorgestellten Komponenten wird in Abbildung 21 illustriert Der Identity Provider und das Sicherheitsmodul be 80 sitzen jeweils eine Datenbank die aus der durch die Trainingssuite erzeugten XML Daten erzeugt werden Die Aufgaben der Datenbanken teilen sich in die oben beschriebenen Bereiche Authentifikation und Autorisation Die Datenbank des IDPs tr gt alle Informationen die n tig sind einen Benutzer zu authentifizie ren In der Datenbank des Sicherheitsmoduls werden alle Daten gelagert die be n tigt werden um eine Authentifikation auszul sen und danach die Handlungen eines Benutzers kontrollieren zu k nnen Auf dem Client wird der Hardwaretoken Abbildung 21 Gesamtkonzept durch ein Applet angesprochen das den Kontakt mit dem IDP aufbaut Daneben wird noch ein zweites Applet gestartet welches die Proaktivit t des Systems zur Verfiigung stellt und
67. Mehrhoff Outsourcing unter Sicherheitsaspekten In D A CH Security 2004 Seiten 62 70 P Horster Hrsg 2004 E LITERATURVERZEICHNIS 141 Mel05 Ronald Melster Workflow Systeme 2005 URL http www software kompetenz de 13155 MKL97 Anurag Mendhekar Gregor Kiczales und John Lamping RG A Case Study for Aspect Oriented Programming 1997 URL http www2 parc com cs1l groups sda publications papers PARC AOP RG97 Mos03 Marie Luise Moschgath Sicherheitsmanagement Sommersemester 2003 2003 URL http www sec informatik tu darmstadt de de lehre SS03 sicherheitsmanagement in dex html MSS88 S Miyaguchi A Shiraisi und A Shimizu Fast data encryption algorithm Feal 8 Review of Electrical Communications Laboratories 36 4 433 437 1988 Mur90 Sean Murphy The Cryptanalysis of FEAL 4 with 20 Chosen Plaintexts J Cryptology 2 3 145 154 1990 URL http www isg rhul ac uk sean feal ps MWW 98 Peter Muth Dirk Wodtke Jeanine Weissenfels Angelika Kotz Dittrich und Gerhard Weikum From Centralized Workflow Specification to Distribu ted Workflow Execution J Intell Inf Syst 10 2 159 184 1998 URL http dx doi org 10 1023 A 1008608810770 NMMB04 James Noble Stuart Marshall Stephen Marshall und Robert Biddle Less Extreme Pro gramming In CRPIT 30 Proceedings of the sixth conference on Australian computing education Seiten 217 226 Australian Computer Society Inc 2004 OA94 Kazuo Oh
68. Sch nefeld Seitenkanalangriffe auf die Sicherheit von Javabasierten Softwarearchi tekturen In D A CH Security 2004 Seiten 341 348 P Horster 2004 O Slattery R Lu J Zheng F Byers und X Tang Stability Comparison of Re cordable Optical Discs A Study of Error Rates in Harsh Conditions 2004 URL http www nist gov public_affairs techbeat tb2004_1208 htm cddvd Jennifer G Steiner B Clifford Neuman und Jeffrey I Schiller Kerberos An Authenti cation Service for Open Network Systems In USENIX Winter Seiten 191 202 1988 Antti Salovaara und Antti Oulasvirta Six modes of proactive resource management a user centric typology for proactive behaviors In Proceedings of the third Nordic conference on Human computer interaction Seiten 57 60 ACM Press 2004 URL http doi acm org 10 1145 1028014 1028022 SourcelD Licensing 2003 URL http www pingidentity com license Hovav Shacham Matthew Page Ben Pfaff Eu Jin Goh Nagendra Modadugu und Dan Boneh On the effectiveness of address space randomization In Proceedings of the 11th ACM conference on Computer and communications security Seiten 298 307 ACM Press 2004 URL http doi acm org 10 1145 1030083 1030124 JEROME H SALTZER und MICHAEL D SCHROEDER The Protection of Information in Computer Systems 1975 URL http web mit edu Saltzer www publications protection Ravi Sandhu und Pierangela Samarati Authentication access con trol and audit ACM Comput
69. Schnittstelle des Servers so zu belasten dass die regul ren Dienste nicht ausgefiihrt werden k nnen Die Daten der Server werden in diesen Szenario nicht ber hrt allerdings ist der Dienst nicht zu erreichen Falls auf diesem Weg der IDP unbrauchbar gemacht wird so k nnen auch alle Dienste die diesen verwenden nicht benutzt werden IDP security Aspect Eine Kommunikation zwischen dem Identity Provider mit dem Security Aspect findet nicht direkt statt Der Browser des Clients wird durch ein HTTP Redirect dazu gebracht mit dem jeweils anderen System Kontakt aufzunehmen Hieraus ergibt sich die Anf lligkeit des Konzepts gegen ber des in Kapitel 6 3 beschriebenen Session Hijacking Angriffs Ein Benutzer wird gegen ber IDP wie auch SecurityAspect durch die hinterleg ten Cookies identifiziert Bekommt ein Angreifer die hinterlegten Cookies so kann er sich als der entsprechende Benutzer ausgeben IDP Wibukeyapplet Das Applet welches der Kommunikation des IDP mit dem lokalen WIBUKEY Server dient besitzt zwei Schnittstellen Die Kom munikation mit dem IDP wird durch SSL gesch tzt Das Applet kann au erdem lediglich mit dem Aussteller des Applets in diesem Falle nur dem IDP kommunizieren Dies ist durch das Java Sicherheitskonzept sicherge stellt Durch die Signierung des Applets berpr ft der Browser automatisch ob das Applet unver ndert ist IDP proaktiv Die Kommunikation zwischen dem Identity Provider und dem ProAktivApplet ist per SS
70. Um genau spezifizieren zu k nnen welche JSP Seiten nur per SSL erreichbar sind wird der Parameter wie in Listing 30 zu jeder abzusichernden JSP Seite eingetragen lt sslext pageScheme secure true gt Listing 30 Anderungen an einer JSP Seite Die Angabe ob der Aufruf einer Action Class nur per SSL oder direkt erfolgen darf geschieht in der Datei struts config xml Wie in Listing 31 gezeigt gibt es dazu einen Parameter secure der Wahlweise auf true oder false gesetzt werden kann gee er ee type org diplom idp IndexPwAction scope request gt lt set property property secure value true gt lt forward name success path jsp logon jsp redirect true gt lt action gt Listing 31 Anderungen an der struts config xml 8 9 Wibu Key Der Wibu Key kann im Rahmen dieses Demonstrators neben der initialen Au thentifikation zur periodischen Reauthentifikation siehe 5 2 2 auf Seite 65 des Benutzers verwendet werden Nachdem der Benutzer initial seine Benutzerken nung und sein Passwort angegeben hat kann periodisch eine Uberpriifung auf Vorhandensein des Wibu Keys am Client Rechner durchgefiihrt werden Die An gabe welches Authentifikationsverfahren durchgef hrt werden soll wird vom Ser vice Provider spezifiziert Im Falle unseres Demonstrators wird einer Rolle ein Au thentifikationsverfahren zugeordnet Die Uberpriifung des Wibu Keys wird mit Hilfe eines Applets realisiert Dieses Applet wird vom Identity Pro
71. Zugriff erlaubt ist Falls der Zugriff nicht gew hrt wird erzeugt der Aspect eine Fehlerseite die zwei M glichkeiten zur Verf gung stellt e zur ckzugehen auf die letzte Seite und eine andere Eingabe versuchen oder e ganz auf die erste Seite zur ckzugehen Das Zur ckgehen wurde ber ein Javascript realisiert welches lediglich den back Knopf des Browsers bet tigt Da dadurch aus dem Stack des Browsers eine ge speicherte Seite geholt wird und die Applikation sich nicht im Zustand ver ndert hat kann der Benutzer eine neue Eingabe an den Server senden Die Funktion des Backbuttons wird in Abi04 und Cor erkl rt Um auf die erste Seite der Applikation zur ckzugehen ist es erforderlich dies auch dem Referenzmonitor mitzuteilen damit sich dieser auf die Ausgangsposition zur ckbegeben kann In der vorliegenden Implementation ist dies dadurch gel st dass die Workflows alle auf Base gestellt werden und ein Redirect auf eine in der Datenbank hinterlegte Seite durchgef hrt wird falls ein Parameter BackBasePage auf einen definierten Wert gesetzt ist Durch den Redirect wird der Browser des Benutzers aufgefor dert eine neue Seite zu laden von einer frei definierbaren Quelle if validate thisJoinPointStaticPart getSignature request user ActionForward result proceed mapping form request response return result else log debug around _validated_to_false _page_access_denied throwValidationErrorPage
72. achen Dies kann die Stabilitat und Sicherheit eines Systems entscheidend verbessern 4 REFERENZMONITOR 49 4 Referenzmonitor F r die Implementierung der Zugangskontrollen wird das Konzept eines Refe renzmonitors gew hlt Durch diesen wird ein vom Authentifikations und Autori sationsverfahren unabh ngiges Konzept beschrieben wie diese in einem System verwendet werden k nnen Das Konzept des Referenzmonitors wird im Anschluss weiter erl utert Danach wird im zweiten Teil RBAC als verwendete Sicherheits strategie eingef hrt und im dritten Teil schrittweise um das Konzept der Work flows erweitert Ein Referenzmonitor wird im Federal Standard 1037C fTS196 wie folgt defi niert reference monitor An access control concept that refers to an abstract machine that mediates all accesses to objects by subjects NIS Entsprechend dieser Definition ist ein Referenzmonitor eine Blackbox welche gefragt wird ob ein spezieller Benutzer das Recht hat eine von ihm angeforderte Operation durchzuf hren Somit stellt der Referenzmonitor das Modul dar in dem die Sicherheitsstrategie verankert ist Der Monitor kann in zwei getrennte Probleme unterteilt werden e Technische Implementierung des Referenzmonitors e Wahl der richtigen Sicherheitsstrategie 4 1 Implementierung eines Referenzmonitors Wie Anderson 1972 in And72 beschreibt sind die folgenden Punkte wichtige Charakteristika eines Referenzmonitors Dieser soll e manipulat
73. agment unter Verwendung von SourcelD zu erm glichen SourcelD benutzt dabei offene Protokolle und Standards dazu geh ren die Standards des Liberty Alliance Projekts der OASIS SAML Gruppe und die WS Initiative von IBM und Microsoft Es soll dem Entwickler von Software erleichtert wer den siehe FE03 seine Software um Identity Federations zu erweitern da er sich nicht mehr um die Details des Liberty Protokoll und der darunterliegen den Protokolle wie XML XML Digital Signatures SOAP und SAML k mmern muss SourcelD hat bisher mehrere Versionen ihres Frameworks ver ffentlicht Dazu geh rt SourceID Java SourceID NET sowie SourcelD Liberty Sour celD Java und SourcelD NET implementieren dabei das Liberty Protokoll ID FF der Version 1 1 SourceID Liberty das Liberty ID FF Protokoll der Version 1 2 Alle drei Frameworks wurden von der Liberty Alliance getestet und als konform bezeichnet und mit dem Pr dikat Liberty Alliance Interoperable ausgezeichnet Alle drei Frameworks sind Open Source Projekte die nach einer Open Source oder Public Source Lizenz freigegeben sind vgl sou03 SourcelD NET ist eine Erweiterung zur Integration des Liberty Protokolls f r das NET Framework von Microsoft SourcelD Java ist die Erweiterung f r 2 SINGLE SIGN ON 31 die Java Programmierumgebung und zielt auf die Integration in eine Java Web Applikation die innerhalb eines Containers wie Tomcat oder JBoss l uft Sour celD Liberty ist das neuest
74. als Identifikator ver wendet um den aktuellen Zustand der Workflows einer Session zu speichern Die SessionID ist notwendig da ein Benutzer durchaus auch mehrere Sessions besitzen kann Den Rollen sind die geforderten Verfahren zur Authentifikation zugeordnet Ein Benutzer der diese Anforderungen nicht erf llen kann da er z B keine Smartcard besitzt aber diese gefordert ist ist nicht in der Lage sich zu authentifizieren Somit besitzt ein Benutzer die Menge aller zu seiner Rolle geh renden Rech te In diesem Modell kann er auch gleichzeitig in verschiedenen Workflows ak tiv sein Falls durch einen Interaktionsschritt ein Workflow nicht weitergef hrt werden kann so wird der Workflow auf Base gesetzt Falls alle Workflows auf Base stehen bedeutet dies dass es keinen Workflow gibt auf dem der Benutzer weiterarbeiten kann und der Referenzmonitor validiert zu false Die gleichzeitige Aktivit t von Workflows bedingt sich aus dem Aufbau von Webservices Zumeist gibt es eine zentrale Seite von der aus die Software und die m glichen Abl ufe erreichbar sind Somit kommt diese Seite in allen m gli chen Workflows vor Da es aber nicht entscheidbar ist welchen Schritt der Be nutzer gehen wird ist somit jeder Workflow der dem Benutzer m glich ist zu diesem Zeitpunkt aktiv Dies sollte sich allerdings nach wenigen Schritten be reits ge ndert haben und nur noch wenige bzw einer der Workflows sollte sich herauskristallisieren
75. also Verfahren und Methoden die sich in der Praxis bew hrt haben Es werden aber keine konkreten Mafnahmen empfohlen so dass er flexibel bleibt Bei der ISO IEC TR 13335 werden hingegen keine Vorgehensweisen oder L sungen vorgegeben Er ist ein Leitfaden wie Vorgehensweisen zu entwickeln und anzupassen sind Daher ist er auch nicht in der Lage ein Sicherheitsniveau zu messen oder in Relation zu anderen Systemen zu stellen Im RFC 2196 werden Sicherheitsrichtlinien im Internet beschrieben und rich tet sich speziell an Systembetreiber In Deutschland ist 1992 vom BSI das Sicherheitshandbuch in seiner ersten Auflage herausgegeben worden Dieses stellt einen Leitfaden dar anhand dessen eine Risikoanalyse durchf hrbar ist Doch der Aufwand hierf r ist sehr gro so dass im Juli 1994 die erste Version des Grundschutzhandbuchs GSHB heraus gegeben wurde Dieses wird seitdem j hrlich aktualisiert Es ersetzt die Risiko analyse des Sicherheitshandbuchs durch einen Ist Soll Vergleich In einer Sicherheitsanalyse werden alle Objekte die bedroht werden erfasst und f r jedes Objekt werden die Grundbedrohungen sowie die Gef hrdungen ermittelt Daraufhin wird jedes Objekt bewertet und die H ufigkeit der Sch den ermittelt Aus diesem Resultat werden dann Ma nahmen abgeleitet wie ein einzelnes Objekt zu sch tzen ist Dieser Prozess ist sehr aufwendig und f r viele Firmen nicht durchf hrbar Daher setzt das Grundschutzhandbuch auf einen Sol
76. alverschlisselung Zur Durchf hrung einer Authentifikation die von einem Service Provider initiiert wurde miissen viele Nachrichten ausgetauscht werden Zum einen geh ren dazu die Nachrichten die durch die Web Redirects des Liberty Protokolls zwischen den Service Providern und den Identity Providern entstehen Da diese ber den Browser des Client Rechners verschickt werden ergibt sich eine Verdoppelung 108 des Kommunikationsaufkommens da die Nachrichten vom Service Provider zum Client Rechner und von dort weiter zum Identity Provider geschickt werden Eine genaue Beschreibung des Web Redirect Verfahrens befindet sich in Kapitel 2 4 Weiterhin geh ren dazu die Nachrichten die durch die Ubertragungen der Web seiten vom Identity Providers entstehen Unter der Vielzahl dieser Ubertragungen sind folgende die schiitzenswertesten e Benutzernamen Passwortes e WibukeyApplets mit seinen Parametern e Response vom Wibukey Applets Einen guten berblick ber die n tigen bertragungen bietet die Abbildung 36 Hier sind beispielhaft die abgebildet die durch eine Authentifikation mit dem Wibu Key stattfinden Wie in Kapitel 2 5 angedeutet gibt es gewisse Pro blematiken bei der Durchf hrung der Web Redirect Technik des Liberty Proto kolls In Gro03 wird empfohlen einen sicheren bertragungskanal f r die Li berty Nachrichten zu verwenden Eine M glichkeit den bertragungskanal der Liberty Nachrichten abzusichern ist die Benutzung von
77. ation Cobit Website 2004 URL http www isaca org AAAF95 G Alonso Divyakant Agrawal Amr El Abbadi C Mohan Roger Gunthor und Mohan Kamath Exotica FMQM A Persistent Message Based Architecture for Distributed Workflow Managemen In Proceedings of the IFIP WG8 1 Working Conference on Infor mation Systems Development for Decentralized Organizations Trondheim Norway 1995 URL http citeseer nj nec com alonso95exoticafmqm html Abi04 Abigail Simulating the back button 2004 URL http www foad org abigail HTML Misc back_button html ACMO01 Vijayalakshmi Atluri Soon Ae Chun und Pietro Mazzoleni A Chinese wall security model for decentralized workflow systems In Proceedings of the 8th ACM conference on Computer and Communications Security Seiten 48 57 ACM Press 2001 URL http doi acm org 10 1145 501983 501991 AG Wibukey Systems AG WIBU KEY URL http wibu de de wibukey php AGO1 Wibukey Systems AG Keynote No 2 October 2001 URL http www wibu com files news kn2 pdf AG03 Wibukey Systems AG Programmer s Guide WIBU KEY 2003 Version 4 00 AG04 Wibukey Systems AG Benutzerhandbuch WIBU KEY 2004 Version 4 00 And72 J Anderson Computer Security Technology Planning Study ESD TR 73 51 Hanscom AFB Oct 1972 ANSI04 Inc American National Standards Institute ANSI INCITS 359 2004 Role Based Access Control 2004 AS87 Shoji Miyaguchi Akihiro Shimizu Fast Data Encryption Algorithm FEAL Lec
78. beenden und ein return null auszuf hren Dies hat zur Konsequenz dass die aktuelle Seite wieder aufgerufen wird Nun aber mit einem gesetzten Usernamen private void callPasswordIDP HttpSession session HttpServletRequest request HttpServletResponse response throws Exception Vector idpIdVector getIDPVector session request setAttribute ProviderID idpIdVector firstElement request setAttribute IsPassive new Boolean false request setAttribute ForceAuthn new Boolean false request setAttribute Federate new Boolean false String myURL request getServletPath request setAttribute Return Success myURL request setAttribute Return Failure myURL request getRequestDispatcher sso authnRequest forward request response Listing 22 Aufruf der Authentifikation Da im ersten Schritt nur eine Passwortauthentifikation durchgef hrt wird um den Benutzer festzustellen ist es danach je nach Rollenkonfiguration n tig eine 100 Reauthentifikation durchzuf hren Eine solche Reauthentifikation kann auch periodisch durchgefiihrt werden Hierdurch kann z B erzwungen werden dass eine SmartCard w hrend der Programmausf hrung vorhanden ist Die Autorisierung umkapselt den Aufruf der Methode Dies wird aus dem Codebeispiel in Listing 23 deutlich Bevor die Methode durch ein proceed siehe 3 1 1 aufgerufen wird stellt der SecurityAspect an den Referenzmonitor siehe 8 6 die Anfrage ob der
79. bei zuerst eine Kompilation der Dateien HTMLRewriterAspect java und WrappedResponse java durch Diese beiden Dateien werden in das Archiv HTMLRewriterWeave jar ge packt und in das lib Verzeichnis der Applikation kopiert Zus tzlich werden die vom Tomcat erzeugten Java Klassen der JSP Seiten gel scht Dies geschieht um eine Neukompilation der JSP Seiten vom Tomcat zu erzwingen sodass zu jeder Datei von Tomcat automatisch der HTMLRewriter Aspect hinzugef gt wird 124 SecurityAspect F r die Einbindung des Security Aspects muss zuerst das Build Script ausgef hrt werden Dieses kompiliert die zum Zugriff auf die Daten bank ben tigte Java Dateien und packt diese in das Archiv security Aspect jar Dieses Archiv wird ich das lib Verzeichnis der Applikation kopiert Zus tzlich wird der Aspect SecurityAspect java in das src Verzeichnis der Applikation ko piert Nach einer Kompilation der Webapplikation ist der SecurityAspect mit allen Action Classes der Applikation verwoben Beispielablauf Nach Aufruf des mit dem SecurityAspect abgesicherten JPets tores wird der Benutzer zuerst zu den Seiten des Identity Providers weitergeleitet und bekommt die Login Seite des IDPs Abbildung 53 angezeigt Falls das Login Identity Provider Please enter your Username and Password Username thomas Password Submit Reset Abbildung 53 Identity Provider Login Page Formular richtig ausgef llt wurde wird die Wibu Key Authentif
80. besten Technologie e die bessere Betreuung und 1 EINLEITUNG 9 e die hohe Implementierungsgeschwindigkeit des Gesamtsystems genannt Bei der Betrachtung der dort aufgef hrten Kriterien die zur Wahl einer ASP L sung f hren f llt allerdings auf dass die Sicherheit und Verl sslichkeit eines Systems jeweils nur von ca 20 der Befragten als Kriterium angegeben wurde Eine ffnung von internen Prozessen f r Partner Lieferanten oder auch Kun den birgt gro e Sicherheitsrisiken die es in abgeschirmten Unternehmensnetzwer ken in der Form nicht gibt Hierzu wird in BMO3 festgestellt concerns about security trust authentication fraud and risk of loss are often cited as among the significant barriers to the growth of e commerce In diesem Umfeld ist die Verwaltung der Benutzer und ihrer Rechte eine gro e Herausforderung wie in Vog04 festgestellt wird Die Verwaltung wird als User Management bezeichnet und ist Teil eines Identity Managements Dieses Identity Management muss in ein Softwaresystem integriert werden so dass die Methoden Identifikation Authentifikation Access Control Accountability und Audit wie sie in 5203 vorgestellt werden die gestellten Anforderungen erf llen Ein weiteres ASP und Outsourcing spezifisches Problem ist das Erzeugen der Datenbasis auf deren Basis Authentifikation und Access Control basieren Im Rahmen der Authentifikation muss sichergestellt werden dass die Benutzerdaten unver ndert s
81. cation Method Authentication Instant User account info IDP pseudonym des User account info SP pseudonym Digital Signature of assertion Abbildung 4 Authentication Assertion Wie man in Abbildung 4 sieht besteht eine Assertion dabei aus einer Assertion ID dem Namen des Ausstellers dieser Assertion IDP dem Zeitpunkt wann diese Assertion ausgestellt wurde dem Zeitpunkt bis wann diese Assertion giiltig ist ftir wen sie bestimmt ist Audience Restriction der Methode wie sich der Principal authentifiziert hat z B Passwort dem Zeitpunkt der Authentifizierung dem Pseudonym auf der SP und IDP Seite und einer digitalen Signatur der Assertion Diese SAML verpackten Assertions werden entweder Ober Web Redirects oder ber das SOAP Protokoll ausgetauscht Das SOAP Simple Object Access Protocol ist nach W3C00 ein Protokoll um in einer dezentralisierten verteilten Umgebung Informationen auszutauschen Es baut auf dem XML Standard auf und kann prinzipiell ber verschiedenste Protokolle bertragen werden Es wird bei Liberty ID FF aber nur ber das HTML Protokoll bertragen In Abbildung 5 ist zu erkennen dass eine SOAP Nachricht in eine HTTP Nachricht eingebettet ist Eine SOAP Nachricht besteht aus einem SOAP Hea der und einem SOAP Body Innerhalb dieses Bodys k nnen die Nachrichten ber tragen werden Im Falle des Liberty Protokolls ist die Authentication Assertion spezifiziert nach SAML 2 SINGL
82. cern hingegen l sst sich durch objektorientierte Verfahren nur sehr schwer beschreiben wie es am Anfangs gezeigten logging Beispiel zu sehen ist Ein Cross Cutting Concern steht sozusagen orthogonal zur objektorientierten Methode und beschreibt Aufgaben die sich an vielen Stellen wiederholen Dies wird in Abbildung 10 illustriert In der Entwicklung einer Software gilt es diese Cross Cutting Concerns zu isolieren getrennt zu implementieren und dann wieder mit dem Programm zu verweben Dieses Verweben der Eigenschaften wird durch einen sogenannten Wa ver durchgef hrt 38 Logging ur a Acounting Logging Business logic Abbildung 10 Zusammenf gen eines Systems aus Concerns Concerns m Ss Logging System Implementation modules Abbildung 11 Ein System wird als Komposition von Concerns betrachtet Lad03 3 1 1 Die Syntax Die Sprachdefinition von AspectJ unterscheidet Pointcuts Advices inter type Declarations und Aspects Ein Pointcut beschreibt wo ein Aspect eingef gt wer den soll Der Advice sagt wann der Aspect ausgef hrt werden soll Join Point Der Join Point ist das fundamentalste Konzept der AspectJ De finition Durch ihn kann jeder identifizierbare Ausf hrungszeitpunkt innerhalb eines Programms beschrieben werden Es werden folgende Join Points in AspectJ unterschieden Execution Der Execution Join Point bezieht sich auf die bezeichnete Methode an sich Es
83. chen 2 1 1 NET Passport Das NET Passport Protokoll ist ein propriet res Protokoll von Microsoft und ist als ein Service von Microsoft zu verstehen Es ist ein zentralisierter Service zur sicheren und einfachen Authentifikation von Benutzern fiir teilnehmende Be treiber von Webseiten Das Hauptaugenmerk beim Passport liegt dabei auf dem Single Sign In Service f r web basierte Applikationen Es soll die Zufriedenheit der Benutzer durch einfaches Sign in und Registration erh ht werden Der Benut zer wird davor verschont wiederholt seine Benutzerdaten einzugeben Er speichert oft abgefragte Informationen in seinem Passport Profil das zentral auf den Mi crosoft Passport Servern gespeichert ist und von dort an Dritte nach Bedarf und Sicherheitspolitik weitergegeben wird Die Vorteile DOTO3 von Passport sind e convenient access e enhanced user experience e reduced costs and ease of administration Die Tatsache dass die Daten zentral gespeichert werden hat aber nicht nur Vor teile Man ist von der Sicherheitspolitik Microsofts abh ngig insbesondere was die Weitergabe von Daten an Dritte und den Zugang zu den Daten betrifft Die M glichkeit der anonymen Authentifikation ist bei Passport nicht gegeben da je der Benutzer eine global eindeutige Identit t hat Au erdem gibt es nach KR00 einige Angriffsm glichkeiten auf das Protokoll die die Verwendung von Passport sehr in Frage stellen Auch die Verwendung der h chsten Sicherh
84. cherheitsmoduls bringt verschiedene Vorteile In W JP03 wird festgestellt dass das Modularisieren von Crosscutting Concerns siehe 3 1 die Verst ndlich keit und Analysierbarkeit des Quelltextes stark erh ht Die Entwickler m ssen nicht den gesamten Quelltext untersuchen sondern k nnen sich auf die Entwick lung eines Moduls beschr nken Weiter wird in W JP03 das Problem der Verifizierbarkeit angesprochen Die Qualit tssicherung ist ein wichtiger Bestandteil bei der Entwicklung von Software Das Verwenden von AOP hat auf diesen Prozess positive wie auch negative Auswirkungen Der starke Modularisierungsansatz erzeugt kleinere und abgegrenzte Einheiten Dies hat zur Folge dass es einfacher ist f r diese Module Testfalle zu definieren und sie gegen diese Tests zu verifizieren Problematisch ist aber die Kontrolle des Fokus des Aspects Die Frage ob der Aspect wirklich ber all hinzugefiigt wird wo er n tig ist und er wirklich nur hinzugef gt wird wo er ben tigt wird ist leider bisher durch kein Tool beantwortbar Fine nachtr gliche Kontrolle ob wirklich dieses Ziel erreicht wurde fehlt komplett AOP Techniken bedeuten aber auch fiir den Einsatz von Software neue Risi ken Durch die M glichkeit den Bytecode im Nachhinein zu ndern wird es f r den Benutzer schwerer zu beurteilen ob die Software die er einsetzt wirklich so 46 von dem Hersteller kommt Allerdings k nnen hier die in Java bereits etablier ten Mechanisme
85. ches Zertifi kat gespeichert ist Dies bringt den Nachteil dass nderungen immer von Hand eingetragen werden m ssen lt account handler gt org diplom idp AccountHandlerJDBC lt account handler gt Listing 3 Auszug aus der sourceid sso xml Zus tzlich zu den Informationen in den angegebenen xml Dateien verlangt SourcelD Java nach einem Account Handler Dieser AccountHandler siehe Listing 3 ist eine Java Klasse die von SourceID Java aufgerufen wird und eine Schnitt stelle zwischen der lokalen Benutzerdatenbank und SourcelD darstellt SourceID berpr ft bei von Partnern im Circle of Trust ankommenden Nachrichten ob die Subjekte die von den Partnern authentifiziert wurden in der lokalen Datenbank gespeichert sind und es Federationeintr ge mit den Subjekten und der ID der Partners gibt ber den AccountHandler wird diese Zuordnung der Pseudonyme zu den lokalen Benutzerkennungen vorgenommen In Bild 7 wird verdeutlicht wie der Ablauf der Kommunikation zwischen der SourceID API und der Applikation auf Seiten eines Service Providers von statten geht Die Applikation initiiert 1 eine Authentifikationaufforderung eines Sub jektes und erstellt daf r ein Authentification Request der die Art der ben tig ten Authentifikation sowie den Identity Provider angibt der die Authentifikation durchf hren soll sowie die R cksprungadressen zu der Applikation bei gelun gener Authentifikation Success Page und im Fehlerfall Failure Page
86. chrieben alle Informationen hinterlegt die f r die Autorisa tion ben tigt werden Zus tzlich befinden sich hier auch die f r eine Rolle zu verlangenden Authentifikationsverfahren Die Kommunikation zwischen SecurityAspect und der Datenbank erfolgt ber TCP IP Ein erfolgreicher Angriff auf diese Datenbank kann 1 ein Offenlegen der Datenbank zur Folge haben oder 2 eine Ver nderung der gespeicherten Daten Im Fall 7 KONZEPT UND SICHERHEITSBETRACHTUNG 85 1 werden die Workflows und damit auch die Rechte der einzelnen Benut zer dem Angreifer offenbart Dar ber kann der Angreifer Einblicke in die Firmenorganisation bekommen Da keine Passw rter oder andere Authenti fikationsmerkmale in dieser Datenbank hinterlegt sind bleibt der Schaden der durch einen lesenden Zugriff entsteht begrenzt Der Fall 2 hat zur Konsequenz dass die Rechte die ein Benutzer hat ver ndert werden und auch die ben tigten Authentifikationsmerkmale durch den Angreifer ge n dert werden k nnen Er hat dadurch die M glichkeit sich selbst Zugriff auf das System und dessen Daten zu gew hren und kann regul ren Benutzern den Zugriff unm glich machen Identity Provider Datenbank Die Identity Provider Datenbank tr gt die Da ten zur Authentifikation der Benutzer Im Gegensatz zur SP Datenbank be deutet der Fall 1 also der lesende Zugriff bereits eine extreme Verletzung des Sicherheitsmodells Hieraus ergibt sich die Notwendigkeit die Datenbanken unzug n
87. com eng mozilla 3 0 handbook javascript Danny Coward Java Servlet Specification Sun Microsystems Inc Version 2 3 Auflage August 2001 Robert Durst Terrence Champion Brian Witten Eric Miller und Luigi Spagnuolo Tes ting and evaluating computer intrusion detection systems Commun ACM 42 7 53 61 1999 URL http doi acm org 10 1145 306549 306571 S Das K Kochut J Miller A Sheth und D Worah ORBWork A Reliable Distributed CORBA based Workflow Enactment System for METEOR 1997 URL http citeseer ist psu edu das96orbwork html Microsoft Net Passport Review Guide Juni 2003 URL http download microsoft com download a f 4 af49b391 086e 4aa2 a84b ef6d916b2 08 passport _reviewguide doc Claudia Eckert T Sicherheit Oldenbourgh 2001 ECK c 01 1 1 Ex C Eckert T Sicherheit Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Strasse 145 D 81671 Mnchen 2 auflage Auflage 2003 Bryan Field Elliot A Developer s Tour 2003 URL http www pingidentity com downloads sourceid_dev_tutorial ppt D F Ferraiolo und D R Kuhn Role Based Access Con trol 15th National Computer Security Conference 1992 URL http csrc nist gov rbac Role_Based_Access_Control 1992 html E LITERATURVERZEICHNIS 139 Fou Fou04a Fou04b FPHKH00 Fra97 Fri97 Sid192 Sid197 SidI03a Sid103b Sid104 TSI96 Gon04 Gro03 Gro04 Hai03 Hal94 hDG04
88. dene HTML Code korrekter Code ist Im Fall des JPetStore z B wurde der body Tag nicht geschlossen so dass anfangs die Tabelle nicht korrekt einge f gt wurde Es w re f r einen absolut generischen Einsatz dieses Aspects ein HTML Parser einzubinden der in der Lage ist solche F lle zu erkennen und den HTML Aufbau in eine korrekte Form zu bringen 8 8 Identity Provider Der Identity Provider IDP hat die Aufgabe die Authentifikation von Subjekten durchzuf hren und von ihm abh ngige Module Service Provider mit relevanten Daten ber die stattgefundenen Authentifikationen zu versorgen Die Anforde rungen im Rahmen dieses Demonstrators an den Identity Provider sind dabei eine initiale Authentifikation zur bermittlung von Benutzerdaten und folgende periodische Reauthentifikationen Das Zusammenarbeiten von unterschiedlichen Service und Identity Providern wird hier mit Hilfe des Liberty Protokolls Kapitel 2 2 durchgef hrt Als Fra mework zum Zugriff auf das Liberty Protokoll wird die Implementierung von SourcelD Kapitel 2 6 verwendet Zur Gestaltung der Benutzerinteraktion wird Struts Fou04b verwendet Da das Framework von SourcelD nur die Kommu nikation mit dem Liberty Protokoll abdeckt mussten die Authentifikationsver fahren und passenden Webseiten selbst entwickelt werden Die Behandlung einer Authentifikationaufforderung wird entweder durch direktes Aufrufen einer Web seite durch einen Benutzer oder durch Initiierung von einem b
89. die Service Provider Applikation der Security Aspect sind nur eine Tomcat Applikation Tomcat l uft auf einem Server und dieser Server mu abgesichert sein siehe Kapitel 6 Das Konzept hat die Annahme dass der Austausch der Authentifikationsda ten durch das Liberty Protokoll abgesichert ist Eine Sicherheitsbetrachtung des Liberty Protokoll befindet sich in Kapitel 2 5 Die Sicherheit der Wibukey Authentifikation basiert auf der Zusicherung durch die Firma Wibu Systems dass sichergestellt ist dass ein Firm Code eindeutig und jedem Kunden speziell zugeordnet ist Eine genauere Be trachtung des Wibu Key findet sich in Kapitel 5 3 Das Konzept des ProAktivApplets basiert auf dem Zusammenspiel der Ser vice Provider und Identity Provider Der Aufruf des Applets mu vom Ser vice Provider in jede Ausgabeseite eingebettet und das Applet direkt vom Identity Provider geladen werden Falls einer der beiden Provider nicht mit den n tigen Modulen f r die Proaktivit t ausgestattet ist kann das ProAk tivApplet nicht ausgef hrt werden vgl Kap 8 10 Aus dem Konzept ergeben sich auch die zu betrachtenden Angriffspunkte die im Rahmen einer Sicherheitsanalyse wie sie in Kapitel 6 4 beschrieben wird be trachtet werden m ssen F r jedes Element des Konzepts muss daher untersucht werden wie und mit welchen Auswirkungen ein Angriff erfolgen kann Service Provider Datenbank In der Service Provider Datenbank sind wie in Kapitel 7 2 bes
90. die auf Betriebssystemebene Anwendung finden lassen sich in pr ventive Ma nahmen Ma nahmen zur Erkennung von Angriffen und zur Wiederherstellung nach einem Angriff einteilen In den Bereich der pr ventiven Ma nahmen fallen alle Schritte die eingeleitet werden einen Angriff zu verhindern Wichtig hierbei ist bereits die Wahl des Be triebssystems In JF03 wird empfohlen ein OpenBSD zu verwenden da es eine geringe H ufigkeit an entdeckten Sicherheitsl chern in der Vergangenheit aufge wiesen hat Dies stellt auch den Vorteil von offenen Betriebssystemen dar Umso mehr Menschen in der Lage sind die Fehlerfreiheit des Systems zu evaluieren desto h her ist die Wahrscheinlichkeit dass ein enthaltener Fehler auch gefunden wird Nach der Wahl des Betriebssystems muss dieses f r den geplanten Einsatz angepasst werden Dies bedeutet dass nur die absolut n tigen Dienste installiert sein d rfen und Dienste die nur intern Verwendung finden m ssen durch eine entsprechende Konfiguration des Netzwerks nach aussen gesperrt werden Hier zu werden hier nicht weiter behandelte Komponenten wie Router und Firewalls eingesetzt Um den dann erreichten Sicherheitsstandard zu erhalten ist es n tig das Betriebssystem und die darauf verwendeten Dienste stets aktuell zu halten und auf entdeckte Sicherheitsl cher schnell zu reagieren Wenn aber ber eine nicht entdeckte L cke ein Angriff stattfindet sollte die ser ebenfalls erkannt werden Hierf r f
91. dieser Arbeit wird der Begriff des Aspekts mit zwei verschiedenen Interpre tationen verwendet Zum einen kommt der Aspekt in seiner normalsprachlichen Bedeutung zum Einsatz Zum anderen wird er auch im Zusammenhang mit dem programmiersprachlichen Konzept aus AOP verwendet Hierbei wird zur besse ren Unterscheidbarkeit die englischen Schreibweise Aspect verwendet Dieser Aspect wird in Kapitel 3 1 1 vorgestellt Diese aspektorierierte Programmierung hat ihren Ursprung im Xerox Alto Reserch Center Das lteste Dokument stammt aus dem Jahr 2000 Voe00 Die Forschungsarbeiten begannen mit den Dokumenten KLM 97 und MKL97 die aus dem Jahr 1997 stammen Es wird in dieser Diplomarbeit AspectJ als Implementierung der aspektorien tierten Programmierung verwendet Die Wahl wurde aufgrund der guten Doku mentation und der hohen Produktreife getroffen 3 1 Die Sprache Jede Aufgabe die das System sp ter duchf hren soll wird im Rahmen von AOP als ein Concern wahrgenommen Bei einem Webshop sind zum Beispiel das Hin zuf gen von Artikeln zum Warenkorb und das Entfernen von Artikeln Gesamt summe berechnen und Protokollieren von Handlungen Concerns Hierbei wird nun zwischen Systemconcerns und Cross Cutting Concerns unterschieden Der Systemconcern stellt eine spezielle sich nicht wiederholende Aufgabe dar die von dem System erledigt werden soll Diese werden durch die objektorientierte Programmierung in Module aufgeteilt Der Cross Cutting Con
92. e org aspectj tools ant taskdefs aspectjTaskdefs properties gt lt classpath gt lt pathelement path devlib aspectjtools jar gt lt classpath gt lt taskdef gt Listing 12 nderungen an der build xml 3 4 Integration in Tomcat Da ein durch AOP ver ndertes Programm weiterhin korrekter Java Bytecode ist muss f r ein bereits compiliertes und verwobenes Programm keine Ver nderung am Tomcat vorgenommen werden Nun kann es aber gew nscht sein dass das Weaving durch den Tomcat Server durchgef hrt wird Dies bringt den Vorteil dass die Aspecte im Betrieb ausgetauscht werden k nnen Hierzu muss der Com piler von Tomcat durch den von AspectJ in der Konfigurationsdatei web xml ausgetauscht werden Folgende Zeilen in der web xml werden ben tigt lt servlet gt lt servlet name gt ajsp lt servlet name gt lt servlet class gt org apache jasper servlet JspServlet lt servlet class gt lt init param gt lt param name gt logVerbosityLevel lt param name gt lt param value gt DEBUG lt param value gt lt init param gt lt init param gt lt param name gt compiler lt param name gt lt param value gt org aspectj tools ant taskdefs Ajcl1CompilerAdapter lt param value gt lt init param gt lt init param gt lt param name gt fork lt param name gt lt param value gt FALSE lt param value gt lt init param gt lt load on startup gt 2 lt load on sta
93. e Flexibilit t im Mittelpunkt unserer Betrachtung Wir haben diese Ziele durch den Einsatz von aspektorientierter Programmie rung und dem Liberty Alliance Framework erreicht Da diese Diplomarbeit in einem kleinen Team bearbeitet wurde gilt es auf zuzeigen wer f r welche Teile der Arbeit verantwortlich zeichnet Nicolai Kuntze hat die Kapitel 1 3 4 6 7 bis 7 2 und 8 bis 8 7 Thomas Rauch die Kapitel 2 5 8 8 bis 8 10 und Kapitel 9 verfasst Das Kapitel 10 und das Kapitel 7 3 sind gemeinsam entstanden Wir m chten uns auch an dieser Stelle bei unserem Betreuer Dr Andreas U Schmidt und Frau Prof Eckert bedanken Ohne deren Geduld Hilfe und Anre gungen w re diese Arbeit nicht entstanden Desweiteren bedanken wir uns beim SIT deren Mitarbeiter uns stets so gut es ging unterst tzten Weiter m ssen wir uns f r die unerm dliche Arbeit von Dominique M hler und Elvira Rauch bedanken die eine unendliche Anzahl von Fehlern entdeckten die wir schon nicht mehr sahen Nicolai Kuntze und Thomas Rauch 17 Februar 2005 Zusammenfassung Identity Management erlangt eine immer gr ere Bedeutung da immer mehr Firmen ihre IT Systeme fiir Partner Lieferanten oder Kunden 6ffnen Die Diplomarbeit stellt einen Ansatz vor durch den ein Zugriffskontroll und Authentifikationssystem modular zu bestehenden webbasierten Syste men hinzugefiigt werden kann Das System muss hierfiir nicht im Sourceco de vorliegen In einer Trainingsphase w
94. e Framework von SourcelD und zielt zus tzlich zur Integration in eine Java Web Applikation auch noch die Integration als autono mer Server an damit dieser innerhalb vieler unterschiedlicher Programmspra chen Umgebungen einbindbar ist F r die Zukunft ist bei SourcelD geplant dass ID FF Version 1 2 ID WSF sowie die WS Federation Spezifikation zu unterstiit zen SourcelD Java bietet eine API zur Kommunikation mit anderen Teilnehmern eines Circle Of Trust und bernimmt die Handhabung der SOAP SAML und XML Nachrichten Auerdem bietet eine high level Schnittstelle f r die Applikati on siehe Abbildung 6 und ist als ein zus tzliches Modul in einer J2EE Umge Client Browser IDP SP Applikation SOAP SAML Authentification Request Federation Request XML Zertifikate Logout Request Abbildung 6 SourceID API bung gedacht Eine typische Anwendung f r die Erweitung mit SourcelD ist eine Webapplikation die innerhalb eines Webcontainers wie z B Tomcat oder JBoss l uft wobei der komplette Versand und die berpr fung der Liberty Nachrichten von SourcelD bernommen wird Der Programmierer einer Anwendung muss sich nicht mit den Details des Liberty Protokolls und deren Unterprotokolle besch fti gen Die Logik des Liberty Protokolls muss allerdings trotzdem in die Applikation integriert werden Die Applikation muss als Service Provider oder Identity Pro vider in den Konfi
95. e Tatsache dass sich das Geheimnis ber l n gere Zeit nicht ndert da st ndige Ver nderungen die Akzeptanz des Verfahrens bei den Benutzern erheblich senken w rden besteht weiterhin die Gefahr dass 5 AUTHENTIFIKATION IM WEBUMFELD 63 ein Angreifer durch das einmalige Abh ren erfolgreiche Maskierungsangriffe t tigen kann Dieses Problem kann durch die Einf hrung von einmal benutzbaren Passworten verhindert werden Ein in der Praxis h ufig eingesetztes Verfahren ist das S Key Verfahren Hal94 Da Benutzer sich meistens einfach zu merkende Geheimnisse w hlen hat ein Password Cracking Angriff unter Zuhilfenahme von W rterb chern gro e Erfolge Es ist sinnvoll sichere Passw rter mit gro er Entropie also einem gro en Wert f r die Zuf lligkeit des Passwortes zu w hlen Dies wiederum erh ht die Schwierigkeit f r den Nutzer sich das Geheimnis zu merken Die Unsicherheit von Passw rtern kann durch ein Passwort Managment zwar minimiert werden bei dem der Benutzer regelm ig sein Passwort ndern muss und nur gute Passw rter im Sinne einer hohen Entropie erlaubt sind Da bei diesem Verfahren aber trotzdem gro es Vertrauen in den Benutzer gelegt wird muss ein Passwort Managment immer auch eine Schulung der Benutzer beinhalten Symmetrische Kryptosysteme basieren auf der Tatsache dass sowohl der Claimant der sich authentifizieren lassen will als auch der Verifier der die Au thentifikation berpr ft im Besitz de
96. e die 3 ASPEKTORIENTIERTE PROGRAMMIERUNG 47 Rechenzeit die von einem Programm konsumiert wird Die zweite Eigenschaft ist das Auditing also das berwachen und forensische Pr fen ob das System wirk lich sicher ist aufgrund der Entscheidungen die es getroffen hat Hierzu ist den Autoren von HMO1 keine Literatur bekannt Bei der Java Architektur gibt es verschiedene Teile die betrachtet werden m ssen um ber die Sicherheit der Sprache eine Aussage zu treffen Die wich tigsten Teile sind der Dynamic Class Loader die Byte Code Verification und der Security Manager Javaprogramme werden nicht wie z B bei C C zu einer Datei gelinked sondern es wird der Dynamic Class Loader verwendet der zur Laufzeit dyna misch Klassen l dt Um sicherzustellen dass der richtige Code mit den richtigen Signaturen geladen wurde werden verschiedene Tests durch den Byte Code Ve rifier durchgef hrt Dieser Byte Code Verifier f hrt folgende Kontrollen an den Klassen zur Laufzeit durch e Over und Underflows von Stack Frames e Validit t des Bytecodes e Spr nge d rfen nur zu korrekten Anweisungen f hren e Methodensignaturen m ssen valide Informationen tragen e die Operationen werden auf den richtigen Typen ausgef hrt e Zugriffskontrollen e Objektinitialisierung vor dem ersten Gebrauch e Exceptions und synchronized Statements werden nach FIFO behandelt Der Security Manager ist eine Laufzeitkomponente in der kontrolli
97. e ein Workflow beim JPetstore aufgezeichnet Abbildung 39 zeigt die Startseite des JPetstores Danach wurde ein Fish angeklickt und man gelangt zur Seite in Abbildung 40 Daraufhin wurde auf ein Goldfish wie in Abbildung 41 3 Allerdings befindet sich in der Datei IncludeBottom jsp des JPetStore ein Fehler Dort fehlt ein schlie ender body Tag Ohne diesen ist die erzeugte HTML Seite nicht korrekt und kann nicht vom HTMLRewriter ver ndert werden Dieser Fehler f llt im Normalfall nicht auf da die Browser am Markt diese Tags selbstst ndig erg nzen 9 BEISPIELABLAUF DES DEMONSTRATORS 117 workflow generator workflow editor role management user management Create XML Description Workflow Generator tesi Start Recording Abbildung 38 Starten einer Workflowaufzeichnung JPetStore Fish Dogs Reptiles Cats Birds Abbildung 39 Startseite des JPetstores S JPetStore Fish Dogs Reptiles Cats Birds Fish Abbildung 40 JPetstore FISH 118 angew hlt Die Aufzeichnung kann beliebig viele weitere Webseiten enthalten und wird hier aus Platzgr nden nicht weiter gef hrt Das Beenden der Aufzeichnung 5 JPetStore Fish Dogs Reptiles Cats Birds Goldfish Abbildung 41 JPetstore Goldfish eines Workflows kann im Webtool mit dem Button Save Recorded Workflow get tigt werden Abbildung 42 workflow generator workflow editor role management user management Create XML Descrip
98. e sehr eingeschr nkte Benutzerinteraktion besitzt sind hier SQL und Command Injection Angriffe ausgeschlossen ProAktivApplet Das ProAktivApplet hat im Rahmen des Demonstrators le diglich eine Protokollierungsfunktion Eine Ver nderung dieses Applets k nn te zu einer Falschaufzeichnung des Benutzerverhaltens f hren Falls Ent scheidungen aufgrund der Aussagen dieses Applets beim IDP getroffen wer den sollen k nnte durch eine Ab nderung des Applets ein Zeitfenster f r Angriffe ge ffnet werden Ab dem Zeitraum der Entferung des Hardware Tokens bis zur n chsten routinem igen Kontrolle des Tokens durch das WibukeyApplet k nnte ein Vorhandensein des Hardwaretoken vorget uscht werden Die Authentizit t des Applet selbst wird sichergestellt durch ei ne Signierung des Applets durch den IDP und der durch SSL gesch tzten bertragung an den Client Rechner WibukeyApplet Das WibukeyApplet hat eine Vermittlerrolle zwischen dem IDP und dem Hardware Token Dieses Applet wird genauso wie das ProAk tivApplet per SSL bertragen und vom IDP signiert Erzeugung der Datenbanken Die Datenbanken werden aus einer XML Be schreibungsdatei initialisiert Der Mitarbeiter der diese Datei erzeugt und die Daten in dieser Datei pflegt legt die Sicherheitsbestimmungen die f r die Software gelten fest Diesem Mitarbeiter wird daher in besonderer Weise vertraut Alle anderen Ma nahmen dienen letztlich lediglich dazu dass die se Vertrauensbasis nicht
99. e wird identisch dazu verwendet before belowAnchor log debug before thisJoinPoint toString Listing 5 Beispiel f r before Advice Von diesem Schema unterscheidet sich der around Advice Dieser kapselt die durch den Join Point gew hlte Methode Erst durch den Proceed Befehl wird die eigentliche Methode aufgerufen Dies wird in Listing 6 gezeigt around belowAnchor log debug before thisJoinPoint toString proceed log debug after thisJoinPoint toString Listing 6 Beispiel fiir before Advice Introduction Durch eine Introduction k nnen Ver nderungen an Klassen In terfaces und Aspecten eines Systems durchgefiihrt werden Dies sind statische Ver nderungen die nicht direkt das Verhalten des Systems ver ndern Es ist z B m glich eine Methode zu einer Klasse hinzuzuf gen oder wie in Listing 7 gezeigt eine Klasse von einer anderen erben zu lassen declare parents Man implements Human Listing 7 Beispiel fiir eine Introduction Compile Time Declaration Eine andere statische Anweisung ist die Compile Time Declaration In Listing 8 wird fiir jede Verwendung der log Methode eine Warnung beim Compilieren angezeigt declare warning call void log Listing 8 Beispiel fiir eine Compile Time Declaration Aspect Innerhalb von AspectJ nimmt der Aspect eine Position ein welcher einer Klasse in Java vergleichbar ist Sie beinhaltet Pointcuts Introductions Comp
100. ehungen auf SP Als zweites gibt es den Service Provider SP Dieser ist ein beliebiger web basierter Diensteanbieter oder Informationsanbieter und umfasst praktisch jede Organisation im Web vom einfachen Internetportal ber Banken bis zu Beh r den Circle of Trust Nach Proa ist ein Circle of Trust Siehe Abb 1 eine Verei nigung von Service Providern und Identity Providern die Gesch ftsbeziehungen basierend auf der Liberty Architektur haben Als Beispiel eines Circle of Trust Enterprise Circle of Trust Calender Identity Provider user s company Supply Chain Identity Provider user s bank Online Services Consumer Circle of Trust Abbildung 1 Circle of Trust LAP03c dient das Szenario einer Fluggesellschaft zu deren Service es heute geh rt dass der Fluggast zus tzlich zu der reinen Flugbuchung auch ein Hotelzimmer buchen oder ein Leihauto mieten kann Die Fluggesellschaft hat Vertragsbeziehungen zu weiteren Firmen die Zusatzleistungen fiir den Fluggast liefern und bildet entspre chend des Protokolls ein Circle of Trust Die Fluggesellschaft ist der IDP und die angeschlossenen Firmen sind die SPs Damit sichergestellt ist dass nur den er laubten Vertragspartnern Zugriff gewahrt wird werden diese bei jedem Provider 2 SINGLE SIGN ON 21 SPs und IDPs in eine Tabelle fest eingetragen Es gibt dabei keine Begren zung an wievielen Circles of Trust ein Provider teilnimmt sodass sic
101. eil dieser Diplomarbeit die Authentifikation ber ein Hardware Token Kapitel 5 3 ist muss die Angabe der ben tigten Au thentifikation auf Seiten des Service Provider von der Applikation erstellt wer den und nach Erhalt der Best tigung berpr ft werden Auf Seiten des Identi ty Providers muss eine entsprechende Authentifikationsanfrage erst dahingehend berpr ft werden ob eine gefordete Methode durchgef hrt werden kann und das detaillierte Ergebnis als Authentication Context zur ckgeschickt werden 2 5 Sicherheitsbetrachtung Da die Nachrichten des Liberty Protokolls ber das Internet bertragen werden m ssen die Sicherheitsprobleme des Protokolls und der benutzten Sub Protokolle genau betrachtet werden Nach Eck03 geh ren zu einem richtigen Protokollde sign die Beachtung folgender Sicherheitsaspekte e Vertraulichkeit die Unterbindung unautorisierter Informationsgewinnung e Authentizit t die Echtheit und Glaubw rdigkeit eines Subjekts e Integrit t das Verhindern von unautorisiertem und unbemerkten manipulieren ge sch tzter Daten e Frische Verhindert die Wiedereinspielung von alten abgefangenen Nachrichten Nach diesen Aspekten wird nun das Liberty Protokoll bewertet In der Spezifikation zum SAML Protokoll HM04 wird festgelegt dass wenn die Integrit t und die Vertraulichkeit einer Nachricht ben tigt wird die Ver wendung von HTTP ber SSL 3 0 oder TLS 1 0 gefordert RECOMMENDED wird Au erdem wird empf
102. ein Subjekt seine Identi t t gegen ber einem anderen Subjekt oder System nachweist Bezogen auf Com puter weist ein Benutzer seine Identit t einem System eines Computers nach also eine Benutzer zu Computer Authentifikation Da traditionelle Authentifika tionen basierend auf physischen Inspektionen eines Subjektes f r den Einsatz der Benutzer zu Computer Authentifikation schlecht praktikabel sind BM03 wird diese auf Basis der drei Kernelemente Wissen Besitz und Biometrie aufgebaut SS96 Eck03 Kapitel 10 e Wissen Die Authentifikation auf Basis von Wissen wird in heutigen Systemen am h ufigsten verwendet In der Regel authentifiziert sich der Benutzer durch die Kenntnis eines geheimen Passwortes e Besitz Die Authentifikationsmethode durch Besitz fordert dass der Benutzer im Besitz eines Ger tes Tokens ist Hierbei wird eigentlich das Ger t und nicht der Benutzer authentifiziert Meistens wird die besitzbasierte Authen tifikationsmethode mittels Chipkarten gel st Eck03 Auf der Chipkarte ist ein geheimer Schl ssel gespeichert mit dem die Chipkarte sich mittels eines Challenge Response Verfahren ausweisen kann e Biometrie Biometrische Verfahren zur Authentifikation basieren auf den Merkmalen eines Menschen die ihn eindeutig identifizieren Hierzu geh ren physiologi sche oder verhaltenstypische Eigenschaften eines Menschens Im Webumfeld vor allem dem E Commerce kommt der Authentifikation eines Benutzer noch
103. eine Fehlerseite weitergeleitet Dieses Verfahren hat genau wie das HTTP Basic Verfahren den Nachteil dass Benutzernamen und Passwort im Klartext ber tragen werden Dies k nnte durch Kanalverschl sselung wie HTTPS verhindert werden Diese Authentifikationmethode ist bei einem Wechsel zwischen HTTPS und HTTP den beiden vorherigen aus Sicherheitsaspekten berlegen da Benut zernamen und Passwort nur einmalig bertragen werden Die vierte M glichkeit der Authentifikation ist HTTPS Client Authentifikati on Hierbei wird die Authentifikationsm glichkeit des SSL Protokolls verwendet Es authentifizieren sich ber Zertifikate sowohl der Server gegen ber dem Client als auch der Client gegen ber dem Server sodass eine wechselseitige Authenti fikation stattfindet Der Benutzer mu f r dieses Authentifikationsverfahren im Besitz eines Public Key Zertifikats sein Der ffentliche Schl ssel dieses Zertifikats wird im deployment descriptor auf Seiten der Applikation angegeben Da nur der Benutzer im Besitz des privaten Schl ssel ist ist dieses Verfahren recht sicher 5 AUTHENTIFIKATION IM WEBUMFELD 61 Allerdings muss beachtet werden dass sich nur der Rechner authentifiziert auf dem das Zertifikat gespeichert ist Somit ist es eventuell wiinschenswert dieses Verfahren zus tzlich mit einem der anderen zu kombinieren um sicherzustellen dass sich der richtige Benutzer an dem Rechner befindet 5 1 2 Zugriffskontrolle Die Zugriffkontrolle
104. eine weitere Bedeutung zu Das Vertrauen eines K ufers in einen Verk ufer beruht zum gro en Teil darauf inwieweit er der Identit t seines Ver handlungspartners vertrauen kann Das Vertrauen ist generell gr er wenn der potenzielle Schaden geringer ist FPHKHO0 d h je mehr man der Authentizit t eines Verhandlungspartner vertrauen kann desto geringer ist der zu erwartende 5 AUTHENTIFIKATION IM WEBUMFELD 99 Schaden den man im Gegensatz von einer zweifelhaft authentifizierten Person erwarten k nnte Zur Verbesserung einer Authentifikation k nnen mehrere Methoden gleichzei tig verwendet werden Ein Verfahren bei dem sich der Benutzer mittels Passwort und Token bei einem System anmeldet und zus tzlich per biometrischen Daten gegen ber dem Token ausweisen mu w rde sowohl ein Verfahren nach Wissen sein da der Benutzer ein geheimes Passwort vorweisen muss als auch nach Be sitz da er das Token besitzen muss als auch nach Biometrie da er sich gegen ber dem Token ausweisen muss 5 1 Tomcat Im Normalfall wird eine innerhalb des Tomcat Container laufenden Applikation nicht abgesichert Erst durch Angabe von Sicherheitseinstellungen im deployment descriptor web xml der Applikation wird Tomcat angehalten eine Sicherheits berpr fung durchzuf hren M gliche Einstellungen k nnen dabei wie in der Java Servlet Spezifikation Cow01 Kapitel SRV 12 angegeben zu e Authentifikation e Zugriffskontrolle e Datenintegrit t
105. eitsstufe Strong Credential Sign In beseitigt nach Eck01 nicht alle Sicherheitsl cken Zwar soll zuk nftig Kerberos 5 s u in das Passport System integriert werden und f r mehr Sicherheit sorgen aber es bleibt abzuwarten ob die Sicherheitsma nahmen von Microsoft zur sicheren Verwahrung der Daten ausreichend sind Zwei gro e Internetseiten die Jobb rse Monster und das Online Auktionshaus eBay haben Inttp www passport com 2 SINGLE SIGN ON 15 mittlerweile ihre Zusammenarbeit mit Microsoft im Bezug auf den Passport Ser vice wieder beendet On105 2 1 2 Web Services Federation Language WS Federation Microsoft IBM und Verisign arbeiten an einer Reihe von Spezifikationen fiir zu k nftige Web Service Plattformen AND Security roadmap oder WS genannt Die Teilspezifikation Web Services Federation Language WS Federation wurde im Juli 2003 ver ffentlicht und hat nach BDLD 03 als Hauptziel The primary goal of this specification is to enable federation of identity attribute authentication and authorization information Allerdings ist WS Federation noch in der Entwicklungsphase und es gibt noch kei ne konkrete Implementierung Wahrscheinlich kann erst mit der neuen Windows Version Longhorn mit einem produktiven Einsatz dieser Spezifikation gerech net werden Rob04 Zus tzlich gibt es bei der WS Federation Spezifikation eini ge Uberlappungen mit dem Identity Federation Framework ID FF von Liberty
106. en entsprechenden Parameter t tigen kann Wenn mindestens ein Workflow angelegt wurde k nnen Rollen unter dem Punkt role managment angelegt werden Abbildung 46 Nachdem Rollen an gelegt wurden k nnen diese bearbeitet werden Abbildung 47 wobei spezifiert werden kann welche Workflows dieser Rolle zugeordnet sind und welche Authen tifikationsmethoden sie erfordern Abbildung 48 Nachdem mindestens eine Rolle angelegt wurde k nnen Benutzer unter dem Punkt user management angelegt werden Abbildung 49 Daraufhin bekommt man eine Liste der Benutzer ange zeigt Abbildung 50 In der Bearbeitungsmaske des Benutzers Abbildung 51 wird ein Benutzer einer Rolle zugeordnet Au erdem wird der Name des Identity Providers ber den sich der Benutzer einloggt angegeben Zus tzlich wird der Benutzername und das Passwort f r das einloggen bei der abzusichernden Ap plikation angegeben Das IDP Passwort der SC Firmcode und der SC Usercode dienen zum Erzeugen der IDP Datenbank falls der IDP des Demonstrators ver wendet wird Nachdem alle ben tigten Daten im Webtool eingegeben sind kann unter dem Punkt Create XML Description eine XML Beschreibung erzeugt werden die alle aufgenommenen Workflows und die gespeicherten Daten enth lt Abbildung 52 120 workflow generator workflow editor rolemanagement _user management Create XML Description Workflow Management test Gon Actual State base_0_0 Previous State abort Save
107. en zu k nnen wird eine methodische Vorgehensweise ben tigt Hierdurch k nnen verschiedene Systeme untereinander verglichen werden Wich tig ist es dass die Methode erprobt ist und allgemein anerkannt da auch hier Fehler in der Methode nicht ausgeschlossen werden k nnen Aufgrund der verschiedenen Anforderungen haben sich ber die Zeit auch verschiedene Kriterienkataloge entwickelt Die wichtigsten Kataloge sind laut M Moschgart in Mos03 e D BSI IT Sicherheitshandbuch fSid192 e D BSI Grundschutzhandbuch fSid103b e GB BSI BS 7799 Code of Practice for information security management Sid104 74 e ISO IEC 17799 Information technology Code of practice for information security management Gro04 e ISO IEC TR 13335 1 bis 5 Information Technology guidelines for the management of IT Security GMITS e RFC 2196 Site Security Handbook Fra97 e Cobit AA04 In Eck03 werden noch folgende Kriterienkataloge angef hrt e ITSEC Information Technology Security Evaluation Citeria fSid197 e TCSEC Trusted Computer Systems Evaluation Criteria STA85 Das BS 7799 wird vom englischen BSI herausgegeben und wurde 1999 in einer zweiten berarbeiteten Version ver ffentlicht die international anerkannt ist Aus diesem Standard ist im Dezember 2000 der ISO IEC 17799 hervorgegangen Die ISO hat diesen Standard weiterentwickelt Er stellt eine Sammlung von Emp fehlungen fiir die Informationssicherheit dar
108. ences ITS FED STD 1037 Glossary of Telecommunication Terms 1980 1996 URL http www its bldrdoc gov fs 1037 dir 030 _4486 htm Antone Gonsalves IBM Gets Behind Federated Identity Standard 2004 URL http www techweb com wire networking 51000068 Thomas Gro Security Analysis of the SAML Single Sign on Browser Artifact Profile 2003 URL http www acsac org 2003 papers 73 pdf ISO 17799 Information Security Group The ISO 17799 Directory 2004 URL http www iso 17799 com index htm Sven Haiges Tools zum Verstreben Java Magazin 2003 URL http www javamagazin de itr online_artikel psecom id 423 nodeid 11 html Neil M Haller The S KEY one time password system In Proceedings of the Symposium on Network and Distributed System Security Seiten 151 157 1994 The hsqldb Development Group Hypersonic Database 2004 URL http hsqldb sourceforge net Pieter H Hartel und Luc Moreau Formalizing the safety of Java the Java vir tual machine and Java card ACM Comput Surv 33 4 517 558 2001 URL http doi acm org 10 1145 503112 503115 John Hughes und Eve Maler Technical Overview of the OASIS Se curity Assertion Markup Language SAML V1 1 2004 URL http www oasis open org committees documents php wg_abbrev security 140 Hor04 Torsten Horn SSL mit Tomcat 2004 URL http www torsten horn de techdocs ssl htm HSO 04 Michael Herfert Andreas U Schmidt Peter Ochsenschlager J
109. ens testet Dies setzt eine M glichkeit zum Auslesen der Hardware am Client voraus Im Gegensatz zu einer Passwort abfrage die durch den Browser durchgef hrt werden kann ist daf r eine spezielle Software notwendig Die Verbindung zwischen dem Hardwareinterface und dem IDP wird durch ein signiertes Browserapplet durchgef hrt Es leitet die Anfragen des IDP zu der Schnittstelle des Hardwaretoken weiter Modularit t der Proaktivit t Da ein Hardwaretoken leicht durch den Be nutzer vergessen werden kann muss die Software den Benutzer an diesen Token erinnern Dies erfolgt ebenfalls durch ein Applet Damit dieses Applet durch den Browser geladen und ausgef hrt wird muss das Applet in die Webseite der zu sch tzenden Applikation eingebaut werden Die Anwendungsunabh ngigkeit des Konzepts wird durch den HTMLRewriterAspect gewahrt Dieser modifiziert die erzeugten Webseiten und f gt das Applet hinzu Kommunikation von IDP und Sicherheitsmodul Diese Kommunikation zwischen Client und dem IDP bzw dem Security Aspect muss durch entsprechen de kryptografische Ma nahmen gegen Angriffe gesichert werden Dies wird im Kapitel 7 3 und 2 5 n her betrachtet Daten in den Sicherheitsdatenbanken Durch den Einsatz eines Single Sign On Protokolls ergibt sich eine auch r umliche Trennung des Dienstes von der Anmeldung der Benutzer Der Dienst wie auch der Identity Provider ben tigen daher getrennte Datenbanken in denen lediglich die Informationen hi
110. er Firm Code kann nur mittels einer Firm Security Box in einen Wibu Key programmiert werden Somit ist die Firma Wibu System der Sicherheitsanker und reprasentiert quasi eine Zertifizierungsstelle da nur sie die M glichkeit besitzt Firm Codes zu vergeben beziehungsweise Programmierbo xen f r einen speziellen Firm Code herauszugeben Der User Code kann mit einer Firm Security Box frei definiert werden Der User Code ist dabei genauso wie der Firm Code eine 24 Bit Zahl Somit hat man mit einer Firm Security Box die M g lichkeit jedem Benutzer einen eigenen User Code zuzuteilen Um den Wibu Key 5 AUTHENTIFIKATION IM WEBUMFELD 67 als Authentifikationswerkzeug verwenden zu k nnen werden durch die symmetri sche Verschl sselung zwei Wibu Keys ben tigt Sowohl auf Seiten des Claimant als auch auf Seiten des Verifier Allerdings bietet ein normaler Wibu Key nur die M glichkeit 10 Eintr ge einzuspeichern sodass mit einem Wibu Key auf Seiten des Servers nur maximal 10 Benutzer authentifizierbar sind Erst die Nachfolge version CodeMeter des Wibu Keys mit der M glichkeit ber 1000 Eintr ge zu speichern erm glicht eine bessere Skalierbarkeit FEAL Der FEAL Algorithmus A587 der im Wibu Key verwendet wird wur de urspr nglich von Shimizu und Miyaguchi entwickelt FEAL ist ein Blockchiffre Algorithmus mit 64 Bit Schl ssell nge und sollte eine Alternative zum DES sein Eines der Designziele war ein gro er Geschwindigkeitsgewinn bei Softwa
111. er Gruhn und Dirk Peters Konfigurierbare Sicherheit f r Java Laufzeitumgebungen Seiten 329 340 2004 Philip Bernstein V MHadzilacos und N Goodman Concurrency Con trol and Recovery in Database Systems Addison Wesley 1987 URL http research microsoft com pubs ccontrol T Berners Lee R Fielding und H Frystyk Hypertext Transfer Protocol HTTP 1 0 URL http citeseer ist psu edu article berners lee96hypertext html Amit Basu und Steve Muylle Authentication in e commerce Commun ACM 46 12 159 166 2003 URL http doi acm org 10 1145 953460 953496 D F C Brewer und M J Nash The Chinese Wall Security Policy In IEEE Symposium on Security and Privacy Seiten 206 214 1989 E Biham und A Shamir Differential cryptanalysis of FEAL and N Hash In D W Da vies Hrsg Advances in Cryptology Eurocrypt 91 Seiten 1 16 Berlin 1991 Springer Verlag cafesoft Tomcat Security Overview and Analysis URL http www cafesoft com products cams tomcat security html Scott Cantor und John Kemp Liberty ID FF Bindings and Profiles Specification 2003 URL http www projectliberty org specs Mark D Corner und Brian D Noble Zero interaction authentication In Proceedings of the 8th annual international conference on Mobile computing and networking Seiten 1 11 ACM Press 2002 URL http doi acm org 10 1145 570645 570647 Netscape Communications Corporation JavaScript Guide URL http wp netscape
112. erden mit dem Webtool die Workflows angelegt und jeweils durch Benutzung der Applika tion definiert Daraufhin werden sie nachbearbeitet und die Constraints ber die Benutzereingaben definiert Danach m ssen die User und Roles angelegt werden Dabei m ssen die Workflows den Rol len und Rollen den Usern zugeordnet werden Bei den Benutzern m ssen daneben noch die Authentifikationsmerkmale definiert werden Wenn dies abgeschlossen ist wird eine XML Datei generiert Diese kann manuell um die M glichkeit des 92 7 ApplicationLogin erweitert werden Dies bedeutet das der SecurityAspect sp ter den Benutzer auch an der Wirtsapplikation anmelden kann Aufer dem besteht jetzt die M glichkeit der manuellen Kontrolle der XML Datei bevor sie im n chsten Schritt 8 mit Hilfe des Datenbanktools in die Sicherheitsdatenbank eingebracht wird Ab diesem Schritt ist der SecurityAspect in der Lage seine Aufgabe zu erfiillen und die Trainingsphase beendet 9 Nun wird statt dem Trainingsaspekt der SecurityAspect mit der Applikati on verwoben 8 1 Trainingssuite Die Trainingssuite dient der halbautomatischen Generierung der Beschreibung in der alle Eigenschaften von Authentifikation und Autorisation definiert werden Dazu geh ren die Abh ngigkeiten zwischen Benutzern Rollen und Workflows so wie die M glichkeit f r die Rollen die geforderten Authentifikationsmethoden anzugeben und bei den Benutzern die Authentifika
113. erdurch k nnen Datenbankzust nde der Wirtsapplikation in die Entscheidungsfindung des Monitors einbezogen werden Auch wird es m glich Korrektheitsbedingun gen der Informationen in einer Datenbank nachtr glich zu definieren ohne die Datenbankdefinition zu ndern 4 4 Kombination aus Workflows und RBAC Da in RBAC die durchzuf hrenden Aufgaben im Mittelpunkt der Betrachtung stehen bietet sich eine Kombination mit Workflows an Workflows sind gerade die Aufgaben die ein Mitarbeiter im Rahmen seiner T tigkeit erf llt und lassen sich wie in Abbildung 17 dargestellt in das RBAC Modell einf gen In KS02 zeigen Abbildung 17 Einsatz von Workflows in RBAC R Sandhu und S Kandala die Kombination von RBAC und Workflows Die in dieser Diplomarbeit verwendete Kombination gestaltet sich etwas einfacher da keine Hierarchie der Rollen wie sie in RBAC96 SCFY96 existiert vorgesehen ist Die Rechte interpretieren wir hier als das Recht ob ein Workflow und damit auch alle States des Workflows ausgef hrt werden darf oder nicht Diese Rechte werden von Sandhu und Kandala als explizite Rechte bezeichnet Da aber die 4 REFERENZMONITOR 59 Entscheidung tiber die Korrektheit eines Schrittes innerhalb der Modellierung des Workflows getroffen wird gibt es daneben noch die impliziten Rechte In jedem Schritt wird versucht den Workflow in einen neuen giiltigen Zustand State zu bringen In Abbildung 18 ist ein kleiner
114. erfahren das keine Interaktion mit dem Benutzer ben tigt Ein Benutzer ist im Besitz eines Tokens mit dem er sich regelm ig reauthentifiziert Das initiale Authentifikationsverfahren kann dabei eine Inter aktion mit dem Benutzer fordern aber alle weiteren Authentifizierungen mittels ZIO ben tigen keine In einem solchen Szenario wird dabei eine Authentifika tion nach Wissen und Besitz durchgef hrt Zuerst die initiale Authentifikation nach Wissen zur Benutzererauthentifikation und alle folgenden in der Sitzung zur Computerauthentifikation nach Besitz 66 5 3 Wibu Key Mit Hilfe des Liberty Protokolls siehe Kapitel 2 2 wird es einer Web Applikation erm glicht den Prozess der Authentifikation komplett auszulagern Der Single Sign On Server im Kontext von Liberty der Identity Provider IDP bernimmt die Aufgabe der Authentifikation f r die Web Applikation Das Liberty Protokoll ist dabei so offen gehalten dass es beliebige Authentifikationsverfahren unter stiitzt Der Identity Provider kann je nach Authentifikationsverfahren spezielle Prozeduren mit dem Benutzer bzw Clientrechner durchfiihren Dieser teilt der Web Applikation dem Service Provider nach erfolgreichem Ablauf des Authen tifikationsverfahren mit mit welchem Verfahren sich der Benutzer authentifiziert hat Wir entschieden uns in unserem Demonstrator fiir eine initiale Passwortau thentifikation um ein Verfahren nach Wissen zu integrieren und zus tzlich zu einer m
115. ert wird ob die von einem Programm verlangten Zugriffe auf Ressourcen gew hrt werden oder nicht So wird zum Beispiel im Rahmen des Security Managers auch der Stack kontrolliert Innerhalb des Security Manager existiert der Policy Mana ger dessen Aufgabe es ist die Menge der Rechte zu bestimmen die ein Pro gramm besitzt Dieser Manager ist ber eine bestimmbare Datei konfigurierbar Eine genaue Sicherheitsdiskussion findet sich z B in HMO1 und BBF02 Trotz dieses hohen Sicherheitsniveaus beschreibt z B Marc Sch nefeld in Sch04 einen m glichen Angriff auf dieses Modell Hier ist es n tig dass das Java Runtime Environment dem Angreifer zug ngig ist Bei einem J2EE Appli cationserver ist dies aber nicht der Fall Die gesamte Kommunikation mit diesem Server erfolgt ber Strings die zwischen den Clients und dem Server ausgetauscht 48 werden Ein Angriff auf diesen Server muss also einen Buffer Overflow oder hnli ches ausnutzen falls es keinen anderen Weg gibt den Server zu kompromittieren Eine genauere Betrachtung dieser Problematik findet sich in Kapitel 6 Java bietet also eine ausgereifte und stabile Basis fiir die Entwicklung sowie den Betrieb von webbasierten Diensten Besonders die implementierten Eigen schaften der Sandbox sprechen stark fiir Java und gegen andere Sprachen wie zum Beispiel C Durch den Einsatz von aspektorientierter Programmierung ist es moglich das Design eines Systems stark zu vereinf
116. et werden Mit Shibboleth soll es m glich sein dass der Student sich an seinem Heimatinstitut anmeldet und durch die Vertrauensbeziehung zwischen den beiden Institutionen Zugriff auf die gew nschte Ressource erh lt Schibboleth will somit den Administrationsaufwand f r Institutionen verringern die untereinander digitale Resourcen teilen Durch die starke Ausrichtung von Shibboleth auf den universit ren Bereich ist es nicht direkt auf den Einsatz in der E Commerce Gesch ftswelt bertragbar Wenn ei ne Firma X mit einer zweiten Firma Y eine Gesch ftbeziehung pflegt hei t es noch lange nicht dass auch automatisch ein Kunde der Firma X das Angebot der Firma Y nutzen darf Dies ist im universit ren Bereich der Fall da hier im Normalfall allen Mitarbeitern einer Institution Zugriff auf Ressourcen gew hrt werden soll 2 1 4 Kerberos Das Kerberos Authentifikationssystem SNS88 wurde im Rahmen des Athena Projektes am MIT entwickelt mit dem Ziel Anfragen auf Netzwerkressourcen authentifizieren zu k nnen Mit Kerberos wird ein Single Sign On Konzept rea lisiert Die aktuelle Version ist 5 Ein Benutzer Principal genannt bekommt nur Zugriff auf eine Netzwerkresource wie z B NFS oder Remote Login wenn er eine Authentizit tsbescheinung von einem vertrauensw rdigen Kerberos Server vorweisen kann Der Kerberos Server verwaltet in einer Datenbank die geheimen Schl ssel aller beteiligten Benutzer authentifiziert die Benutzer und generiert
117. eteiligten Service Provider gestartet Der Ablauf einer von Benutzer direkt initiierten Authentifi kation ist in Bild 34 dargestellt Der Benutzer wird mit der Startseite des IDP begr t und bekommt die Auswahl ob er eine Authentifikation per Passwort oder Wibu Key w nscht Falls er Passwort Authentifikation angeklickt hat wird er zur ActionClass IndexPwAction java weitergeleitet Daraufhin bekommt der Benutzer eine Eingabemaske pr sentiert und kann seinen Benutzernamen und entsprechendes Passwort eingeben Nach der bermittlung und berpr fung der Daten wird dem SourcelD Framework mittgeteilt dass sich der User erfolgreich authentifiziert hat Im Falle eine Authentifikation mittels Wibu Key wird erst berpr ft ob sich der Benutzer schon per Benutzernamen und Passwort authen 106 entered directly from User Browser isp index jsp NV EE org diplom idp wibukey loginAction java jsp logonSp jsp org diplom idp logonPwPostAction java jsp logonWibukey jsp org diplom idp wibukey LogonPostAction java jsp logonWibukeyApplet jsp Browser querys Applet WibukeyApplet java Wibukey org diplom idp wibukey responseAction java Abbildung 34 IDP Ablauf tifiziert hat und im negativen Fall eine Eingabemaske fiir Benutzernamen und Passwort gesendet Nach erfolgreicher Eingabe wird der Browser des Benutzers auf die Seite jsp logonWibukeyApplet jsp geleitet in der das Applet zur W
118. f r Autovermietung ein Auto mieten will muss er nicht einen zweiten Benutzernamen und ein zweites Passwort f r dessen Webseite wissen sondern es reicht die einmalige Authentifikation bei der Fluggesellschaft Das Tochterunternehmen vertraut der Fluggesellschaft dahingehend dass sich der Reisende dort korrekt authentifiziert hat und bernimmt diese Benutzerdaten In Kapitel 2 1 wird kurz auf Identity Management eingegangen und die exis tierenden Single Sign On Protokolle beschrieben In Kapitel 2 2 wird die Liberty Alliance vorgestellt und eine detaillierte bersicht des Liberty Protokollablaufs und der dazu ben tigten Zusatzprotokolle und technischen Grundbausteine ge liefert Abschlie end wird in Kapitel 2 6 auf das Projekt SourcelD eingegangen das f r die Implementierung des Protokolls in eine Applikation verwendet wird 14 2 1 Identity Management in bisherigen Systemen Um ein Single Sign On Konzept verwirklichen zu k nnen m ssen die verschie denen Identit ten eines Benutzers die bei unterschiedlichen Organisationen ge speichert sind verwaltet und verkniipft werden Identity Management wie in der Einleitung eingef hrt umfasst die Abwicklung der Authentifikation eines Indivi duums in einem verteilten Netz und die Verwaltung des Zugangs zu den Resout cen die dem Individuum zugeordnet sind Im Folgenden werden die Protokolle die im Kontext von Single Sign On und Webapplikationen genau dieses leisten kurz erl utert und vergli
119. fft Bei der technischen Ausf hrung be stehen verschiedene M glichkeiten diese Quelle zur Verf gung zu stellen Hierbei stellen sich zwei Wege zur Auswahl e Speichern der Workflows in XML Dateien und Verwenden dieser Dateien als Basis oder 96 e Ubertragen der XML Dateien in ein relationales Schema und Speicherung in einer Datenbank Bei der ausschlie lichen Verwendung von XML Strukturen wird es n tig f r die Dauer einer Session ein Document Object Model DOM der Struktur im Speicher zu behalten oder bei jedem Zugriff die XML Struktur neu auszuwerten Dies ist entweder extrem speicherintensiv oder relativ langsam Auch w re der Zustand einer Session nur der Session bekannt Erweiterte Zugriffsschutzregeln wie sie z B Chinese Wall siehe 4 2 vorsieht w ren in diesem Fall nicht zu implementieren Es wurde daher die Verwaltung der Datenbasis an ein Datenbanksystem gegeben und die Hypersonic Database hDG04 verwendet Hierdurch ist eine persistente Speicherung der Zust nde f r jeden Benutzer sowie ein effizienter Zugriff durch die Concurrency Control Mechanismen der Da tenbank auch bei vielen gleichzeitigen Sessions auf dem Server gew hrleistet Hier sei auf die Literatur von Ramakrishnan und Gehrke Ram98 sowie Bernstein et al BHG87 verwiesen Es werden im Rahmen des Demonstrators zwei getrennte Datenbanken neben den eventuell vorhandenen Datenbanken der Wirtsprogramme verwendet Eine Datenbank wird vom IDP verwendet und
120. fgabenstellung bedeutet f r den Programmierer in der Entwicklung dass er in jede Methode Sourcecode einbinden muss Am Beispiel des Tomcat Application Server wird in Abbildung 9 gezeigt wie stark diese Verteilung ist Die senkrechten Balken repr sentieren die Klassen wohingegen die waagerechten f r die Aufgabe Logging stehen Daneben bedeutet dies f r den Programmierer dass er an jedem dieser Punkte immer wieder die gleichen Befehle im Code einf gen muss Die wichtigsten hierbei sind e Der Importbefehl import org apache commons logging e die Initialisierung der Logklasse private static Log log LogFactory getLog example class und e in jeder Methode das Ausf hren des loggens log debug Entering Methode xyz 3 ASPEKTORIENTIERTE PROGRAMMIERUNG 37 Falls nun eine nderung in der Loggingstrategie gew hlt wird z B logp statt log so muss der gesammte Sourcecode des Projektes durchsucht werden um diese nderung durchzuf hren Dies ist sehr fehleranf llig da es in gr eren Projekten durchaus langwierig ist alle Stellen zu finden die wirklich ver ndert werden m ssen und grep nur manchmal hilft Aufgrund der Tatsache dass es offensichtlich Module gibt die durch den ob jektorientierten Ansatz nicht isoliert werden k nnen wurde eine Erweiterung der Objektorientierung entwickelt Diese versucht Aspekte in einer Software wie z B Logging zu isolieren und in einer kompakten Form zu beschreiben In
121. genaueren Interaktionskontrolle zus tzlich eingebaut werden Die Kontrolle ber den Aktivit tsstatus eines Benutzers muss dabei auf Sei ten des Identity Providers sein da ein Benutzer an mehreren Service Providern gleichzeitig angemeldet sein und arbeiten kann Nur der Identity Provider hat genauen berblick an welchen Service Providern der Benutzer arbeitet und wie lange die Lebensdauer der Authentication Assertions f r jeden Service Provider ist Als Zeitspanne wird bei unserem Demonstrator die Lebensdauer einer vom Identity Provider ausgestellten Authentication Assertion genommen Diese Zeit 8 SPEZIFIKATION UND IMPLEMENTIERUNG 115 spanne wird wie in Listing 32 in der Konfigurationsdatei von SourcelD auf Seiten des Identity Providers in der Datei sourceid sso xml spezifiziert lt idp authn lifespan gt 1800 lt idp authn lifespan gt Listing 32 Auszug aus der sourceid sso xml 116 9 Beispielablauf des Demonstrators Im folgenden wird die Verwendung der in Kapitel 8 vorgestellten Software de monstriert Der Ablauf gliedert sich in die bereits beschriebenen Einheiten e Training e Editieren der XML Beschreibung e Erzeugung der Sicherheitsdatenbank e Einsatz des Systems Die Durchf hrung wird exemplarisch am JPetstore von iBatis gezeigt Die Ap plikation wird hierbei nicht ver ndert 9 1 Erzeugen der Sicherheitsbeschreibung Um die Traingsphase durchf hren zu k nnen muss der TrainingAspect mit der Web Ap
122. glich f r externe Personen zu halten Hierzu kann das in Abbildung 25 illustrierte Middle Tier Back End Client Applikationsserver Datenbanken Abbildung 25 Drei Schichten Modell Three Tier Modell verwendet werden vgl Wik Eine m gliche Massnah me sind Firewalls die den Zugriff auf die entsprechenden IP Ports verhin dern Identity Provider Der Identity Provider ist das zentrale Modul in dem die Authentifikation f r verschiedene Dienste durchgef hrt wird Ein Ausfall des Identity Providers hat zur Folge dass die auf ihm basierenden Dienste nicht weiter verwendbar sind da f r keinen Benutzer eine Authentifikati on durchf hrbar ist Er stellt eine ideales Ziel f r eine Denial Of Service Attacke dar Aufgrund dieser zentralen Bedeutung gilt es den Server der den Identity Provider beheimatet speziell abzusichern siehe 6 1 Da der IDP in Java realisiert ist m ssen die in Kapitel 3 6 getroffenen Betrachtungen zur Si cherheit von Java und die in Kapitel 6 3 aufgezeigten Angriffsm glichkeiten auf eine Websoftware beachtet werden 86 Da die erzeugte Webseite statisch ist sind die im Kapitel 6 3 ausgef hrten XSS Angriffe weniger wahrscheinlich Daf r muss aber speziell die M glich keit von SQL und Command Injection Angriffen im Einzelfall untersucht werden securityAspect F r den SecurityAspect gelten prinzipiell die berlegungen die f r den Identity Provider zutreffen Da der SecurityAspect allerdings nur ein
123. gurationsdateien von SourcelD eingerichtet werden und an die SourcelD API Schnittstellen angepasst werden Die Requests die im Liberty Pro tokoll m glich sind m ssen von der Applikation sowohl selbst initiiert als auch entsprechende Antworten von ihr verarbeitet werden k nnen 32 Damit eine Anwendung mit Hilfe von SourceID an einem Circle of Trust teilnehmen kann muss einiges vor dem Aufruf der API konfiguriert werden e In der Datei web xml werden die Schnittstellen von SourcelD Java einge tragen Diese Schnittstellen werden sowohl von den anderen Teilnehmern des Circle of Trust angesprochen als auch direkt von der Applikation und m ssen somit direkt aus einem Browser heraus erreichbar sein Beispielhaft ist in Listing 1 der Eintrag des SourcelD SSO AuthnRequestor abgebildet Die nach au en hin offene Adresse ist die Adresse der Applikation an sich plus den Zusatz sso authnRequest z B http localhost 8080 jpetstore sso authnRequest lt servlet gt lt servlet name gt SourceID SSO AuthnRequestor lt servlet name gt lt description gt Provides Service Provider SP Authentication Request Services lt description gt lt servlet class gt org sourceid sso servlets AuthnRequestor lt servlet class gt lt servlet gt lt servlet mapping gt lt servlet name gt SourceID SSO AuthnRequestor lt servlet name gt lt url pattern gt sso authnRequest lt url pattern gt lt servlet
124. h transitive Beziehungen ergeben k nnen Federated Digital Identities Falls ein SP und ein IDP im Sinne von Liberty eine Beziehung innerhalb eines Circle of Trust aufgebaut haben hat der Benut zer die M glichkeit seine beiden Accounts beim SP und beim IDP miteinander zu verkn pfen federate Er muss sich dabei auf beiden Portalen einloggen und angeben dass er die beiden Accounts verbinden will Falls er die beiden Accounts f deriert hat muss er sich bei einem erneuten Login nur noch beim IDP authen tifizieren wo er sich mit seinen Logindaten des IDPs anmeldet Falls der Benutzer vom IDP akzeptiert wird reicht dieser ihn weiter zum SP der dem IDP vertraut dass sich der Benutzer korrekt authentifiziert hat Da sich sowohl SP als auch IDP merken welchen lokalen Account sie mit dem entfernten Account f deriert haben ist es dem SP m glich auf den lokalen Benutzer zu schlie en sodass der Benutzer seinen Account beim SP nutzen kann ohne sich daf r beim SP ein zweites Mal authentifizieren zu m ssen Simplified Sign On Der IDP ist beim ID FF Protokoll ein Single Sign On Server der das Login Portal des Circle of Trust darstellt Dieser teilt seinen im Circle of Trust angeschlossenen SPs bei Bedarf mit ob und wie sich der Benutzer bei ihm authentifiziert hat Somit ist dem Benutzer ein vereinfachtes Sign On erm glicht Nachdem er seine Accounts beim IDP und den SPs f deriert hat kann er nach einer initialen Authentifikationphase beim
125. hert wird in welchem Zustand der jeweilige Workflow ist Bei einem Zu standswechsel wird der neue Zustand vermerkt 8 SPEZIFIKATION UND IMPLEMENTIERUNG 97 FSMState lt gt Abbildung 29 relationales Modell der Datenbank I applicationLogin Abbildung 30 relationales Modell der Datenbank II 98 Der IDP verwendet die in Abbildung 31 gezeigte Struktur In der accounts Tabelle werden die Benutzer mit ihren Authentifikationsdaten erfasst Die ver schiedenen Federations die ein Benutzer potentiell mit verschiedenen Service Providern haben kann werden durch die Tabelle federations erfasst vergl Ka pitel 2 3 accounts usercode remote_name federations local_nam a providerlD Abbildung 31 relationales Modell der IDP Datenbank 8 4 Datenbanktool Das dbtool konvertiert die XML Beschreibung in die relationale Repr sentation Hierzu wird die XML Datei serialisiert und mit Hilfe von SAX Meg04 interpre tiert Eine weitere Funktion ist das Entfernen und Neuaufbauen aller existieren den Tabellen in der Datenbank 8 5 Security Aspect Der SecurityAspect umh llt wie in Abb 32 gezielt die Methoden welche vom Applikationserver aufgerufen werden und an die die Parameter der Interaktion des Benutzers bergeben werden Ein solcher Parameter besteht immer aus einem Schl
126. hrei bung Die Vorteile dieses Konzepts liegen in seiner Modularit t Das Sicherheits modul kann als eigenst ndiges Projekt entwickelt werden und in verschiedenen Applikationen zum Einsatz kommen Hierdurch senken sich die Entwicklungs kosten f r diesen Bereich der Software Gleichzeitig sind weniger Fehler in dem Sicherheitsmodul zu erwarten da es eine abgeschlossene Einheit darstellt wel ches intensiv getestet werden kann Auch wird durch die Entfernung von Sicher heitssourcecode aus der Wirtsapplikation diese einfacher Strukturiert Auch dies reduziert die Kosten in der Entwicklung der Software Falls durch Ver nderungen der Organisationsstrukturen im Einsatz der Wirtsapplikation Ver nderungen am Sicherheitsmodul erforderlich machen so kann durch einen Austausch des Sicherheitsmoduls auf einfache Art und Weise eine neue Sicherheitsarchitektur wie z B Chinese Wall eingef hrt werden Durch die Trainierbarkeit wird eben falls m glichen nderungen der Organisationsstruktur Rechnung getragen da die vorgegebenen Arbeitsabl ufe Workflows jederzeit angepasst gel scht oder 78 neu erstellt werden k nnen und dadurch flexibel an die Bedingungen angepasst werden Authentifikation F r die Authentifikation findet das in Kapitel 2 2 beschrie bene Liberty Protokoll Anwendung dessen Einsatz in Kapitel 2 1 6 motiviert wird Durch die Trennung von Applikation und Loginserver ist es m glich den Log inserver als eigenes Schutzobjek
127. ibu Key Authentifikation eingebettet ist Diesem Applet werden der benutzerabhan gige Firmcode und Usercode des Wibu Keys tibermittelt sowie die zufallig erzeug te Challenge und der Salt Wert Seite 112 Die Antwort des Applet folgt an die Action Class responseAction java Diese vergleicht die Response des Applets mit dem eigenerzeugten Ergebnis und informiert danach das SourceID Framework Eine Authentifikation die durch einen Service Provider initiiert wurde l uft unterschiedlich ab Siehe Abbildung 35 Da eine Authentifikationsaufforderung von einem Service Provider tiber das Liberty Protokoll an den Identity Provi der versendet wird landet die Anfrage erst beim SourcelD Framework Dieses leitet nach berpr fung der Aufforderung an die in den Konfigurationsdateien eingetragene Seite des Identity Providers weiter Diese Seite entscheidet je nach Anforderung ob eine Authentifikation per Passwort oder Wibu Key stattfindet Die Webseiten sind hnlich gestaltet wie Webseiten der direkt initiierten Au thentifikation Beim Abschluss der Authentifikation wird die Kontrolle zur ck an das SourcelD Framework bergeben welches den authentifizierten Benutzerna men und die Authentifikationsmethode an den Service Provider ber das Liberty Protokoll zur ck Zus tzlich zu den ben tigten Einstellungen die unter Kapitel 2 6 beschrie ben sind m ssen f r die Funktion des Identity Providers mit SourcelD bei einer vom Service Provider initiierte
128. ich auch aus dem Vorhandensein des JPetStore in Struts der als Standardbeispiel in der Webprogrammierung gilt 8 6 Referenzmonitor Der durch den SecurityAspect verwendete Referenzmonitor befindet sich in der Klasse SecurityMonitorHistory Wie der Name schon andeutet entscheidet dieser Referenzmonitor auf der Basis der bereits get tigten Interaktionen eines Anwen ders mit der Software und verbietet jede Handlung die nicht explizit erlaubt ist Als Entscheidungsbasis wird die in 8 3 beschriebene Sicherheitsdatenbank ver wendet in der lediglich Positivregeln hinterlegt sind Bei einem Zugriff wird nach einer Regel gesucht die diesen erlaubt Wenn keine Positivregel existiert wird der Zugriff verwehrt Dies bildet die Basis eines Konzepts der minimalen Rechte wie es z B in FK92 gefordert wird Auf der Entscheidungsbasis wird das in Kapitel 4 2 beschriebene rollenbasierte Sicherheitsmodell RBAC verwendet Dementsprechend wird bei jeder Interaktion des Benutzers mit dem System auf Basis des Benutzernamens und der SessionID ermittelt e in welchen Rollen der Benutzer Mitglied ist und daraus die Menge der Workflows gebildet 8 SPEZIFIKATION UND IMPLEMENTIERUNG 103 e aus den Rollen wird auch die Menge der ben tigten Authentifikationsmerk male hergeleitet und e der Zustand der einzelnen Workflows bestimmt Rollen Benutzer Sessions und Workflows h ngen wie in Abbildung 28 gezeigt zusammen Die SessionID wird vom Tomcat vergeben und
129. ichert sind Ein hnliches Konzept wird in ASKP00 verfolgt Proaktivit t Die Grundbausteine eines proaktivem Systems sind nach A Sa lovaara und A Oulasvirta 5004 1 working on behalf of or pro the user and 2 acting on their own initiative Ein proaktives System ist also ein System das f r einen Benutzer arbeitet aber auch aus Eigeninitiative heraus handeln kann Die Autoren sehen Proaktivit t dabei als ein Teil von context awareness also der F higkeit eines Programms sich seiner Umgebung bewusst zu sein David Tennenhouse beschreibt ein proaktives System in einer mehr techni schen Sicht in Ten00 als 7 KONZEPT UND SICHERHEITSBETRACHTUNG 79 Proactive systems will be intimately connected to the world around them using sensors and actuators to both monitor and shape their physical surroundings Ein proaktives System verf gt hiernach ber Sensoren und t tigt selbststandig im Sinne des Benutzers Uberwachungen trifft Entscheidungen und fiihrt Aktionen aus Der Benutzer steht dabei sowohl tiber dem proaktiven System im Sinne eines Uberwachers als auch innerhalb des Wirkungskreises des Systems in dem sowohl der Benutzer direkt auf das proaktive System einwirken kann als auch das proaktive System auf den Benutzer Die Verwendung von Hardwaretoken als Merkmal zur Authentifikation ist mit dem Problem behaftet dass jede Person die den Token besitzt auch vom System als legitimer Benutzer akzeptiert wird Deshalb s
130. icht m glich auf wichtige Dateien des Betriebssystems Zugriff zu nehmen Hierdurch kann der Angriff an sich nicht verhindert werden aber eine Kompromittierung des Systems wird verhindert In JF03 stellen J Brittain und I F Darwin fest dass eine Kombination aus dem Security Manager von Tomcat und chroot ein sehr hohes Sicherheitsniveau darstellt Auch wenn der Security Manager sehr sicher ist so kann es doch un entdeckte Sicherheitsl cken geben die einem Angreifer Zugriff auf das darunter liegende System gew hren k nnte Durch den Einsatz der chroot Umgebung wird diesem vorgebeugt Allerdings ist auch dies nicht absolut sicher da auch das Betriebssystem Fehler enthalten kann Auch wenn sich die Entwickler gr te M he gegeben haben den Tomcat so si cher wie m glich zu machen kann diese Sicherheit durch ein schlecht entwickeltes Programm beeintr chtigt werden In JF03 werden verschiedene Schwachstellen vorgestellt Sie haben gemein dass sie auf konstruierten Anfragen beruhen mit dem Ziel die Sicherheit des Tomcat zu umgehen Cross site scripting Eine der h ufigsten Attacken auf Webdienste ist das Cross Site Scripting XSS Hierbei geht es darum einen fremden Browser dazu 72 zu bringen Skripte von einem anderen Server auszuf hren und so Daten ber den fremden Benutzer sammeln zu k nnen Um einen Angriff durchf hren zu k nnen sucht ein Angreifer einen Server auf dem er z B in Diskussionsforen folgendes hinte
131. ider in der Lage das Pseudonym zu ihren Accounts zuzuordnen Dies wird f r jede Verkn pfung eines Account neu generiert sodass bei mehreren transiti ven Beziehungen die Accounts eines Benutzer mit einer Kette von verschiedenen Pseudonymen verbunden sind Anonymit t Unter Anonymit t wird bei Liberty verstanden dass ein Pro vider der nur einzelne Attribute der Benutzeridentit t wissen muss auch nur diese zur Verf gung gestellt bekommt Das k nnte zum Beispiel ein Wetterdienst Service Provider sein der nur die Postleitzahl zur Bestimmung des Wohnortes eines Benutzers braucht Es wird durch diese Attributs Sparsamkeit auf Seiten des Service Provider ein gewisser Grad an Anonymisierung erreicht bzw eine De Pseudonymisierung vermieden sodass es dem Service Provier so nicht m glich ist auf die Identit t eines Benutzers zu schlie en Allerdings k nnen Service Pro vider und Identity Provider zusammen auf die Identit t des Benutzers schlie en da das Pseudonym beiden bekannt ist und der Identity Provider die Identit t des Benutzers zu diesem Pseudonym kennt 2 4 Protokollaufbau Nach CK03 besteht das Liberty Protokoll aus 7 Protokollkomponenten die als Profile bezeichnet werden Diese Profile spezifizieren die technische Implementie rung der oben genannten ID FF Schl sselkomponenten Das wichtigste Profil ist das Single Sign On and Federation Profil und wird im Folgenden mit den verwendeten Sub Protokollen und Techniken genauer e
132. ie ankommenden Strings vor einer Auswertung in der Software gepr ft werden Ein Angriff der nicht durch Filter erkannt werden kann ist das Session Hi jacking Hier wird eine Sitzung durch einen Angreifer bernommen Dies kann auf zwei verschiedene Weisen erfolgen wie von J Prosise in Pro85b angef hrt wird erraten einer ID oder das Session ID Cookie stehlen Der erste Weg ist nicht erfolgversprechend da die ID eine sehr grosse Zufallszahl ist Der Angreifer muss somit in den Besitz der Cookies kommen Um die bertragung des Cookies zu sch tzen muss diese krytografisch gesch tzt werden Hier bietet sich SSL an Aber auch dann kann das Cookie noch gestohlen werden Hierzu f hrt J Prosi se XSS Man In The Middle Angriffe und physikalischen Zugriff auf den Client als M glichkeiten an Weiter stellt er fest dass es gegenw rtig nicht m glich ist einen solchen Angriff abzuwehren Es kann lediglich dem Angreifer sehr schwer gemacht werden Ein weiterer wichtiger Baustein in der Absicherung des Tomcat ist die Ver wendung von SSL zum Schutz der Kommunikation Da die Kommunikation im Internet nicht vertraulich abl uft ist jede Information frei lesbar Um dies zu verhindern muss ein sicherer Kanal geschaffen werden in dem die Pakete ver schl sselt bertragen werden Mehr dazu findet sich im Kapitel 8 8 1 6 4 Beurteilung von Sicherheit Um die Sicherheit eines Systems zu beurteilen und eine Aussage ber das Sicher heitsniveau treff
133. ikation durch gef hrt und der Benutzer zur ck zum JPetstore geleitet Daraufhin bekommt der Benutzer die Ausgabe des JPetstores abge ndert durch den HTMLRewriter Aspect angezeigt Abbildung 54 Hier ist das ProAktiv Applet auf der linken Sto re ees Fish Dogs Reptiles Cats Birds Fish Wibukey is present Identity Provider Security Aspect Abbildung 54 Produktiveinsatz 9 BEISPIELABLAUF DES DEMONSTRATORS 125 Seite zu sehen Dieses Applet ist im Normalfall grin Wenn der Benutzer l ngere Zeit inaktiv gewesen ist wechselt das Applet auf die Farbe rot Abbildung 55 Falls der Benutzer im weiteren Verlauf den Workflow verl t und auf eine nicht Wibukey is present Abbildung 55 ProAktiv Applet erlaubte Seite zugreifen will bekommt er stattdessen eine Fehlerseite angezeigt Abbildung 56 Daraufhin kann er zur letzten Seite zur ckkehren um den Work You are not allowed to be there Go back Back to Base Pase Abbildung 56 Fehlerseite flow fortzusetzen oder kann auf die Startseite wechseln um einen neuen Workflow anzufangen 126 10 Fazit und Ausblick Das in dieser Diplomarbeit vorgestellte Konzept hat es erm glicht zu einer Ap plikation eine neue Funktionalit t auf einfache Weise hinzuzuf gen Durch diese hinzugef gte Funktionalit t erh lt das System eine neue Qualit t da eine flexi ble und dynamische Authentifikation und Autorisation zur Verf gung steh
134. ile Time Declarations und Advices Daneben k nnen noch Methoden Va riablen usw wie in jeder normalen Javaklasse definiert werden Ein wichtiger Parameter bei der Erzeugung eines Aspects ist die Aspect As sociation Hierbei wird festgelegt wann eine Instanz eines Aspects erzeugt wird Hierbei unterscheidet AspectJ drei m gliche Kategorien 3 ASPEKTORIENTIERTE PROGRAMMIERUNG 41 e pro virtueller Maschine die Standardeinstellung e pro Objekt e pro Kontrolfluss Die Standardeinstellung entspricht in Java einem Singleton Es existiert nur eine Instanziierung des Aspects in der virtuellen Maschine Pro Objekt meint dass fiir jedes Objekt mit dem ein Aspect verbunden wird der Aspect instanziert wird Die Pro Kontrollflussassoziation control flow association erm glicht es f r einen Kontrollfluss Informationen tibergreifend zu speichern Diese Information steht in allen Point Cuts des Aspects innerhalb dieses Kontrollflusses zur Verfiigung 3 1 2 Der Weaver Beim Verweben der Aspecte mit einem System k nnen verschiedene Wege gegan gen werden e Source Code Weaving e Byte Code Weaving e Weaving mithilfe eines class Loaders Beim Source Code Weaving wird der Sourcecode der Aspecte mit dem Sourcecode des Systems verwoben und dieser erzeugte Source wird dann durch den normalen Javacompiler tibersetzt Der zweite Ansatz erzeugt erst durch den Javacompiler Bytecode der im n chsten Schritt durch den AspectJ Weaver verwoben wird
135. ination aus Wissen und Besitz erfolgen Siehe Kapitel 5 3 und 8 9 Als Wis sen dient der Vorweis eines geheimen Passwort und als Besitz der zum Benutzer geh rende WIBU KEY Urspr nglich sollte der Nachfolger des WIBU KEY Co demeter von Wibu Systems integriert werden allerdings gab es f r diesen noch keine Java API Die Schw chen des WIBU KEY werden in Kapitel 5 3 erl utert Da es kein einheitliches Framework f r die Integration eines Hardwaretoken in eine Webapplikation gibt bzw sehr wenig Literatur zu dieser Thematik erfolgt die Authentifikation durch den WIBU KEY durch ein von den Autoren entworfe nen Challenge Response Verfahren Eine genaue berpr fung dieses Challenge Response Verfahren wurde nicht durchgef hrt da nur gezeigt werden sollte dass es prinzipiell m glich ist ein Authentifikationsverfahren mit Token in eine Web Applikation nachtr glich zu integrieren Daher wird von der bernahme ohne eine genaue berpr fung der Verfahrens in dieser Form abgeraten Die von SUN gegr ndete Liberty Alliance hat mit ihrer ersten Spezifikation ID FF einen soliden Grundbaustein f r Federated Identity geleistet Das Kon kurrenzprodukt von Microsoft WS hat zuletzt einen global Player an Liberty verloren Aufgrund von Kundennachfragen hat IBM nun auch in ihren Tivoli Ac cess Manager das Liberty Protokoll implementiert Ausserdem ist IBM ein Board 128 Member bei Liberty geworden Gon04 Dies verleiht der Bedeutung der Liberty
136. inbindung des Applets zur Realisierung der Proaktivit t Um diese Ziele zu erreichen wurde der Buildprozess wie in 3 4 beschrieben ver wendet Dadurch wird es m glich jede JSP Seite nachtr glich zu ver ndern Er reicht wird dies durch eine Kapselung des verwendeten Responseobjekts welches im Aspect der eigentlichen Methode bergeben wird Dies wird in Listing 25 gezeigt WrappedResponse wrappedResponse new WrappedResponse response request proceed request HttpServletResponse wrappedResponse Listing 25 Anderungen an der web xml Sobald die Ausf hrung beendet wird erfolgt das Umschreiben der erzeugten HTML Seite Dazu wird lediglich eine Methode der gekapselten Klasse aufgerufen Inner halb dieser Methode wird dann eine Ersetzung der Tags lt body gt und lt bo 8 SPEZIFIKATION UND IMPLEMENTIERUNG 105 dy gt durchgef hrt durch die eine Tabelle eingef gt wird deren Eintr ge entspre chend gesetzt werden Bei der Ersetzung der Tags muss beachtet werden dass diese Tags case sensitive sind und es auch Parameter gibt die erhalten bleiben m ssen Daher gestaltet sich der Ersetzungsbefehl relativ aufwendig wie es in Listing 26 zu sehen ist input input replaceFirst le na gt lt 1_ 2 gt lt table_border 1 11 _width e 100 gt lt tr gt lt td_colspan 2 Listing 26 nderungen an der web xml Eine wichtige Einschr nkung dieses Verfahrens ist dass es darauf vertraut dass der vorhan
137. ind und auch nicht unbefugt lesend zugegriffen werden k nnen Bei den Daten die der Zugriffskontrolle zur Basis dienen gelten diese Punkte auch Da bei der Zugriffskontrolle benutzer und rollenspezifische Rechte vergeben werden ist zu hinterfragen wie diese Rechte erzeugt werden und von wem Bei einer fertig konfigurierten Software muss dem Hersteller vertraut werden dass die vorgegebenen Rechte genau den gestellten Anforderungen entsprechen Diese Arbeit zeigt dass es m glich ist ein generisches Sicherheitsmodul zu entwerfen welches in eine bestehende Applikation integriert werden kann und die Eigenschaften der Authentifikation und Autorisation hinzuf gt Die Figenschaf ten des Moduls werden in den folgenden drei Abschnitten definiert Identity Management Das Identity Management fasst alle Prozesse und In frastrukturen zusammen welche f r eine Anlage Verwaltung und Benutzung von digitalen Identit ten unter Beachtung einer Policy ben tigt werden Neben dem bereits erw hnten User Management m ssen noch andere Infra strukturen bereitgestellt werden Diese sind wie in Vog04 und Lew03 gezeigt wird e der Directory Service also eine Datenbank in der die digitalen Identit ten und deren Rechte verwaltet und gespeichert sind 10 e das Bereitstellen von Authentisierungsmechanismen mit deren Hilfe die Identit t einer Person berpr ft werden kann e das Access Management zur Kontrolle ob ein authentifizierter Ben
138. inden verschiedene Ans tze Anwendung Intrusion Detection Systeme IDS sollen Portscans und andere netzbezogene An griffe erkennen und durch ein aktives Reagieren den Angriff unterbrechen Wie in VVK03 IDS00 und DCW 99 zu sehen ist reicht aber die Existenz ei nes IDS Systems an sich nicht aus Eine sorgf ltige Auswahl und Konfiguration ist notwendig Bufferoverflow Angriffe k nnen durch Speicherschutzsysteme wie PAX siehe SPP 04 und Filter siehe JF03 in den Diensten begegnet werden Falls ein Angriff Erfolg hatte kann dies durch vergleichende Programme erkannt werden Ein Vertreter dieser Klasse von Programmen ist Tripwire 1ri04 mit dessen Hilfe ausgew hlte Dateien nach Ver nderungen durchsucht werden k n nen Um die Folgen eines Angriffs gering zu halten und die Ausfallzeiten zu mini mieren kommen redundante Systeme zum Einsatz Unerl sslich sind Backups die es erm glichen auf vorherige konsistente Zust nde des Systems zur ckzugreifen Ein funktionierendes Backup ist ein integraler Bestandteil jedes Schutzsys tems da durch dieses die M glichkeit besteht den Server wieder in einen funk tionierenden Zustand zu versetzen Daher ist bei einem Backup das Vollst n digkeitsprinzip absolut wichtig Auch muss die Aktualit t und die Integrit t des Backups sichergestellt werden Um dies zu gew hrleisten ist eine Datensicherungs strategie erforderlich In dieser muss auch geregelt sein wie die Datentr ger zu ve
139. ionssicher e so klein wie m glich sein so dass er durch Tests oder Analyse auf korrektes Verhalten getestet werden kann und e durch jede sicherheitsrelevante Stelle des Programmablaufs aufgerufen wer den k nnen Aus diesen Forderungen an die Software entwickelten sich verschiedene Ans tze Sicherheit zu gewahrleisten Der erste Ansatz bestand in der Erweiterung bestehender Betriebssysteme wie es in Abbildung 13 dargestellt wird In diesem Modell stehen nur eine begrenzte Anzahl von Programmereignissen zur Verfiigung die durch das Betriebssystem kontrolliert werden k nnen Insbesondere 50 e die Ausfiihrung spezieller Opcodes welche einen Kontextwechsel zum Be triebssystem zur Folge haben oder e die Uberwachung der Speicherzugriffe durch eine spezielle Erweiterung der Hardware Target Program Instruction Instruction Reference Monitor Operating System i i i i i i i i i i i i Hardware Abbildung 13 Referenzmonitor als OS Bestandtteil Eine andere M glichkeit ist die Verwendung eines Interpreters in dem der Re ferenzmonitor integriert ist Hier gibt es im Gegensatz zur erstgenannten M glich keit keine direkten Zugriffe auf die Hardware Abbildung 14 skizziert das Konzept das aber bisher keine so starke Verbreitung fand da es eine starke Reduzierung der Ausf hrungsgeschwindigkeit zur Folge hat Aktuelle Entwicklungen im Rah men von Java und Net verwenden allerdings diesen Weg
140. ird das Modul an die zu schtitzende Applikation angepasst Dies wird durch den Einsatz von aspektorientier ter Programmierung in Form des AspectJ Frameworks erreicht Fiir die Authentifikation kommt das Liberty Alliance Protokoll ein zukiinftiger In dustriestandard zum Einsatz welches ein Single Sign On Protokoll unter Verwendung von Identity Federation implementiert Eine m gliche Verwen dung von Hardwaretoken in diesem Framework wird demonstriert und eine Weg vorgestellt ein proaktives Verhalten in das Systems zu integrieren Abstract Identity Management is becoming more and more important in busi ness systems as they are opened for third parties including trading part ners consumers and suppliers This thesis presents an approach securing a system without any knowledge of the system source code The security module adds to the existing system authentication and authorisation based on aspect oriented programming and the liberty alliance framework an up coming industrie standard providing single sign on In an initial training phase the module is adapted to the application which is to be secured Moreover the use of hardware tokens and proactive computing is demon strated The high modularisation is achived through use of AspectJ a programming language extension of Java Keywords Identity Mangement aspect oriented programming single sign on lib erty alliance pro active computing aspectj identity federation INHALTSVERZEICHN
141. ird das alte Applet von der alten Seite automatisch vom Browser beendet und das gleiche Applet mit der zweiten Seite erneut gestartet Ein Screenshot des Applet eingebettet in eine Beispielseite des JPetstores ist in Abbildung 54 oben links zu sehen Der Kreis nimmt dabei die Farbe griin an wenn der Wibu Key vorhanden ist und das Zeitlimit noch nicht berschritten ist Falls der Wibu Key nach Zeit berschreitung noch vorhanden ist wechselt die Farbe auf Rot Die periodische Kommunikation zwischen Applet und Identity Provider findet dabei auch nach der Zeitiiberschreitung weiterhin statt Man k nnte damit z B eine Statistik tiber die Lange der Abwesenheit eines Benutzers erstellen Trotz des st ndigen Neuladens des Applets existiert auferdem eine kontinu ierliche Kommunikation zwischen dem Applet und dem Identity Provider da die Kommunikation zwischen beiden zustandslos ist Auf Seiten des Identity Provi ders steht das Servlet ProAktivAction java mit dem Applet in bidirektionaler Kommunikation Sowohl das Laden des Applets als auch der Nachrichtenaus tausch zwischen Applet und Identity Provider werden dabei tiber SSL abgesichert Da das Applet zum gleichen Zeitpunkt gestartet wird wie die letzte Seite aufge baut wird hat das Applet den Zeitpunkt der letzten Interaktion des Benutzers zur Verfiigung Eingaben des Benutzers zwischen den Seitentibertragungen wer den bei unserem Demonstrator nicht ber cksichtigt k nnten aber in das Applet zur
142. it B Abbildungsverzeichnis C Listingverzeichnis 69 69 70 71 73 77 TT 80 83 116 116 122 122 122 126 131 132 134 INHALTSVERZEICHNIS 7 D Abk rzungsverzeichnis 135 E Literaturverzeichnis 137 1 Einleitung Outsourcing auf der Ebene der IT Infrastrukturen ist inzwischen g ngige Praxis bei Unternehmen und auch Beh rden Allgegenw rtiger Rationalisierungsdruck l sst inzwischen aber auch immer mehr den Wunsch aufkommen wesentliche Teile von Gesch ftsprozessen und gesch ftlicher Kommunikation auf externe Service Anbieter zu verlagern Unter Sicherheitsaspekten ist dies jedoch stets kritisch insbesondere wenn in komplexen Arbeitsabl ufen Mitarbeitern von Partnerfir men oder Au endienstlern begrenzter aber direkter Zugriff auf firmeneigene Da tenbest nde gew hrt werden soll Meh04 Verteilte Business IT Systeme sicher zu machen ist etwa im Rahmen der von der Distributed Management Task Force entwickelten Familie von Standards und mit Hilfe von Suns Toolkit f r webbasiertes Unternehmensmanagement Prob m glich Der Aufwand so ein auf einer ausformulierten Sicherheitsrichtlinie be ruhendes Gesamtsystem zu konzipieren und umzusetzen ist allerdings erheblich besonders wenn dabei bestehende Altsysteme einzubinden sind HSO 04 Dies ist gerade f r kleine und mittlere Unternehmen nicht vertr glich mit dem Streben nach Effizienz beim IT Outsourcing F r viele Firmen ist es interessant geworden ihre S
143. it ist das Ziel die Einf hrung von unternehmensweiten Identity Man gement L sungen Diese k nnen als Basis f r die Einf hrung verteilter Adminis trationsstrukturen dienen wie sie durch business orientierte Modelle gefordert werden Ein solches Modell wird durch das Beispiel am Anfang des Kapitels vorgestellt Das anfangs erw hnte Beispiel erfordert dass der Dienstleister ein Identity Management besitzt und dort seine Mitarbeiter verwaltet Der Herstel ler vertraut nun auf die Korrektheit der Benutzeridentifikation des Dienstleisters und gew hrt den Mitarbeitern Zugang zu seiner Software 1 EINLEITUNG 11 Dezentrale Verwaltung und Workflows Ein Workflow ist eine Sequenz von Aufgaben die zum Erreichen eines Ziels notwendig sind Zwischen den Aufga ben bestehen Abh ngigkeiten die erf llt sein m ssen bevor die n chste Aufgabe ausgef hrt werden kann Aufgrund der weiter oben bereits beschriebenen W nsche der Industrie nach einer st rkeren Verzahnung der Arbeitsabl ufe auch zwischen verschiedenen Fir men erlangen Workflowsysteme eine immer st rkere Bedeutung in der Automa tisierung von unternehmens bergreifenden Interaktionen Der Begriff der Work flowsysteme beschreibt Software in Unternehmen die den Ablauf von Vorg ngen steuern vgl Mel05 In ACMOI stellen V Atluri et al ber solche Systeme fest Systems are inherently distributed heterogeneous and autono mous in nature and therefore do not lend themselves t
144. kflows vgl 8 1 Implementierung des Web Tools In der Implementierung des Web Tools wer den intern Speicherstrukturen verwendet die besser in Form von XML Strukturen formulierbar w ren Auch hat sich gezeigt dass der Entwurf der graphischen Oberfl che sich als wesentlich schwerer dargestellt hat als erwartet Verwendung von Standards In einer Weiterentwicklung des Konzepts gilt es st rker bestehende Standards zur Modellierung und Beschreibung der Si cherheitsarchitektur heranzuziehen Insbesondere sind hier zu SAML vel HMOA und SUNs WBEM Services vgl Prob zu nennen HTML Verifizierung Durch das im HTMLRewriter vorgestellte Konzept k n nen die erstellten Webseiten auf Korrektheit untersucht werden Es w re denkbar verschiedene Angriffe wie sie im Kapitel 6 3 vorgestellt werden auf diesem Weg erkennen zu k nnen und dynamisch auf diese zu reagieren Es k nnten beispielsweise alle Javascriptanweisungen aus einer Seite heraus gefiltert werden oder Modelle f r Cross Site Script Angriffe zur Anwendung kommen Hierf r wird ein spezieller HTML Parser ben tigt Der Demonstrator verl sst sich auf eine Wohlgeformtheit der erzeugten Sei te und beschr nkt sich auf eine simple Ersetzungsstrategie Eine allgemeine re Anwendbarkeit des bestehenden Aspects ben tigt ebenfalls einen speziel len HTML Parser Am Beispiel des JPetStore ist zu sehen das ein Browser den schliessenden Body Tag nicht unbedingt ben tigt Die Ersetzu
145. kompromittiert werden kann Bei der Erzeugung sollte daher ein Mehraugenprinzip zur Anwendung kommen Auch ist es w nschenswert das die erzeugte Beschreibung durch eine formale Definiti on der Anforderungen verifiziert werden kann Nach der Betrachtung der Module des Konzepts m ssen die Verbindungen zwi schen den Modulen betrachtet werden IDP security Aspect DB Bei der Kommunikation mit den Datenbanken wird TCP IP verwendet Eine Authentifikation gegen ber der Datenbank erfolg mit Hilfe von Benutzernamen und Passwort Diese werden in Konfigurati onsdateien gespeichert oder sind fest einkodiert in der Applikation Somit sind sie offengelegt falls ein Angriff auf den Server erfolgreich durchgef hrt wurde 7 KONZEPT UND SICHERHEITSBETRACHTUNG 87 Da die Datenbanken ber TCP IP zu erreichen sind m ssen hier spezielle Schutzmassnahmen durchgef hrt werden die verhindern dass die Informa tionen in ihr Dritten zug ngig werden M gliche Ma nahmen werden durch das GSHB siehe Kapitel 6 4 vorgeschlagen Die Wirksamkeit ist anhand der Kriterienkataloge wie sie in Kapitel 6 4 vorgestellt werden zu berpr fen Client Server Bei der Kommunikation zwischen dem Browser des Clients und den jeweiligen Servern k nnen verschiedene Angriffspunkte bestehen Kapi tel 6 3 versucht hierbei die h ufigsten aufzuzeigen Neben diesen Angriffen muss noch das Problem eines Denial Of Service Angriffs betrachtet werden Hierbei wird versucht die
146. l Ist Vergleich Damit wird versucht durch Schablonen ein System zu erfassen und konkrete Handlungsanweisungen aus einem Katalog herauszusuchen Nach dem Ausf hren der Ma nahmen kann davon ausgegangen werden dass das System 6 SERVERABSICHERUNG 75 genau so sicher ist wie das Referenzsystem welches dem Grundschutzhandbuch zugrunde liegt Falls festgestellt wurde dass ein h herer Schutzbedarf vorhanden ist als ihn das Grundschutzhandbuch bieten kann so sind erg nzende Sicherheitsanalysen vorgesehen Diese werden auf Grund der hohen Kosten auf die sicherheitskriti schen Bereiche beschr nkt Folgende Methoden sind vorgesehen Risikoanalyse Eine Risikoanalyse wie sie schon weiter oben vorgestellt wurde erfasst fiir jedes betrachtete Objekt die Bedrohungen und Gef hrdungen Die durch das GSHB beschriebene Risikoanalyse beschrankt sich auf die Bereiche des Systems fiir die das GSHB nicht ausreichend ist Somit ist der Aufwand bedeutend geringer Penetrationstest Es wird ein Angriff auf das System simuliert Hierbei wird zwischen einem Blackbox und einem Whiteboxangriff unterschieden Bei einem Blackboxangriff besitzt der Angreifer keinerlei Wissen tiber das vor handene System Der Whiteboxangriff hingegen setzt bei dem Angreifer ein detailliertes Wissen tiber interne Bedingungen voraus Hierdurch kann er mittelt werden welche Schwachstellen vorhanden sind und welche Sch den ein Angriff erzeugen kann Differenz Sicherheitsanalyse
147. lche SSL bzw TSL bieten Au erdem muss bei Verwendung von SSL zum Zwecke der Authentifikation mindestens der Identity Provider ein serverseitiges Zertifikat vorweisen dass ber die PKI Infrastruktur berpr ft werden kann Der IDP kann dar ber hinaus auch ein client seitiges Zertifikat verlangen e Message Security Die Message Security behandelt die Absicherung der Liberty Protokoll Nachrichten zwischen Identity Provider Service Provider und dem Brow ser des Benutzers die ber den gerade genannten Kommunikationskanal bertragen werden Teile der Liberty Protokoll Nachrichten m ssen signiert werden und vom Empf nger validierbar sein Liberty spezifiert nicht mit welcher Methode das zu geschehen hat nur dass es geschehen muss Nach TC03 gew hrleistet das Signieren und Validieren der Signatur die Daten integrit t die Herkunft der Daten und bietet eine Basis f r die Nichtab streitbarkeit einer Nachricht Jeder Teilnehmer in einem Circle of Trust muss bei den Partnern fest vorab eingetragen worden sein damit ber das Liberty Protokoll kommuniziert wer den kann Hierbei wird wie z B bei SourcelD s u nicht nur der Name und die Adresse des Partners eingetragen sondern auch der ffentliche Schl ssel des X509 Zertifikats des Partners Dieses Zertifikat wird von jedem Teilnehmer nur f r den Zweck der Liberty Nachrichten erstellt und kann selbst signiert sein Der ffentliche Schl ssel des Zertifikats wird an die Partner i
148. likation alles darf Dies bedeutet dass die Software speziell so entwickelt sein muss dass es keine Funktionen geben darf die eventuell durch einen Benutzer nicht verwendet werden diirfen Bei sp teren Anderungen am Sicherheitsmodell fiihrt dieser Ansatz dazu dass Meniis durch extra Passw rter oder hnliches gesperrt werden Ein wesentlich eleganterer Ansatz besteht darin den Benutzer in seinem Ver halten in der Software zu kontrollieren und zu lenken Die Software wird als Universalsystem fiir alle anfallenden Aufgaben innerhalb der Organisation entwi ckelt und ein Benutzer bekommt nur bestimmte Bereiche innerhalb der Software zur Verwendung freigegeben Im Vorfeld muss hierbei gekl rt werden welche Auf gaben welcher Mitarbeiter auszuf hren hat In diesem Zusammenhang wird von Arbeitsabl ufen bzw Workflows gesprochen Wir verstehen unter einem Work flow die Reihenfolge der Bildschirmmasken die zur Bearbeitung einer Aufgabe n tig sind sowie die Benutzerinteraktion die n tig ist um von Maske zu Mas ke zu gelangen Eine Repr sentation dieses Zusammenhangs kann als endlicher Zustandsautomat formuliert werden Jede Maske ist hier ein Zustand und die be n tigten Benutzereingaben stellen die Kanten dar Um dies zu verdeutlichen kann als Beispiel ein Logindialog genommen werden Die Applikation soll einen Dialog besitzen dessen Funktion es ist einen Benutzer zuzulassen wenn er sich BERT nennt und sonst einen Fehler anzuzeigen Dies wi
149. lit t in eine Applikation w nschenswert die vor allem in verteilten Applikationen wich tig ist Ein Sicherheitssystem bezogen auf die Authentifikation f r eine verteilte Applikation sollte somit unter anderem folgende Eigenschaften aufweisen e Unterst tzung vieler Authentifikationsverfahren e Integration eines Single Sign On Server e Reauthentifikation e Einfache Integration in eine Applikation Im Folgenden wird kurz auf m gliche Authentifikationsverfahren im Webum feld eingegangen und Reauthentifikation beschrieben Zur Integration eines Single Sign On Servers sei auf das Kapitel 2 verwiesen 5 2 1 Authentifikationsverfahren Passwort Das Passwort Verfahren ist das in der Praxis am h ufigsten einge setzte Verfahren Eck03 und beruht auf der Basis von spezifischem Wissen Die weite Verbreitung des Passwortverfahren ist dabei auch das gr te Sicherheits problem dieses Verfahrens Da ein Mensch sich nicht beliebig viele Passw rter merken kann wird h ufig dazu bergegangen das gleiche Geheimnis f r ver schiedene Portale zu w hlen oder auf einen Zettel zu schreiben der sich in der N he des Computers befindet Diese Tatsache birgt nat rlich gro e Sicherheits probleme da man durch das Knacken eines Passwortes auf mehrere Portale Zu griff bekommt bzw das Geheimnis auf dem Zettel kein richtiges Geheimnis mehr ist Zus tzlich gibt es mit Passw rtern noch das Problem dass sie abgeh rt und geraten werden k nnen Durch di
150. m Anfang ein Federation Request zusammengestellt Dieser beinhaltet den Namen des beteilig ten Identity Providers die R cksprungadressen sowie die Kennung des lokalen Benutzers Dieser Request wird dann an SourcelD Java bergeben 2 Darauf hin generiert SourcelD Java ein Pseudonym f r den Benutzer und nimmt die Kommunikation mit dem Identity Provider auf Die Applikation bekommt zum Schluss wieder ber die Success und Failure Page mitgeteilt ob die F deration zustande kam Der Aufruf zur Beendigung eben dieser der Terminate Federation Request verl uft dabei analog zum Federation Request Der Aufruf zum Logout beim Identity Provider wird ber ein Logout Request an SourcelD Java bergeben Hierbei wird der Name des Identity Providers die lokale Benutzerkennung sowie die R cksprungadressen an SourcelD Java ber mittelt Die Applikation bekommt daraufhin ber die Success oder Failure Page mitgeteilt ob der Global Logout funktioniert hat Auch f r die IDP Seite des Liberty Protokolls gibt es von SourcelD Java eine API Diese ist geringf gig anders als die API der SP Seite Die Konfiguration wird genauso durch die oben genannten drei Dateien spezifiziert Die weiteren Mitglieder des Circle of Trust werden in der Datei sourceid sso providers xml 2 SINGLE SIGN ON 35 SourceID API Application 1 i Request Authenticat Federation Logout 2 from IDP Process Login Page
151. m Circle of Trust weiter gegeben sodass diese von anderen Teilnehmern signierte Nachrichten validieren k nnen Um einen h heren Sch tz gew hrleisten zu k nnen m ssen die IDPs und SPs Schl sselpaare f r die Message Security verwenden die sich von denen zur Kom 30 munikationskanalabsicherung Channel Security unterscheiden Au erdem wird erwartet dass Nachrichten gegen Replay Attacken gesch tzt werden und empfan gene Antworten daraufhin berpr ft werden dass sie passend zu den gestellten Fragen sind Hierzu sollten zeitbasierte Nachrichten verwendet werden um die Frische nachweisen zu k nnen Zusammengefasst muss f r Nachrichten des Liberty Protokoll nach der Mes sage Security Richtlinie folgendes gelten e Per message data integrity e Transaction integrity e Data origin authentication Quellursprung e Non repudiation Nicht Abstreitbarkeit e Confidentiality optional Da die verwendeten Teilprotokolle wiederum weitere Angriffspunkte haben ist eine abschlie ende Sicherheitsanalyse des Liberty Protokolles schwer m glich Auf das SSL Protokoll beispielsweise gibt es Angriffe die auf der DNS Struktur oder der Ver nderung der Systemuhrzeit aufbauen k nnen 2 6 SourcelD SourcelD wurde im Jahre 2001 gegr ndet und wird von Ping Identity HP Nokia und General Catalyst gesponsort und betrieben Das Ziel von SourcelD ist es Open Source Tools Applikationen und Infrastruktur aufzubauen um Federated Identity Man
152. m des security Aspect securityAspe ct Ausstieg 101 102 Dies muss so fr h wie m glich getestet werden um eventuelle Endlosschleifen zu verhindern Auch dies fiihrt zu einer Fehlerseite die dem Benutzer tibermittelt wird Der hier vorliegende SecurityAspect ist fiir eine Verwendung in Verbindung mit dem struts Framework gedacht Als Weiterentwicklung ist es aber m glich ohne Struts auszukommen Hierzu muss lediglich auf die Eigenschaften der Serv letprogrammierung geachtet werden die zu grofsen Teilen im Struts Framework versteckt sind Besonders wichtig ist hier das die ankommenden Eingaben des Benutzers ber verschiedene Methoden an die Applikation bergeben werden e doGet behandelt HTTP GET Anfragen Die Daten die dem Server ber mittelt werden werden durch ein getrennt an die URL angeh ngt e doPost empf ngt HTTP POST Anfragen Diese sind in ihrer L nge nicht begrenzt und finden ihre Anwendung zum Beispiel in der bertragung von Kreditkarteninformationen Die Daten werden im Gegensatz zu GET f r den Benutzer unsichtbar an den Server bermittelt e doPut ist hnlich einer FTP bertragung und erlaubt das Transferieren von Dateien auf den Server Da Struts eine sehr hohe Verbreitung hat siehe z B Hai03 und durch die Verwendung des Frameworks diese Details der Programmierung von Webservices unsichtbar werden haben wir uns entschieden im Demonstrator Struts einzuset zen Ein weiterer Vorteil ergibt s
153. mapping gt Listing 1 Auszug aus der web xml Wenn eine Service Provider Applikation eine Authentifikation mit SourceID initiieren will verweist sie den Browser des Benutzer weiter auf die Adres se des SourceID SSO AuthnRequestor Ein Beispiel hierzu befindet sich in Listing 22 auf Seite 99 e In der Datei sourceid sso xml wird spezifiziert ob sich die Applikation in der Rolle eines SP oder IDP befindet und das eigene Zertifikat das f r das Signieren der Liberty Nachrichten n tig ist sowie der UserID Variablenname gespeichert Es wird davon ausgegangen dass die Appli kation die berpr fung ob ein Subjekt sich authentifiziert hat ber das Vorhandensein einer UserID Variable in dem Session Context der Applika tion vornimmt Somit hat SourceID Java die M glichkeit bei einem ber schreiten des Zeitlimits oder bei einem Ausloggen das von au en getriggert ist diese UserID Variable zu l schen und der Applikation mitzuteilen dass das Subjekt nicht mehr eingeloggt ist e In der sourceid sso providers xml werden alle beteiligten Partner inner halb des Circle of Trust eingetragen lt lib SPDescriptor xmlns lib http projectliberty org schemas core 2002 12 xmlns ds http www w3 org 2000 09 xmldsig gt lt lib ProviderID gt jpetstore lt lib ProviderID gt lt ds KeyInfo xmlns ds http www w3 org 2000 09 xmldsig gt lt ds X509Data xmlIns ds http www w3 org 2000 09 xmldsig gt lt ds X5
154. men erreichte Sicherheit beurteilt und verglichen werden kann Das Kapitel 7 beinhaltet die Beschreibung des erarbeiteten Konzepts Dort erfolgt auch eine Sicherheitsbetrachtung des vorgestellten Konzepts Kapitel 8 stellt ein generisches Sicherheitsmodul vor welches das in Kapitel 7 vorgestellte Konzept realisiert Es ist in der Lage einem ungesch tzten Programm Authentifikation und Autorisation hinzuzuf gen ohne das Programm an sich zu ver ndern und ohne dass der Sourcecode des Programms zur Verf gung steht Die Verwendung des Sicherheitsmoduls wird in Kapitel 9 demonstriert Es wird ein vollst ndiger Lebenszyklus der Training und Einsatz beinhaltet beschrie ben In Kapitel 10 werden weitere M glichkeiten aufgezeigt die keinen Eingang in die Implementierung gefunden haben und ein Fazit gezogen 2 SINGLE SIGN ON 13 2 Single Sign On Die heutige Gesch ftswelt im Internet ist gepr gt von webbasierten Diensten Es werden ber Internetseiten Dienste bzw Informationen angeboten die der Be nutzer per Webbrowser nutzen kann Eine Authentifikation wird in den meisten Fallen tiber den Vorweis von spezifischem Wissen durchgefiihrt Der Benutzer gibt seine Benutzerkennung an und authentifiziert sich ber die Vorlage eines vorher vereinbarten Geheimnisses dem Passwort Da es im Internet keinen gro en Zu sammenschluss von Gesch ften gibt muss ein Benutzer f r verschiedene Dienste unterschiedliche Passw rter vorweisen Dies kann zu eine
155. mit diesen Zust nden arbeiten zu k nnen werden zwei Funktionen ben tigt 4 REFERENZMONITOR 57 e CurrentState CurrentState liefert den aktuellen Zustand eines Tasks und wird wie folgt definiert CurrentState TI S Ordnet jeder Taskinstanz Zust nde zu CurrentState t s s S and s is in the current state of ti e PossibleOperations PossibleOperations bestimmt die m glichen Operationen in einem gegebe nen Zustand PossibleOperations E S x OP in unserem Fall kann also geschrieben wer den PossibleOperations Initial Execute Executing commit Executing abort Diese Uberlegungen fiihren zu der zweiten Erweiterung des RBAC96 Modells in dem RBAC96 um Workflows erweitert ist Die Workflows besitzen Zust nde auf denen nur wenige Operationen execute commit abort erlaubt sind U R RH UA TT TI EP IP werden aus der ersten Erweiterung unver ndert bernommen OP execute commit abort Menge der Operationen S Initial Executing Commited Aborted Menge der Zust nde T Initial execute Executing Executing commit Commited Execu ting abort Aborted Menge der Uberg nge CurrentState t s s S and s is in the current state of ti PossibleOperations Initial Execute Executing commit Executing abort P EPUIP EPA C Rx EP Menge der Explizit zugewiesenen Rechte IPA r 0p t S ri op t EPA A ft S t A CurrentState t op PossibleOperations
156. n direkt zu dem Computer bertragen oder bleibt wie bei der Smartcard auf der Chipkarte und die Chipkarte besitzt ein eigenes Kryptosystem Eine Authenti fikation mit Chipkarten kann dabei sowohl mit einem asymmetrischen als auch mit einem symmetrischen Kryptoverfahren stattfinden Biometrie Eine Authentifikation auf Basis von biometrischen Merkmalen ba siert auf charakteristischen physischen Eigenschaften oder besonderem Verhalten einer Person Hierzu m ssen erst in einer Lernphase Referenzwerte von der Per son aufgenommen werden und personenspezifische Eigenschaften isoliert werden 5 AUTHENTIFIKATION IM WEBUMFELD 65 Der Vorteil einer biometrischen Authentifikation liegt darin dass eine Person zur Authentifikation nichts aufer sich selbst braucht Daraus ergibt sich dass man keine wichtigen Daten zur Authentifikation vergessen oder verlieren kann Das Problem an der biometrischen Authentifikation ist der zuverl ssige Vergleich der aktuell aufgenommenen Daten mit den gespeicherten Referenzdaten Studien der Wirksamkeit von biometrischen Erkennungssystemen gibt es vom BSI unter Sid103a 5 2 2 Reauthentifikation Eine Authentifikation wird typischerweise einmal am Anfang einer Sitzung in itiiert Mit Reauthentifikationen also einer wiederholten Authentifikation nach der initialen versucht man nachzuweisen dass der aktuelle Benutzer mit dem initial authentifizierten User identisch ist PB04 Zus tzlich kann man hiermit fortla
157. n Durch Security werden Zugriffskontrollmechanismen und Resourcenkontrolle beschrieben Java ist eine auf Sicherheit hin entwickelte Sprache da sie im Internetumfeld ihre Anwendung findet Java Programme k nnen reisen und auf verschiedenen Plattformen bei den Benutzern ausgef hrt werden Somit ist von Java eine h here Sicherheit zu erwarten als von anderen Sprachen die es auf dem Markt gibt Im Sprachdesign sind die Konzepte der Memory Safety und Type Safety ber cksichtig worden Memory Safety besagt dass Java keine Speicherstruktu ren unkontrolliert dem Benutzer gibt Somit gibt es keine Pointerarithmetik oder Arrays die zu lang sind Durch Type Safety wird beschrieben dass durch den Javacompiler sicher gestellt wird dass auf Methoden und Operatoren nur erlaub te Operationen ausgef hrt werden Eine weitere Besonderheit ist die Existenz eines Runtime Environment das ebenfalls die oben beschriebenen Kriterien berwacht Ein Programm wird in einer sogenannten Sandbox betrieben In HMOL wird von Hartel und Moreau die Frage gestellt wie weit man der Sicherheit von Java vertrauen kann Sie stellen fest dass neben der Type und Memory Safety zwei weitere Eigenschaften wichtig sind Die Erste ist die M g lichkeit zur Beschr nkung von Ressourcen die einem Programm zur Verf gung stehen Hier gibt es Ressourcen die einfach zu beschr nken sind wie z B der Zu griff auf Dateien und Ressourcen die sich nur schwer begrenzen lassen so wi
158. n Applikation zum Erlernen der Work flows begr ndet ist da sich der Zustand der Datenbank und Applikation ndert Wenn einen Verzweigung im Ablauf des Workflows integriert werden soll so w r de dies bei einer Erzeugung durch das Webtool bedeuten das die Applikation 8 SPEZIFIKATION UND IMPLEMENTIERUNG 93 in den Zustand dieses Punktes zur ckversetzt werden muss Dies kann durch ein nochmaliges Ausf hren aller Interaktionschritte des Benutzers erfolgen und kann durch einen Aspect automatisiert werden Allerdings befindet sich die Applika tion danach nicht mit Sicherheit in dem gleichen gew nschten Punkt Beispiels weise k nnte ein Artikel nicht mehr ausreichend in der Datenbank vorhanden sein so dass das Bestellmen nicht erreicht werden kann was aber vom Trai ner gewollt war Daher wurde das Problem der automatisierten Erzeugung von komplexen Workflows hier nicht weiter beleuchtet eine Grundlage f r die Erzeu gung von komplexen Workflows ist aber gelegt Eine m gliche L sung kann in der Verwendung von gespeicherten Datenbankenzust nden zu jedem Zustand liegen Allerdings erfordert diese L sung eine weitaus komplexere Trainingssuite 8 2 XML Beschreibung Die durch die Trainingssuite erzeugte XML Datei wird durch die Datei secu rityDescription xsd definiert welche der XML Schemakonvention vgl w3c04 entspricht Es wurde ein eigenes Datenformat entwickelt welches eine effiziente Repr sentation der Workflows und den zugeh
159. n Authentifikationsaufforderung noch weitere Ein 8 SPEZIFIKATION UND IMPLEMENTIERUNG 107 entered from an SP org diplom idp logonAction java S org diplom idp wibukey loginAction java lisplogonSp sp org diplom idp logonPostAction java isp logonWibukey jsp org diplom idp wibukey LogonPostAction java lisp logonWibukeyApplet sp Browser querys Wibukey org diplom idp wibukey responseAction java Going back to the SP Abbildung 35 vom SP initiierter IDP Ablauf stellugen get tigt werden Da SourcelD nur f r die Kommunikation des Liberty Protokolls zust ndig ist aber bei einer Authentifikationsaufforderung die Kon trolle besitzt muss SourcelD ber seine Konfigurationsdateien mitgeteilt werden wo sich die Webseiten zur Abwicklung der Authentifikation befinden Zu diesen Seiten wird der Browser des Benutzers von SourcelD weitergeleitet Eine der wichtigsten Einstellungen ist die Angabe der lt idp authentication uri gt siehe Listing 27 Dies ist der Einspringpunkt zur Applikation wenn eine Authentifikation von einem Service Provider gew nscht wird lt idp authentication uri gt logon_from_sp do lt idp authentication uri gt Listing 27 Auszug aus der sourceid sso xml Weitere Einspringpunkte zur Abwicklung des Single Logout Verfahren sowie Aufbau und Beendigung einer F deration siehe Kapitel 2 3 werden ebenfalls in dieser xml Datei spezifiziert 8 8 1 Kan
160. n der Firm Code User Code sowie der Selection Code als Schl ssel verwendet wurden vgl Abbildung 20 Zum Schlie en einer Verbindung mit dem Wibu Key wird die Funktion WkbClose2 aufgerufen 6 SERVERABSICHERUNG 69 6 Serverabsicherung Um die Sicherheit eines gesamten Systems beurteilen zu k nnen m ssen die ver schiedenen Teile betrachtet werden die zusammenarbeiten um die Funktionalit t zu erzeugen Da hier ein webbasiertes System entwickelt wird ist insbesondere die M glichkeit von Angriffen zu untersuchen die nicht nur auf die Applika tion abzielen Somit m ssen neben dem Standort und der Hardware auch das Betriebssystem und die darauf aufsetzenden Dienste einer genauen Betrachtung unterzogen werden Wir beschr nken uns hier auf eine kleine und in keiner Weise repr sentative Auswahl von Komponenten und Diensten mit dem Ziel die Verwendung eines Applikationsservers sicher zu gestalten Sicherheit ist stets die Abw gung zwischen den Kosten und dem Nutzen der Sicherheitsma nahmen Die perfekte Sicherheit ist nie zu erreichen sondern im mer nur eine angemessene Um beurteilen zu k nnen ob ein System sicher genug ist werden Metriken ben tigt anhand derer die Sicherheit quantifizierbar ist Eine Auswahl wird im Kapitel 6 4 vorgestellt 6 1 Hardware Ein Glied der Sicherheitskette ist die Hardware und der Ort an dem diese steht Bei Servern muss eine hohe Ausfallsicherheit erreicht werden die durch Redun danzma nahmen
161. n hinterlegt sind Eine solche Datenbasis muss speziell gegen Ver nderungen und unerw nschte Zugriffe gesch tzt werden Daneben muss auch das Entstehen der Datenbasis kritisch betrachtet werden Da die Entscheidun gen nicht berechenbar sind m ssen sie durch einen Entwickler Administrator oder hnliche Person getroffen und in der Datenbasis hinterlegt werden F r den Betreiber der Software der im Allgemeinen keinen Einblick in die Funktion der Software hat bedeutet dies dass er einem externen Sicherheitsanbieter vertrauen muss Eine weitere wichtige Frage ist wie das System auf nderungen der Zugriffs rechte reagiert Der Rechteentzug kann sofort propagiert werden so dass der Benutzer ab dem Zeitpunkt des R cknahme der Rechte diese nicht mehr ver wenden kann Es kann aber auch eine gewisse Zeit vergehen Bei einem rein ticketbasierten System wie z B Kerberos wird eine nderung der Zugriffsrechte erst nach einigen Stunden aktiv wenn der Benutzer versucht ein neues Ticket zu bekommen Durch diese Verz gerung wird es dem Benutzer m glich Operationen durchzuf hren obwohl ihm bereits die Rechte f r diese genommen wurden 4 REFERENZMONITOR 93 4 3 Workflows Die im vorherigen Abschnitt vorgestellten Sicherheitsstrategien ben tigen eine Entscheidungsbasis anhand derer sie beurteilen was ein Benutzer darf bzw nicht darf Der rudiment rste Ansatz besteht darin dass der Benutzer nach erfolg reicher Authentifikation in der App
162. n zur Signierung verwendet werden Der Anwender bekommt auf diesem Weg die Sicherheit dass das Programm seit der Signatur durch den Her steller nicht ver ndert wurde Als zweites Sicherheitskonzept ist die Javasandbox zu nennen die im n chsten Kapitel behandelt wird Der Einsatz von AOP in J2EE Umgebungen haben P Slowikowski und K Zielinski in 5203 untersucht Sie sind hierbei zu dem Schluss gekommen dass es oft nicht m glich ist mit den in J2EE vorgesehenen Methoden komplizierte oder dynamische Sicherheitsdefinitionen zu formulieren Somit wird oft auf Program matic Security zur ckgegriffen also Sicherheit die durch den Programmierer im Sourcecode verankert wird Hier bietet sich nach Ansicht der Autoren von 5203 ein wichtiger Einsatzzweck von AOP In BGP04 stellen T B hren V Gruhn und D Peters ein dem AOP Ansatz verwandtes Konzept vor Hier werden Wrapper eingesetzt die die vorhandenen Klassenbibliotheken kapseln Dadurch sollen beliebige Klassen zur Laufzeit aus getauscht werden Aufgrund der besseren Normung von AOP z B in Form von AspectJ und der m chtigeren Sprachelemente ist ein Wrappen durch aspektori entierte Programmierung einfacher formulierbar und durchf hrbar 3 6 Javasicherheit Bei der Betrachtung von Sicherheit gilt es zwei Begriffe zu unterscheiden Safety besagt dass auch in Fehlerzust nden das Programm noch das Richtige macht und es die M glichkeit besitzt auf Fehler zu reagiere
163. namen und Passwort vom Browser automatisch bei jeder folgenden Anfrage erneut gesen det sodass bei einem Wechsel zur ck auf das normale HTTP Protokoll nach der Authentifikation das Passwort wieder im Klartext bertragen wird HTTP Digest authentifiziert den Benutzer auf die gleiche Weise wie das HTTP Basic Verfahren nur dass im Unterschied das Ergebnis nicht im Klartext sondern verschl sselt bertragen wird Allerdings ist es nicht sehr weit verbreitet Die Tatsache dass Benutzernamen und Passwort genauso wie beim HTTP Basic Verfahren bis zu einem expliziten Beenden des Browsers durch den Benutzer im Speicher bleiben er ffnet M glichkeiten den Browser des Benutzers direkt anzugreifen Da man bei den beiden HTTP Authentifikationsverfahren das Aussehen der Passworteingabe der Browsers nicht ver ndern kann wurde das Form Based Authentifikationsverfahren spezifiziert bei dem der Entwickler die M glichkeit hat die Login Seite nach seinen Vorstellungen zu gestalten Die Angabe der Login Seite wird dabei im deployment descriptor angegeben und die Namen der Formular Loginfelder sind vorgegeben Bei einem Zugriff auf eine Webseite durch einen Benutzer berpr ft Tomcat ob sich der Benutzer schon authentifiziert hat und leitet ihn im negativen Fall auf die im deployment descriptor angegebene Login Seite Das Ergebnis der Login Seite wird daraufhin vom Tomcat berpr ft und dem Benutzer wird Zugriff auf die Applikation gew hrt oder er wird auf
164. nem Administrator tool gest tzt erzeugt In der momentanen Version hat der Administrator keine M glichkeit die Korrektheit des von ihm erzeugten Workflows zu kontrollie ren da es kein formales Modell gibt Ein einfacher Ansatz dem Administra tor eine M glichkeit zu geben die Auswirkungen von nderungen an den Workflows zu testen ist eine Sammlung von positiven und negativen Bei spielen Einem Workflow k nnte eine Testsuite zugeordnet werden die nach einer nderung getestet wird Dar ber hinaus kann durch das Tool verlangt werden dass bevor eine nderung zugelassen wird erst ein Testfall ange geben werden muss f r den die nderung erforderlich ist Dies w rde dem Testfirst Paradigma des Extreme Programming siehe NMMB04 5501 entsprechen Auf der Basis der durch die Suite erzeugten Workflows ist es denkbar mit formalen Methoden die Einhaltung von Bedingungen zu kontrollieren Hier ist es denkbar Exklusivit tsbedingungen zu berpr fen Workflowerzeugung Das Web Tool aus der Trainingssuite kann lediglich seri elle Workflows erzeugen Die verwendete Definition erlaubt allerdings auch Verzweigungen und Schleifen als Sprachelemente Die Limitierung in der 130 Erzeugung der Workflows hat wie in 8 1 beschrieben seine Ursache im Zu stand der Applikation nach einem Durchlauf Eine m gliche L sung diesem Problem zu begegnen besteht in der Erzeugung und Speicherung des Zu stand der Applikation zu jedem Zustand des Wor
165. nerieren 1 14 HTTP Antwort Abbildung 36 Ablauf Wibukey kurz erlautert Der Benutzer will mit seinem Browser auf eine Webseite eines Service Pro viders zugreifen 1 Der Service Provider initiiert eine Authentifikationauffor derung mit dem Wibu Key und leitet den Browser 2 3 des Benutzers weiter auf die Webseiten des Identity Providers Dieser erzeugt die RAND und den Salt Wert 4 Daraufhin bekommt der Client Rechner das Applet mit den Parametern User Code und Firm Code passend zu dem aktuellen Benutzer sowie Salt und RAND Wert geschickt 5 Das Applet nimmt Kommunikation mit dem Wibu Key auf und verschliisselt den RAND Wert mit den Angaben Salt User Code und Firm Code als Schl ssel 6 siehe Kapitel 5 3 Das Ergebnis wird ber eine Weiterleitung des Browsers zu der responseAction Klasse des Identity Providers geschickt 7 Der Identity Provider berpr ft 8 das Ergebnis des Applets mit 112 dem am Server angeschlossenen Wibu Key und leitet den Browser des Benut zers mitsamt dem Ergebnis der Authentifikation ber letztere Weiterleitung an den Service Provider zur ck 9 10 Der Service Provider generiert nach posi tiv verlaufender Authentifikation die gew nschten Webseiten f r den Benutzer 13 14 Es ist darauf hinzuweisen dass das gerade beschriebene Verfahren von den Autoren entwickelt wurde und vor einem produktiven Einsatz au erhalb des Demonstrators einer genauen Sicherheitsanalyse zu unterziehen
166. ngsstra tegie aber ben tigt den HTML Tag Um den Aspect allgemein verwenden zu k nnen m ssen solche Probleme beachtet werden Weiterreichende proaktive Ma nahmen Die Proaktivit t wurde in dem De monstrator mit Hilfe eines Applets imtegriert das in Kapitel 7 1 beschrieben ist Das Applet registriert eine Aktivit t nur wenn der Benutzer zwischen Webseiten wechselt Eine weitreichendere berwachung des Benutzers z B die Registrierung von Tastatureingaben oder Mausbewegungen ist denk bar A ERKL RUNG ZUR DIPLOMARBEIT 131 A Erkl rung zur Diplomarbeit Erkl rung zur Diplomarbeit gem ss 19 Abs 6 DPO AT Hiermit versichern wir dass die vorliegende Diplomarbeit ohne Hilfe Dritter nur mit den angegebenen Quellen und Hilfsmitteln angefertigt wurde Alle Stel len die aus den Quellen entnommen wurden sind als solche kenntlich gemacht worden Diese Arbeit hat in gleicher oder hnlicher Form noch keiner Pr fungs beh rde vorgelegen Nicolai Kuntze Thomas Rauch Darmstadt den 17 Februar 2005 Darmstadt den 17 Februar 2005 132 B Abbildungsverzeichnis Abbildungsverzeichnis O OG JO OG WN A Roa Ro 0 E 8 Y Y 0 A NN DN IN NN DN DN k k a a a fa a 00 O Ot He Co BD ra O SCH 00 O Ot He ONE O O OATS CH e bi Circle of Trust LAPOGe 4 2 284 4 EEN EE aaa 20 Single Sign On and Federation o 23 Web Redreeis cos 122 a a A AA Se ee Yo 24 Authentication Assertion 34 l
167. nicht m glich ist eine endg ltige Aussage ber die Sicherheit eines mit der hier vorge stellten Methode abgesicherten Webservices treffen zu k nnen Bekannte Angriffe auf Webservices k nnen wie in 6 3 gezeigt abgewehrt werden Aber zum Beispiel Session Hijacking Angriffe stellen ein gro es Problem dar da es keine M glichkeit gibt diese zu unterbinden Es kann einem Angreifer lediglich sehr schwer gemacht werden an die Cookies heranzukommen Auch h ngt jede Aussage ber die Si cherheit des Konzepts von verschiedenen Voraussetzungen ab deren Korrektheit nur im Einzelfall oder gar nicht berpr ft werden kann Diese sind die Integrit t des Servers die Korrektheit der Javasprachdefinition die Korrektheit der Imple 7 KONZEPT UND SICHERHEITSBETRACHTUNG 89 mentierung der Sprachdefinition und der Korrektheit des Applikationsservers Eine Sicherheitsaussage kann somit nur ber pragmatische Vorgehensweisen getroffen werden wie sie z B im Rahmen des GSHB beschrieben werden 90 8 Spezifikation und Implementierung Um das in Kapitel 7 beschriebene Konzept in Form eines Demonstrators umzu setzen wurden f nf voneinander getrennte Module entwickelt die die einzelnen Aufgaben bernehmen Diese Module werden nun kurz vorgestellt und in den folgenden Abschnitten erkl rt SecurityAspect Der SecurityAspect ab Seite 98 umh llt die Ausf hrung der eigentlichen Actionklassen Eine Actionklasse stellt die Schnittstelle zwi schen dem
168. nssystem und hat ein paar gut dokumentierte Sicherheitsprobleme Die Nachrichten werden im Klartext bertragen und sind somit abh rbar Als Absicherung ist hier eine Ka nalabsicherung wie SSL n tig Diese Absicherung l st aber nicht das Problem dass die Informationen auf der Browser Seite entschl sselt werden und im Klar text vorliegen Diesem kann man nur entgegenwirken indem man die Informa tionen schon vor dem Senden verschl sselt Eine weitere Beschr nkung besteht durch die Gesamtl nge der URI Es k nnen nicht beliebig viele Informationen ber diesen Kanal ausgetauscht werden Gerade bei mobilen Ger ten ist die L n ge der URI recht klein Diese und weitere Einschr nkungen sind bei dem Design des Liberty Protokoll beachtet und in RW03a betrachtet 2 SINGLE SIGN ON 25 Cookies Da das HTTP Protokoll ein zustandloses Protokoll ist muss jede An frage an einen Server als Einzelanfrage bearbeitet werden obwohl vielleicht meh rere direkt hintereinander ausgef hrt worden sind Um eine M glichkeit einer Zustandspeicherung in das HTTP Protokoll integrieren zu k nnen sind die Coo kies eingef hrt worden Die Cookies werden vom Browser automatisch an den Server bei einem Verbindungsaufbau gesendet und k nnen vom Server gelesen und ge ndert werden sodass der Server in diesen Cookies Informationen ablegen kann Nach Eck03 sind Cookies zur Erleichterung des elektronischen Einkaufens entwickelt worden Ein Cookie soll als Warenkorb
169. ntType gt lt xsd complexType name SQLConstraintType gt lt xsd attribute name sqlUser type xsd string gt lt xsd attribute name sqlPassword type xsd string gt lt xsd attribute name connectURL type xsd string gt lt xsd attribute name sqlQuery type xsd string gt lt xsd complex Type gt Listing 19 Definition eines Ubergangs Ein Benutzer besteht aus einer Liste von Rollen denen der Benutzer ange hort und dem Benutzernamen siehe Listing 20 Dariiber hinaus werden noch die Authentifikationsparameter fiir den Benutzer eingetragen Im Fall dieser Di plomarbeit sind ein Passwort sowie WibuKey als spezifische Parameter siehe 5 3 aufgenommen worden Auch sind alle Parameter zur Erzeugung einer F deration siehe 2 3 Bestandteil der Definition 8 SPEZIFIKATION UND IMPLEMENTIERUNG 95 lt xsd complexType name lt xsd sequence gt lt xsd element name role type xsd string minOccurs 0 maxOccurs unbounded gt lt xsd element name idp type xsd string minOccurs 1 maxOccurs 1 gt lt xsd element name idpPassword type xsd string minOccurs 0 maxOccurs 1 gt lt xsd element name i irmCode e xsd strin minOccurs maxOccurs gt 1 t idpFirmCode type xsd string inO non O vin lt xsd element name idpUserCode type xsd string minOccurs 0 maxOccurs 1 gt lt xsd element name applicationUser type xsd string minOccurs 0 maxOccurs 1 gt
170. nterlegt sind die f r ihre Aufgabe ben tigt werden Der Identity Provider ben tigt hierbei die Benutzernamen und Authentifi kationsmerkmale der Benutzer Das Sicherheitsmodul welches den eigentlichen Dienst umschliesst ben tigt die Informationen ber die Workflows und die Au thentifikationsmerkmale die f r eine Rolle bzw Benutzer verlangt werden 7 KONZEPT UND SICHERHEITSBETRACHTUNG 83 Dar ber hinaus muss es noch Tabellen geben die den aktuellen Zustand fiir eine Session festhalten Interaktion des Sicherheitsmoduls mit der Wirtsapplikation Die In teraktion wird durch ein Ansprechen der Wirtsdatenbank erreicht so dass in der XML Beschreibung 8 2 SQL Anfragen formuliert werden k nnen deren Er gebnisse als Entscheidungsgrundlage herangezogen werden Hierbei wird davon ausgegangen dass eine Wirtsapplikation alle Daten in einer entsprechenden Da tenbank verwahrt Eine Erweiterung dieses Konzepts auf das Auswerten von z B Konfigurationsdateien ist m glich Somit ergibt sich ein Gesamtbild welches in Abbildung 24 dargestellt ist In ihm werden von links nach rechts der Client der IDP und der SP dargestellt Der SP besteht aus dem SecurityAspect und der Wirtsapplikation Die einzelnen Mo dule haben jeweils in der Vertikalen miteinander Kommunikationsbeziehungen Die Farben sind in Anlehnung an Abbildung 21 gew hlt Gr n eingef rbt sind die Komponenten der Wirtsapplikation gelb die Service Provider Module t rkis alle K
171. o centralized control Auch stellen sie fest dass Skalierbarkeit eine wichtige Eigenschaft von Syste men ist da viele konkurrierende bzw verschiedene Instanzen des gleichen Work flows zur selben Zeit ausgef hrt werden sollen Daher k nnen zentralisierte Work flow Management Systeme zu einer starken Geschwindigkeitsbremse werden vgl AAA 95 DKM 97 MWW 98 Es muss ein Weg gefunden werden wie die Entscheidungen ber die Zul s sigkeit eines Schrittes in einem Workflow m glichst dezentral getroffen werden kann Es ist aber gleichzeitig erw nscht dass auch andere Instanzen in Erfah rung bringen k nnen in welchem Zustand ein anderer Benutzer gerade ist Dies ist f r z B das Chinese Wall Modell siehe BN89 von Bedeutung da ein Be nutzer in einem webbasierten System durchaus mehrfach angemeldet und diese Mehrfachanmeldung auch erlaubt sein kann Modularit t Bei der Entwicklung der Sicherheit muss gew hrleistet werden dass die gestellten Anforderungen an die Stabilit t und Zuverl sigkeit eingehalten werden Da diese Forderungen nur durch intensive Tests der Sicherheit erreicht werden k nnen ist ein Ziel die Sicherheit m glichst in einem Modul zusammen zufassen Hierbei kommen auch Kostenerw gungen zum Tragen da ein einmal entwickeltes Modul potenziell auch in anderen Applikationen wiederverwendet werden kann Optimal ist ein Sicherheitsmodul wenn es komplett getrennt von der Software entwickelt und an die Software d
172. oftware bei externen Fir men anzumieten Die Anbieter von entsprechenden Diensten sogenannte App lication Service Provider ASP stellen in diesem Gesch ftsmodell alle Dienst leistungen die f r einen reibungslosen Ablauf der Software ben tigt werden zur Verf gung Ein solcher Vorgang wird als Outsourcing beschrieben Eine Weiterentwicklung dieses Konzeptes besteht darin auch anderen Firmen Zugang zur Betriebssoftware zu gew hren und Abl ufe in der Firmenkommuni kation wesentlich zu beschleunigen Das folgende Szenario soll dies verdeutlichen Ein Dienstleister nimmt defekte Ger te entgegen und gibt diese an den Her steller zur Reparatur weiter Bevor ein Ger t zum Hersteller gesendet werden kann muss die Reparatur beantragt werden Dieser Antrag erfolgt normalerweise ber ein Callcenter oder Kommunikationsstrukturen wie Email Da der Dienst leister einen speziellen Vertrag mit dem Hersteller besitzt wird ihm aber erlaubt direkt in der Software des Herstellers das Ger t zur Reparatur anzumelden Die Software entscheidet ob das Ger t zugelassen wird und vergibt dann die Fall nummer f r die Bearbeitung Der Dienstleister und der Hersteller haben hiervon einen Gewinn da weniger Personal und Zeit n tig sind um die Bearbeitung ein zuleiten Ein Anmieten der Software bietet verschiedene Vorteile In der Studie SBW01 stellen A Susarla et al verschiedene Aspekte vor Als besonders wichtig werden hier e der Zugang zur
173. og LogFactory getLog loggingAspect class pointcut traceMethods execution tip amp amp within loggingAspect loggingAspect test 0 before traceMethods test 1 Signature sig thisJoinPointStaticPart getSignature log debug Entering _ sig getDeclaringType getName sig getName _test J nn test after traceMethods Signature sig thisJoinPointStaticPart getSignature log debug Leaving _ sig getDeclaringType getName sig getName _test _ test Listing 9 Loggingaspect Dieser Aspect gibt f r jeden Methodenaufruf im definierten Fokus je eine Zeile f r den Beginn der Methode und das Beenden der Methode aus Die Ausgabe enth lt den Methodennamen sowie den Klassennamen Daneben wird ein Z hler jeweils erh ht Dieser z hlt durchg ngig von Null aufw rts da ein Aspect standardm ssig ein Singleton ist 3 2 2 Sicherheit f r eine einzelne Anwendung Hier soll gezeigt werden wie durch den Einsatz von AOP die Forderung nach einem Sicherheitskern vgl Eck01 Seite 122 auf elegante Weise realisierbar ist javax security auth Subject javax security auth login com sun security auth callback TextCallbackHandler public aspect Authentication 3 ASPEKTORIENTIERTE PROGRAMMIERUNG 43 private Subject _authenticatedSubject public pointcut authOperations execution public main String before
174. ogrammierte Webanwendung nachtr glich abgesichert werden kann Um zu zeigen das dieses Konzept tragf hig ist wird es in Form eines Demonstrators implementiert siehe Kapitel 8 7 1 Konzept Es soll eine generische Absicherung eines Webservices realisiert werden Das ei gentliche Produkt muss in diesem Fall nicht im Sourcecode vorliegen sondern wird lediglich um eine neue Funktionalit t erweitert Diese Funktionalit t be steht im Hinzuf gen von Autorisations und Authentifikationsmechanismen Ein besonderes Augenmerk liegt in der r umlichen Verteilbarkeit dieser Dienste auf verschiedene Server Ein weiterer Bereich ist das berwachen und F hren der Benutzer in der Verwendung von Hardwaretoken die zur Authentifikation Ver wendung dienen Der zentrale Teil ist das Sicherheitsmodul in dem die Autorisation und Au thentifikation implementiert ist und welches zu einer Wirtsapplikation hinzuge f gt werden kann Da der Sourcecode der Wirtsapplikation nicht vorliegt muss das System auf andere Weise erfahren welcher Benutzer welche Resourcen verwenden darf Hier zu wird eine Trainingsphase der eigentlichen Produktivit tsphase vorgeschaltet in der das Sicherheitsmodul an das zu sch tzende System angepasst wird Ein weiteres Ziel besteht in der Definition eines XML basierenden Datenfor mats mit dessen Hilfe die Sicherheitseigenschaften beschrieben werden k nnen und der Entwicklung eines Tools zur halbautomatischen Erzeugung der Besc
175. ohlen wenn eine abh ngige Partei SP von Authen tifikationsdaten einer anderen Partei IDP abh ngig ist die Benutzung von SSL 3 0 mit Server und Client Zertifikaten anzuwenden Wenn eine Assertion ber ein web redirect ber eine dritte Partei z B den Browser des Benutzers gelei tet wird muss diese mit einer digitalen XML Signatur signiert werden Da es mittlerweile einige Angriffsszenarien auf Single Sign On Protokolle auf Basis von SAML gibt empfiehlt Gro03 immer einen sicheren bertragungskanal wie SSL 2 SINGLE SIGN ON 29 3 0 oder TLS 1 0 mit mindestens einseitiger Authentifikation fiir die Ubertragung der Informationen zu verwenden SSL bietet Authentizit t Frische und verhindert Wiedereinspielungen von Nachrichten sodass ein Gro teil der Angriffsm glich keiten abgefangen werden Nach TC03 unterscheidet Liberty die Absicherung des Protokolls auf der Kommunikationsebene Channel Security und auf der Nachrichtenebene Mes sage Security e Channel Security Mit der Channel Security wird dabei die Absicherung der Kommunikation zwischen Kommunikationspartnern addressiert im Falle von Liberty die Ko munikation zwischen Identity Provider Service Provider und dem Browser des Benutzers Liberty gibt hier vor dass die Absicherung der Kommuni kation mittels TLS1 0 oder SSL3 0 geschehen muss Die Spezifikation von Liberty besagt dass f r die Channel Security Vertraulichkeit und Datenin tegrit t vorgeschrieben sind we
176. ollte eine initiale Authentifika tion nur aus einer Kombination mit einem anderen Authentifikationsverfahren durchgef hrt werden z B zus tzlich mit einer Passworteingabe Damit wird eine Authentifikation nach Wissen und Besitz durchgef hrt siehe Kapitel 5 Au er dem darf ein solcher Token nicht Dritten leichtfertig verf gbar gemacht werden Da dieses Problem bei vielen Benutzern nicht als bekannt vorausgesetzt werden kann ist es erforderlich die Benutzer in diesem Themenbereich zu sensibilisieren Falls ein Token der der Identifikation dient an einem unbeobachteten Sys tem zur ckgelassen wird besteht die Gefahr dass sich jemand Drittes Zugang zu dem zu sch tzenden System verschafft Dies kann durch einen zuvor erfolgen Passwortdiebstahl oder eine noch angemeldete Session erreicht werden Der An greifer kann dann im Namen eines Mitarbeiters in dem System arbeiten Hier greift die Proaktivit t und soll den Benutzer daran erinnern den Token nicht zur ckzulassen und damit Angriffe dieser Art verhindern helfen Training Da dem Sicherheitsmodul die Abl ufe in der zu sch tzenden Appli kation nicht bekannt sind m ssen diese erst erlernt werden Dies geschieht durch das Durchf hren der Workflows unter speziell kontrollierten Bedingungen Diese m ssen danach durch einen Administrator von dem speziellen Fall auf die allge meinen Workflows generalisiert werden Damit ist gemeint dass wenn z B beim Durchf hren einer berweisung ein
177. omponenten des IDPs sowie der Proaktivit t und braun die Datenbanken des IDPs und SPs Browser SourcelD Abbildung 24 Gesamtkonzept 7 3 Sicherheitsbetrachtung des Konzepts Eine Sicherheitsbetrachtung eines aus Sicherheitsmodul und Wirtsapplikation zu sammengesetzten Systems ist im Allgemeinen nur schwer m glich da die Figen schaften des Gesamtsystems nicht nur von dem hier vorgestellten Konzept abh n gig sind sondern auch von dem zu sch tzenden System Sicherheitsverletzungen die durch die Wirtsapplikation entstehen k nnen durch das hier vorgestellte Kon zept nicht erkannt werden Die Grenzen das Ansatzes stellen sich wie folgt dar 84 Das Sicherheitsmodul hat Konzeptbedingt keine M glichkeit zu berpr fen ob die Antworten der Software den gewollten Antworten entsprechen Die in Kapitel 6 3 vorgestellten Angriffe werden durch den Security Aspect nicht verhindert Eine inhaltsbasierte Kontrolle von Informationsfliissen kann nur bedingt erfolgen da das Sicherheitsmodul nur auf der Basis der Eingaben des Benutzers entscheidet ob ein nachfolgender Zustand legitim ist Es wird nicht verifiziert dass das zugrunde liegende System unver ndert ist Eine Ver nderung der Klassen des Systems wird nicht erkannt Dies wird in Kapitel 10 nochmals beleuchtet Das Konzept ist auf die Absicherung der Server angewiesen Sowohl die Identity Provider Applikation die die Authentifikationen durchf hrt als auch
178. ovider angegebenen Authentifikation vertrauen kann Damit nicht alle Details des AuthnContext angegeben werden m ssen um eine Kommunikation zwischen Identity Provider und Service Provier zustande kom men zu lassen wurde die Spezifikation um sogenannte Authentication Con text Classes erweitert Diese unterteilen die verschiedenen Mechanismen der Authentifikation in gewisse Klassen und werden ber festgelegte URIs spezifiziert Standardm ig gibt es zum Beispiel die Klasse Password in der alle Verfahren zusammengefasst sind die eine Passwortauthentifikation ber einen unverschl s selten Kanal durchf hren oder z B die Klasse PasswordProtected Transport in der die Verfahren einer Passwortauthentifikation ber eine gesch tzte Verbindung zusammengefasst sind Mit diesen Klassen wird die Sicherheitsbewertung des Ser vice Providers vereinfacht da die gleichen Mechanismen in einer Klasse hnliche Sicherheitskriterien mit sich bringen Au erdem wird es dem Service Provider 28 vereinfacht seine bevorzugten Authentifikationsmethoden anzugeben Der Iden tity Provider kann ber diese Spezifikation seine Authentifikationsfahigkeiten auf einfachem Weg ver ffentlichen Die Erstellung und berpr fung des AuthnContext wird von SourcelD s u nicht bernommen sondern muss von der Applikation auf beiden Seiten also sowohl auf der Identity Provider Seite als auch der Service Provider Seite im plementiert werden Da ein Bestandt
179. plikation kompiliert werden Dazu reicht es aus die Datei TrainingAspect java in das src Verzeichnis der Applikation zu kopieren und die Applikation zu kompilieren Au erdem muss das Build Script des dbtools ausgef hrt werden damit die zur Kommunikation zwischen dem TrainigsAspect und Webtool be n tigten Klassen zur Verf gung stehen Dieses Script erzeugt die jar Datei se curityDatabase jar und kopiert diese ins Verzeichnis common lib des Tomcats damit die beiden Applikationen eine gemeinse Kommunikationsbasis aufbauen k nnen Da der Trainingsaspect in einer anderen Anwendungsumgebung als das Web Tool l uft muss der Tomcat Server so konfiguriert werden dass er eine Kommunikation zwischen beiden gestattet Dies wird durch den in Listing 33 gezeigten Parameter crossContext in der Datei server xml des Tomcats erreicht lt Context path web_tool docBase web_tool reloadable true crossContext true gt lt Context path jpetstore docBase jpetstore reloadable true crossContext true debug 10 gt Listing 33 nderung an der server xml Um einen Workflow aufnehmen zu k nnen muss zuerst im Webtool unter dem Punkt workflow generator die Aufzeichnung eines Workflows gestartet werden Abbildung 38 Daraufhin kann man in der Applikation beginnen einen Workflow aufzuzeichnen Hierbei kann die Applikation ganz normal benutzt wer den und es werden die ben tigten Daten vom TrainingAspect aufgezeichnet Bei spielhaft wurd
180. privatem Schl ssel verschl sselt und diese daraus entstandene digitale Signatur zum Verifier als Antwort schickt Wichtig bei diesem Verfahren ist dass der Verifier dem ffentlichen Schl ssel des Claimants vertrauen kann Um dies berpr fen zu k nnen muss es eine Public Key Infrastruktur geben N heres hierzu in Eck03 Kapitel 7 6 1 Ein Beispiel eines asymmetrischen Kryptosystem ist das Authentifikationsverfahren des SSL Protokolls Chipkarten Die Authentifikation mit Hilfe einer Chipkarte ist eine Form der besitzbasierten Authentifikation Nur jemand der im Besitz dieser Karte ist kann sich authentifizieren Hierbei wird normalerweise die Chipkarte ber ein Karten leseger t an den Computer angeschlossen und der Computer authentifiziert sich mit Hilfe des Schl ssels auf der Karte gegen ber dem Verifier oder der Schl ssel bleibt auf der Karte und diese t tigt die Authentifikation direkt Man unterscheidet drei Arten von Chipkarten Eck03 Einfache preiswerte Speicherkarten die nur zur reinen Speicherung von Daten ausreichen Intelligen te Speicherkarten die zus tzlich eine Sicherheitslogik meist zur PIN berpr fung besitzen Und drittens die Smartcards die mit einem eigenen Mikroprozessor und programmierbarem Speicher ausger stet sind Die Authentifikation mit Hilfe von Chipkarten basiert darauf dass ein geheimer Schl ssel auf ihnen gespeichert ist Dieser geheime Schl ssel wird entweder wie bei den einfachen Speicherkarte
181. r berh ufung der Be nutzers mit verschiedensten Accounts und zugeh rigen Passw rtern f hren Es kann z B passieren dass ein Fluggast einen Flug online gebucht hat und f r die Online Reservierung eines Autos bei einer angeschlossenen Autovermietung wiederum ein neues Passwort vorweisen muss Die Sicherheit eines Passwortes steht und f llt mit der sicheren Verwahrung und Wahl des Passwortes Da ein Mensch sich aber nicht unbegrenzt viele unter schiedliche kryptische Passw rter merken kann tritt das Problem auf wie man den Passwortwucher b ndigen kann Viele benutzen einfach das gleiche Passwort f r unterschiedlichste Dienste oder schreiben sich die verschiedenen Passw rter irgendwo in der N he ihres Computers auf Eine M glichkeit das Problem der unterschiedlichen Accounts bzw Passw r ter zu vereinfachen ist das Konzept des Single Sign On SSO Nach Eck03 ist ein Single Sign On ein System bei dem sich ein Benutzer in einem verteilten System nur einmal f r den Zugang zu den vernetzten Rechnern authentifizieren muss Der authentifizierte Zugang zu den anderen vernetzten Rechnern wird au tomatisch abgewickelt d h der Benutzer muss sich nur ein Passwort merken um alle angeschlossenen Dienste nutzen zu k nnen Dieses Konzept kann z B bei der Fluggesellschaft implementiert sein Wenn ein Reisender einen Flug ber die Webseite der Fluggesellschaft gebucht hat und zus tzlich bei dem Tochterunter nehmen der Fluggesellschaft
182. r Liberty Alliance federated network identity model genannt Unter federated ist im Kontext von Liberty dabei der Zusammenschluss von network identities ge meint also der Zusammenschluss von unterschiedlichen Online Identit ten eines Benutzers die zusammen seine network identity ergeben Da das Ziel einer eindeutigen network identity nicht auf Anhieb mit inhomo genen Systemen vereinbar ist hat die Liberty Alliance mehrere Spezifikationen zu seiner schrittweisen Umsetzung ver ffentlicht ID FF Liberty Identity Federation Framework Version 1 0 von 2001 seit Ende 2003 Version 1 2 Der Fokus des ID FF liegt auf der Verkn pfung federate von Zugangsdaten und dient als Basis f r ein Single Sign On System Die oben genannte digital identity beinhaltet in dieser Spezifikation nur die Zugangsdaten zu einem Webdienst Account ID WSF Die Phase zwei der Liberty Alliance Aktivit ten ist die Spezifizie rung des Liberty Identity Web Services Framework und wurde Anfang 2004 mit der Version 1 0 herausgebracht ID WSF baut auf dem ID FF Protokoll auf und umfasst nun auch AAA Daten sowie pers nlichen Daten eines Benutzers die frei definiert werden k nnen ID WSF spezifiert ein Protokoll und Sicherheitsma nah men um diese Daten zwischen Providern austauschen zu k nnen Das Protokoll legt somit die Grundlage f r den Austausch von umfangreichen Identit tsdaten zwischen Diensteanbietern ID SIS Die dritte und letzte Phase der
183. r Syntax werden wie in Kapitel 3 6 beschrieben durchgef hrt Es ist somit sichergestellt dass das ausgef hrte Programm syntaktisch korrekt ist und die Schnittstellendefinitionen eingehalten werden Einem Javaprogramm ist es nicht anzusehen ob es durch einen Weaver siehe Kapitel 3 1 2 ver ndert wurde Es kann somit jedes beliebige Programm in sei ner Funktionalit t ge ndert werden Um diesem Problem zu begegnen sieht Java die Signatur der Programme vor Die Klassen werden hierzu in ZIP komprimier te Archive JAR zusammengefasst und danach signiert siehe hierzu SUN85 und ST85 Ein Benutzer kann dadurch kontrollieren von wem die Software er zeugt wurde und ob sie seit der Signierung ver ndert wurde Dieses Verfahren ist auch f r die Web Archive WAR anwendbar die im J2EE Umfeld zum Einsatz kommen Der Inhalt einer war Datei wird beim Deployment im Applikationsserver ent packt und ab diesem Moment nicht mehr verwendet Der Server kontrolliert nicht ob das Verzeichnis identisch zu dem Archiv ist Ein Angreifer kann somit falls er ungehinderten Zugriff auf den Server bekommt ber die aspektorientierte Pro grammierung das Programm in seinem Verhalten ver ndern oder hnlich dem beschriebenen HTMLRewriter die Benutzerinteraktion protokollieren Eine sol che Ver nderung kann beispielsweise durch ein Programm wie Tripwire siehe Kapitel 6 2 erkannt werden Anhand dieser Sicherheitsbetrachtung wird es deutlich dass es zur Zeit
184. rd in Abbildung 16 beispielhaft als Automat dargestellt Auf diese Art und Weise lassen sich auch komplexere user BERT user BERT Progra mm Abbildung 16 Beispiel eines Ablaufs Ablaufe erfassen Ein Referenzmonitor besitzt eine Menge von Workflows die einzelnen Benut zern zugewiesen werden Bei jedem Interaktionsschritt der Software vergleicht der Monitor die Benutzereingaben mit den erlaubten Werten die in den Workflows hinterlegt sind Auf dieser Basis kann nun entschieden werden ob ein Schritt in der Interaktion abgelehnt werden muss oder ob er erlaubt ist 54 Eine erste Erweiterung dieses Modells ist das Einf hren von regul ren Aus dr cken f r die berpr fung der Eingaben des Benutzers Durch die Verwendung von regul ren Ausdr cken eine genauere Darstellung der M glichkeiten findet man in Fri97 k nnen z B Wertebereiche definiert werden Eine denkbare An wendung hierf r sind Finanztransaktionen Ein normaler Mitarbeiter darf nur 1000 Euro berweisen Sein Vorgesetzter darf aber bis zu 10000 Euro transfe rieren Der Term im ersten Fall w rde so aussehen 1 0 9 0 3 im zweiten Fall 1 0 9 0 4 Eine zweite Erweiterung der Workflows ist die Einbeziehung der Applikations datenbank Wenn z B in einem Men nur Hunde und Katzen zur Auswahl stehen kann dies durch eine Datenbankanfrage festgestellt werden und der Monitor er laubt in diesem Fall auch nur die Angabe von Hund oder Katze Hi
185. rever schl sselungen gegen ber DES Der FEAL Algorithmus war urspr nglich auf 4 Runden deshalb auch FEAL 4 ausgelegt wurde aber recht schnell auf 8 Run den verdoppelt MSS88 da es einige sehr leichte Angriffsm glichkeiten auf den FEAL 4 gab Einer sogar nur mit maximal 20 gew hlten Klartexten Mur90 Al lerdings wurde auch der FEAL 8 mittels Kryptoanalysen BS91 gebrochen Im Jahre 1994 wurde ein Kryptoanalyse Attacke gegen FEAL 8 entwickelt die nur 22 gew hlte Klartexte ben tigt OA94 Hiernach wurde eine FEAL N Version des urspr nglichen FEAL Algorithmus entwickelt der N Runden durchf hrt Al lerdings gibt es f r FEAL N bis zu 31 Runden auch Kryptoanalytische Attacken Der FEAL Algorithmus sollte wegen der Vielzahl von Angriffsm glichkeiten als unsicher betrachtet werden Lab00 Der Verschl sselungsalgorithmus des Wibu Keys ist nach AG04 wie in Ab bildung 20 dargestellt eine Hintereinanderausf hrung mehrerer FEAL 8 Algo rithmen Zuerst wird der Firm Code mit einer Konstanten als Schl ssel verschl s FEAL 2998 Firm Code User Code Selection Code Data Abbildung 20 Wibu Key Feal Algorithmus AG04 selt Das Ergebnis wird als Schl ssel f r eine erneute FEAL Runde mit dem User Code verwendet Dieses Ergebnis wird daraufhin wieder als Schl ssel f r ei ne FEAL Runde mit dem Selection Code verwendet Das Ergebnis hieraus bildet den Schl ssel f r die eigentlichen Daten die verschl sselt werden sollen
186. rgen Repp Roland Rieke Martin Schmucker Steven Vettermann Uwe B ttge Cristina Escaleira und Dirk R diger Implementierung von Security Policies in offenen Telekollaborationen In D A CH Security 2004 Seiten 37 49 P Horster Hrsg 2004 IDS00 Testing Intrusion detection systems a critique of the 1998 and 1999 DARPA intrusion detection system evaluations as performed by Lincoln Laboratory ACM Trans Inf Syst Secur 3 4 262 294 2000 URL http doi acm org 10 1145 382912 382923 Int Internet2 Uses of Shibboleth URL http shibboleth internet2 edu shib uses html JF 03 JasonBrittain und Ian F Darwin Tomcat The Definitive Guide O Reilly 1 Auflage 2003 KLM 97 Gregor Kiczales John Lamping Anurag Mendhekar Chris Maeda Cristina Videira Lo pes Jean Marc Loingtier und John Irwin Aspect Oriented Programming 1997 URL http www2 parc com csl1 groups sda publications papers Kiczales ECOOP97 KR00 David P Kormann und Aviel D Rubin Risks of the Passport Single Signon Protocol Computer Networks Vol 33 51 58 2000 URL http avirubin com passport html KS02 Savith Kandala und Ravi Sandhu Secure role based workflow models In Proceedings of the fifteenth annual working conference on Database and application security Seiten 45 58 Kluwer Academic Publishers 2002 Lab00 RSA Laboratories RSA Laboratories Frequently Asked Ques tions About Today s Cryptography Version 4 1 2000 URL http
187. rl utert Eine detaillierte Beschreibung aller wichtigen Profile findet man in Liberty ID FF Bindings and Profiles Specification CK03 Zur Vereinfachung wird angenommen dass der Benutzer bei seinem Ser vice Provider und Identity Provider f derierte Accounts hat Die hierfiir n tigen Schritte werden durch die anderen Profile des Liberty Protokoll spezifiziert Wei terhin wird angenommen dass sich der Benutzer noch nicht bei einem der Pro vider authentifiziert hat Das Profil siehe Abbildung 2 beginnt mit der HTTP Anfrage eines Benutzers zur Nutzung eines Service Provider Dienstes 1 Der Service Provider muss ermitteln 2 welcher seiner eingetragenen IDPs fiir den Benutzer passend ist Dies wird als das Introduction Problem bezeichnet und wird durch das Identity Provider Introduction Profil abgewickelt Daraufhin schickt 3 4 der SP den Browser des Benutzers tiber ein Web Redirect siehe Seite 23 zu dem Identity Provider und tibergibt ihm die Riickkehradresse und eine Aufforderung zur Authentifikation des Benutzers AuthnRequest s u Der Identity Provider fiihrt die Authentifikation 5 durch und antwortet tiber 2 SINGLE SIGN ON 23 Browser Service Provider Identity Provider 1 HTTP Anfrage 1 gt 1 2 IDP ermitteln 3 Weiterleitung zum IDP gt 1 4 Weiterleitetung zum IDP 5 Loginprozess 6 Weiterleitung zum SP 7 Weiterleitung zum SP g
188. rlegen kann lt a href http www ezample com search query lt script language javascript gt document location http www grovywings com foo document cookie lt script gt gt link lt a gt Listing 15 Beispiel eines XSS Angriffs Wenn ein Benutzer auf diesen Link klickt wird der richtige Server mit dieser Suche beauftragt Wenn nun der Server eine Antwortseite produziert auf der auch der von Benutzer eingegebene Inhalt steht wird der im Inhalt eingebettete Skriptbefehl ausgef hrt Der Benutzer sendet sich also selber b sartigen Code Eine genauere Darstellung von XSS Angriffen kann in Eck03 Seite 100 in JF03 Seite 147 oder Woe04 gefunden werden HTML Injection Hierbei wird HTML Code auf eine Seite gestellt so dass Be sucher etwas anderes sehen als der Autor der Seite wollte In JF03 wird festgestellt dass die f r HTML Injection anf lligen Seiten gr tenteils ein HTTP Get erlauben um HTML Code hochzuladen in der L nge die der HTTP Client in einer URL erlaubt Leider wird dieser Angriff in der Litera tur meist in Kombination mit XSS Angriffen aufgef hrt und nicht gesondert behandelt Eine Darstellung des Angriffs findet sich in JF03 SQL Injection Hier geht es um einen Angriff auf die Datenbank die hinter einem Webserver steht Die Technik ist hnlich dem XSS Angriff Meist findet diese Form des Angriffs ber die Formfelder einer Webanwendung statt Hierzu ist es n tig
189. ronic Commerce sind weitere Daten wie z B Bezahlungsda ten und Versanddaten f r einen Kauf sowie statistische Daten ber das Benutzer verhalten wichtig Ein weiterer Faktor ist die Tatsache dass bei einem Gro teil der Benutzer die Bereitschaft sehr klein ist zus tzliche Software zu installieren sei es zur einfacheren Nutzung oder aus Sicherheitsgr nden PWO02 Single Sign On Protokolle f r Electronic Commerce m ssen deshalb mehr als nur eine AAA Architektur unterst tzen k nnen und auf der Client Seite m g lichst mit nichts au er dem Kernbetriebssystem und dem Browser zurechtkom men In PW02 wird ein Protokoll das diese Anforderungen erf llt deshalb als ein browser based attribute exchange Protokoll bezeichnet und umfa t unter anderem Browser based Die Unterst tzung m glichst aller Browser auf m glichst allen Plattformen Case by case attribute exchange Den freie Austausch von Atributen die nicht jedesmal zwingend die Authentifikationsdaten beinhalten Cross trust domain Der Austausch von Informationen zwischen Parteien die zu unterschiedlichen Domains geh ren compatible with zero footprint Benutzbar nur mit den M glichkeiten eines Browsers Das Protokoll mu funktionieren auch wenn auf dem Client Rechner au er dem Browser keine spezielle Software zum Austausch von Attributen vorhanden ist compatible with mobility Benutzbar f r mobile Benutzer die verschiedene Devices wie z B Computer Handhelds
190. rtup gt lt servlet gt lt servlet mapping gt lt servlet name gt ajsp lt servlet name gt lt url pattern gt jsp lt url pattern gt 3 ASPEKTORIENTIERTE PROGRAMMIERUNG 45 lt servlet mapping gt Listing 13 nderungen an der web xml Nun muss dem Compiler noch mitgeteilt werden wo bzw wie er potentielle Aspecte findet Dazu bietet der ajc eine Schnittstelle an die es erm glicht die Compilerparameter zu ndern Um dies m glich zu machen muss wie folgt eine Umgebungsvariable gesetzt werden export CATALINA_OPTS Dorg aspectj tools ant taskdefs AjcTask COMMAND_EDITOR ajee adapters AutoAspectpathRewriter Listing 14 Compilerparameter Die hier angegebene Klasse durchsucht vor dem Compilationsprozess verschiede ne Verzeichnisse nach bin rvorhandenen Aspecten um diese dann dem Compiler mitzugeben Sie ist auf der zugeh rigen CD zu finden Leider reagiert dieses Sys tem nicht auf das Austauschen der Aspecte da diese Erweiterung nur aktiv wird wenn der Tomcat JSP Dateien kompiliert Um einen Austausch eines Aspects zu erreichen ist es n tig im work Verzeichnis den Applikationspfad zu l schen Dadurch wird der Tomcat gezwungen neu zu kompilieren und die Aspecte zu verwenden Da dieser Vorgang durch ein Ant Skript elegant zu l sen ist stellt er keine echte Einschr nkung dar 3 5 Vorteile und Probleme Der Einsatz der aspektorientierten Programmierung im Rahmen der Entwicklung eines Si
191. rwahren sind vgl SLZ 04 6 SERVERABSICHERUNG 71 6 3 Tomcats Sicherheitskonzept Um ein J2EE Programm ausfiihren zu k nnen wird eine J2EE konformer Ap plikationsserver ben tigt der die entsprechende Umgebung zur Verfiigung stellt die eine Webapplikation ben tigt Daher wird der Applikationsserver auch als Container bezeichnet Der Tomcat ist ein bekannter Vertreter unter den Ap plikationsservern und die Referenzimplementierung von SUN Fiir diesen Server existieren zwei kombinierbare Wege die Sicherheit des Servers zu erh hen und ihn gegen Angriffe zu h rten security Option In der Grundeinstellung des Tomcat unterliegt ein Programm keinerlei Begrenzung in der Verwendung von Resourcen Durch die security Option wird der SecurityManager aktiviert der es dem Entwickler erm g licht eine feink rnige Beschr nkung der Rechte des Programms zu entwer fen Die Rechte werden in der Datei catalina policy verwaltet Das Format ent spricht der herk mmlichen Policydatei wie sie in Java Verwendung findet Hier k nnen Rechte fiir eine gesamte Codebasis oder fiir einzelne Javaklas sen gesetzt werden Fine genaue Darstellung der M glichkeiten findet sich in JF03 Seite 133 oder Foul chroot Umgebung Unix und die Derivate davon bieten die M glichkeit ber den chroot Befehl ein Programm in einem anderen Verzeichnis oder unter einem anderen Benutzer auszuf hren Bei einem erfolgreichen Angriff auf den Dienst ist es dem Angreifer n
192. s gleiches Schl ssels sind und beide den glei chen Verschl sselungsalgorithmus verwenden Definition siehe ISO Norm 9798 97997 Dieser geheime Schl ssel kann aus dem Passwort des Benutzers abge leitet sein oder aber er ist zu komplex als dass ihn sich ein Benutzer merken k nnte sodass er auf einer Chipkarte oder einem Rechner gespeichert wird Die berpr fung des Schl ssels wird dabei berwiegend mittels Challenge Response Verfahren get tigt N heres zum Challenge Response Verfahren findet man in Eck03 Kapitel 10 2 3 Der Verifier schickt dem Claimaint eine Challenge meis tens eine Zufallszahl die der Claimant mit dem Schl ssel verschl sselt und das Ergebnis die Response an den Verifier zur ckschickt Der Vorteil ist dass bei jeder Authentifikation eine andere Challenge bertragen wird und es somit ei nem Angreifer erschwert wird einen Maskierungsangriff durchzuf hren Aller dings sollte hier eine wechselseitige Authentifikation stattfinden da sich sonst ein Angreifer als Verifier maskieren und somit eine known plaintext Attacke auf den Claimant ausf hren k nnte Au erdem muss beachtet werden dass ein Angreifer die Verbindung zwischen Claimant und Verifier kontrollieren und die Response vom Claimant abfangen k nnte diesen au er Gefecht setzt und sich daraufhin mit der gestohlenen Response ausweisen k nnte Dies kann durch eine Erweite rung des Challenge Response Systems verhindert werden Ein weiteres Problem bei
193. s securityAspect 2 22 2 o 101 IDP Ablauf e e Ee da a a a a Re a A 106 vom SP initiierter IDP Ablauf gt gt iroa tisse ren 107 Ablaut Wibukey 25 038 2 ret 111 o SG eG AI 113 Starten einer Workflowaufzeichnung 117 ABBILDUNGSVERZEICHNIS 133 39 40 41 42 43 44 45 46 47 48 49 50 ol 92 53 54 59 56 Startseite des JPetstores o o 117 JPetstore lt PIDH os c capa ea thi 117 JPetstore Gold sh 2 22 2 E r nta 8 aa eee sa e ke 118 Beenden einer Workflowaufzeichnung 118 Bearbeitung der Workflows 2 2 2 a o 118 Bearbeitung eines Workflows 119 Bearbeitung eines States e o o na ec c be ae 2 2 ee 120 Pole Management cc ceso neice ee eee ENEE A SG A 120 bersicht der Rollen oreco teite E a e 120 Rollenbearbeitung 2 2 121 User Management 22 2 1 44 ENER a db a 121 bersicht der Dentzer 121 Benutzer Bearbeitungsmaske 2 2 2 22 nn nn 122 Erzeugung der XML Beschreibung 122 Identity Provider Login Page 2 24 oo eke 205 124 ii PIO 124 ProAktiv Apple au ass en aroga oas d mia E EE E 125 a c a etca a ae ae we re ee ELE d we ELE der 125 134 C Listingverzeichnis Listings 1 Auszug aus der web xml 2 2 nn nn 32 2 Auszug aus der sourceid sso providers xml 32 3 Auszug aus der sourceid sso xml 222 22 2 2 22er 33 4 Beispiel emes Faken lt
194. scribing many to many relationships between individuals and rights 92 Somit unterscheidet sich RBAC von anderen Sicherheitsstrategien da hier nicht die Subjekte im Mittelpunkt der Betrachtung stehen sondern die durchzuf hren den Aufgaben vel Eck01 S 129 In San98 hebt R Sandhu hervor dass eine Rolle eine stabile Einheit inner halb einer Organisation ist die sich ber die Zeit nur langsam ndert Damit unterscheidet sich eine Rolle stark von einer einfachen Gruppierung Eine Rolle repr sentiert alle Kompetenzen die ben tigt werden eine spezielle Aufgabe zu erf llen Weiter stellt R Sandhu fest dass f r ein rollenbasiertes System zwei Eigenschaften entscheidend sind e Es muss ungef hr gleich schwer sein die Rollenmitgliedschaft und die Rol lenrechte zu bestimmen e Die Kontrolle ber die Rechte muss auf eine kleine Anzahl von Benutzern reduziert sein Bei all diesen Modellen stellt sich die Frage wie der Referenzmonitor jeweils entscheidet ob ein Zugriff gew hrt werden darf oder nicht Hier gibt es zwei grunds tzlich unterschiedliche Ans tze e Das System kann berechnen ob ein Zugriff gestattet wird e Das System erh lt diese Information von au erhalb Der erste Ansatz nimmt an dass es m glich ist diese Entscheidung zu berechnen was aber im allgemeinen nicht der Fall ist siehe Sch03 Der Referenzmoni tor ist auf eine externe Datenquelle angewiesen in der die Informationen ber Berechtigunge
195. sd element name transitions type transitionsType minOccurs 0 maxOccurs 1 gt lt xsd sequence gt lt xsd attribute name name type xsd string gt lt xsd attribute name className type xsd string gt lt xsd complex Type gt Listing 18 Definition von Zust nden Bei den Uberg ngen von einem Zustand zum N chsten wird der Folgezustand angegeben sowie die Bedingungen die eingehalten werden m ssen F r jeden Parameter kann ein regul rer Ausdruck oder ein SQL Ausdruck oder beides an gegeben werden Der regul re Ausdruck kann als Filter angesehen werden Der SQL Ausdruck produziert eine Liste in der der Wert des Parameters enthalten sein muss Fiir den SQL Ausdruck werden zus tzlich noch diverse Parameter fiir den Datenbankzugriff angegeben Die Schemadefinition eines Ubergangs ist in Listing 19 gezeigt lt xsd complexType name transitionType gt lt xsd sequence gt lt xsd element name target type xsd string gt lt xsd element name constraint type constraintType minOccurs 0 maxOccurs unbounded gt lt xsd sequence gt lt xsd complex Type gt lt xsd complexType name lt xsd sequence gt lt xsd element name para type xsd string gt lt xsd element name regex type xsd string minOccurs 0 maxOccurs 1 gt lt xsd element name SQLConstraint type SQLConstraintType minOccurs 0 maxOccurs 1 rra lt xsd sequence gt lt xsd complexType gt constrai
196. t Das Liberty Framework als Basis der Authentifikation erm glicht neue Wege in der Kooperation unterschiedlicher Firmen da die Integration externer Mitarbeiter schnell und effizient realisierbar ist In Verbindung mit der vorgestellten flexiblen Autorisation der Benutzerinteraktion k nnen die gew nschten Arbeitsabl ufe ef fizient beschrieben werden Somit ist eine Kooperation von Firmen in kurzer Zeit etablierbar Dar ber hinaus erfolgt durch den m glichen Wiedereinsatz des Si cherheitsmoduls eine Komplexit tsreduktion der Wirtsapplikation Hierdurch ist sie billiger und schneller in der Entwicklung Die in Kapitel 8 vorgestellte Implementierung hat verdeutlicht dass es m g lich ist Sicherheit nachtr glich in einen verteilten Webservice einzuf hren Die klare Trennung des Benutzungsinterface von der Programmlogik und die einheitli chen Schnittstellen dazwischen erm glichen den in dieser Diplomarbeit verfolgten Weg Ohne diese Schnittstellen ist ein Einf gen von Workflows nicht so einfach m glich Daher ist es schwer zu beurteilen inwieweit das vorgestellte Konzept sich au erhalb von Webservices verwenden l sst Ein alleiniges Hinzuf gen von Authentifikationsmethoden ist aber im Prinzip wie in Kapitel 3 2 2 gezeigt m g lich Da der Demonstrator Sicherheit nachtr glich in ein System integriert ist die Betrachtung der Sicherheit der modularen Sicherheitsfunktionen und ihrer Kom munikation ein wichtiger Punkt Die genaue Betrach
197. t 4 44 8a 4 eve ea eas 26 Struktur einer SOAP SAML Nachricht 27 Source ID API a dh RR A deer A 31 SP Interaktion Applikation amp SourceID API 34 IDP Interaktion Applikation SourceID API 35 Einsatz von Logging im Tomcat 2 04 44 3 2 2 2 20 bn E 36 Zusammenf gen eines Systems aus Concerns 38 Ein System wird als Komposition von Concerns betrachtet Lad03 38 Schema des Weaver 41 Referenzmonitor als OS Bestandtteil 50 Referenzmonitor im Interpreter integriert 50 Inline Referenzmonitor 51 Beispiel eines Ablaufs io 24424544 6445445 53 Einsatz von Workflows in RBAC 54 Beispielworkflow 2 24564 be ee Re rim ee nn 55 Tasek DOUE 5 ers pr owe Bw ae aa 56 Wibu Key Feal Algorithmus AG04 67 Gesamtkonzept gt o oe eos e haw EE Ee ta aora raara 80 Aspecte verbunden mit der Wirtsapplikation 81 Ablauf einer Anmeldung 81 Gesamtl nge essen kes uie ES GS 83 Dre Schichten Modell o u e a0 444 u Gee 2 a au A d 85 Entwicklungsschrilte co 2a a seras Kran 91 Verwendung der XML Beschreibung 93 Zusammenhang von Usern Rollen und Workflows 95 relationales Modell der DatenbankI 97 relationales Modell der Datenbank I 97 relationales Modell der IDP Datenbank 98 Der Securityaspect umh llt die Methoden 99 Flussdiagramm de
198. t zu betrachten Dadurch wird es m glich f r die Verwaltung der Authentifikationsmerkmale getrennte Server und Administrato ren einzusetzen Auch kann dieser Teil vollkommen getrennt von der Applikation weiterentwickelt werden Hierbei ist zu beachten dass nach einer erfolgreichen initialen Anmeldung an den Server die Software eine regelm ssige Reauthentifi kation am Server vorsehen kann Auf diesem Weg kann die G ltigkeit einer aus gestellten Authentifikation regelm ig durch den Identity Provider neu gepr ft werden Autorisation Nach einer erfolgreichen Authentifikation am Loginserver ste hen dem Benutzer potentiell alle Resourcen der Software zur Verf gung Eine m gliche Einschr nkung ist die Interaktion des Benutzers mit der Software zu reglementieren Hierzu f hren wir den Begriff der Workflows ein wie sie in Kapitel 4 3 definiert werden Jeder Workflow beschreibt eine Abfolge von Webseiten und den Benutzereingaben die erlaubt sind um von einer Seite zur N chsten zu kom men Dies l sst sich ber eine Finite State Machine beschreiben Die berg nge k nnen durch regul re Ausdr cke erfasst werden Als Sicherheitsmodell findet RBAC Anwendung Dieses wird in Kapitel 4 2 eingef hrt Die Konsequenz hieraus ist dass jede Interaktion die nicht ausdr ck lich erlaubt ist als verboten eingestuft wird Die Entscheidungsbasis liefert eine Datenbank in der die Workflows sowie die Rollen und Benutzer als relationales Schema gespe
199. ta und Kazumaro Aoki Linear Cryptanalysis of the Fast Data Enci pherment Algorithm Lecture Notes in Computer Science 839 12 16 1994 URL http citeseer ist psu edu ohta94linear html On105 Heise Online Microsofts Authentifizierungsdienst Passport nicht mehr bei eBay 2005 URL http www heise de newsticker result xhtml url newsticker meldung 54705 PB04 Maja Pusara und Carla E Brodley User re authentication via mouse movements In Pro ceedings of the 2004 ACM workshop on Visualization and data mining for computer securi ty Seiten 1 8 ACM Press 2004 URL http doi acm org 10 1145 1029208 1029210 Proa Liberty Alliance Project Liberty Alliance Developer Tutorial URL http www projectliberty org resources tutorial_draft pdf Prob Jeff Prosise DMTF Web Based Enterprise Management Initiative URL http www dmtf org standards wbem Pro85a High Availability Linux Project High Availability 1985 URL http www linux ha org Pro85b Jeff Prosise Foiling Session Hijacking Attempts 1985 URL http msdn microsoft com msdnmag issues 04 08 WickedCode Pro04 Jakarta Tomcat Project SSL Configuration HOW TO 2004 URL http jakarta apache org tomcat tomcat 4 0 doc ssl howto html PwWo02 Birgit Pfitzmann und Michael Waidner Privacy in browser based attribute exchange In WPES 02 Proceedings of the 2002 ACM workshop on Privacy in the Electronic Society Seiten 52 62 ACM Press 2002 URL http
200. te 110 e Das Wibukey Applet stellt das clientseitige Interface zur Verifikation des Wibukeys zur Verf gung Seite 112 e Die Proaktivit t implementiert durch das ProAktivApplet Seite 78 8 SPEZIFIKATION UND IMPLEMENTIERUNG 91 Trainingssuite Das Erlernen eines Workflows teilt sich in zwei Module auf e Im Webtool siehe 8 1 werden die Workflows angelegt sowie die Benutzer und Rollen Wenn ein Workflow angelegt wird und die Trai ningsphase gestartet ist e wird durch den Trainingsaspect die Interaktion des Trainers Ad ministrators mit der zu schiitzenden Software aufgezeichnet und dem Webtool zur Verf gung gestellt Aus der Trainingssuite erh lt der Trainer eine XML Datei in der alle Be nutzer inklusive ihrer Authentifikationsmerkmale sowie Rollenzugeh rigkei ten und Workflows enthalten sind Diese kann manuell nachbearbeitet und sp ter durch das Datenbanktool dem Security Aspect verf gbar gemacht werden Datenbanktool Um die in der Trainingssuite erzeugten xml Daten in die Daten bank des Security Aspects zu transferieren wird das Datenbanktool dbtool verwendet Es erzeugt eine relationale Datenbankstruktur d s Daten 8 Abbildung 26 Entwicklungsschritte Um eine Applikation zu sch tzen m ssen nun folgende Schritte durchgef hrt wer den die grob wie in Abb 26 unterteilt werden k nnen 1 Der Trainungsaspekt muss unter Hilfe des AspectJ Weavers mit der Appli kation verwoben werden Danach w
201. terung des Struts Frameworks zur Spezifikation des bertragungsprotokolls Hiermit kann angegeben werden welche Webseite bzw Action Class ber welches Protokoll bertragen werden soll Somit kann w h rend des Ablaufs einer Webapplikation zwischen reiner HTTP bertragung und SSL abgesicherter bertragung gewechselt werden Hiermit ist es m glich nicht wichtige Seiten ohne SSL Absicherung bertragen zu lassen und wichtige Seiten nur mit Absicherung durch SSL bertragen zu lassen Bei dem Identity Provider unseres Demonstrators wird die Einstiegsseite per normalem HTTP bertragen 110 und sobald es zur Ubermittlung von Authentifikationsdaten kommt wird zu SSL gewechselt sslext bernimmt dabei nicht nur die Kontrolle ob Action Klassen und JSP Seiten mit dem richtigen Protokoll aufgerufen werden sondern auch die Spezifikation der Links je nachdem ob ein Wechsel zwischen SSL abgesi chertem und normalem HTTP Protokoll stattfindet Dies ist n tig da die Links normalerweise nur relative Links in Relation zum Pfad der Webapplikation des Tomcat sind und beim Wechsel zwischen SSL und HTTP direkt die Angabe einer vollst ndigen URL n tig ist Die Integration von sslext in Struts wird durch das Austauschen des action mappings Parameter in der Datei struts config xml wie in Listing 29 dargestellt realisiert lt action mappings type org apache struts config SecureActionConfig gt Listing 29 nderungen an der struts config xml
202. tion Workflow Generator Recording test Refresh Tree Abort Recording Save Recorded Workflow Abbildung 42 Beenden einer Workflowaufzeichnung Zur Bearbeitung eines aufgezeichneten Workflows geht man oben auf den Punkt workflow editor Daraufhin werden alle bisher aufgezeichneten Work flows angezeigt und man w hlt einen aus Abbildung 43 Der Workflow wird workflow generator workflow editor role management user management Create XML Description Workflow Management test edit delete Abbildung 43 Bearbeitung der Workflows daraufhin als Ablaufdiagramm angezeigt Abbildung 44 Jeder der Knoten ent spricht einer aufgezeichneten Actionclass in unserem Falle State genannt und es ist m glich diese States anzuklicken um die Parameter angezeigt zu bekom men und eventuell zu bearbeiten Beispielhaft wird der zweite State angeklickt 9 BEISPIELABLAUF DES DEMONSTRATORS 119 workflow generator workflow editor role management user management Create XML Description Workflow Management test Ge 0 0 0 Actual State base Previous State abort Save Abbildung 44 Bearbeitung eines Workflows Abbildung 40 und die passenden Parameter werden angezeigt Abbildung 45 Hier sind die Parameter zu erkennen die der ActionClass bergeben wurden In diesem Fall FISH und andere Parameter In dieser Eingabemaske ist es m glich eine SQL Anfrage zu spezifizieren aus der der SecurityAspect den Vergleich f r d
203. tionsmerkmale wie z B Pass worte Das Format dieser erzeugten Datei wird im Kapitel 8 2 genauer vorgestellt Die Suite besteht aus Webtool und Trainingsaspect Der Aspect dient der Aufzeichnung und bermittlung der Interaktion des Benutzers mit der Wirtsap plikation Aus den aufgezeichneten Daten kann danach durch das Webtool die XML Beschreibungsdatei erzeugt werden Der Trainingsaspect wird nachtr glich in das zu sch tzende Programm hinzu gef gt und f gt in eine Speicherstruktur bei jedem Seitenaufruf die bergebenen Parameter des Benutzers ein Da diese Speicherstruktur durch beide Applika tionen also von der Wirtsapplikation und dem Webtool gemeinsam verwendet werden soll muss dies dem Tomcat explizit mitgeteilt werden Dies passiert durch die crossContext Option in der server xml wie es in Listing 17 gezeigt wird lt Context path web_tool docBase web_tool reloadable true crossContext true gt lt Context path jpetstoreTraining docBase jpetstoreTraining reloadable true crossContext true debug 10 gt Listing 17 nderungen an der server xml Ebenfalls muss die communicationInterface jar im common lib Verzeichniss des Tomcat vorhanden sein In dieser jar Datei befindet sich die Beschreibung der gemeinsam verwendeten Speicherstruktur Die Verwendung des Webtool wird in Kapitel 9 1 dargestellt In diesem Erzeugungsprozess k nnen nur serielle Workflows entstehen was durch die Verwendung der zu sch tzende
204. tity Provider zugelassen Das Applet wird au erdem signiert um einerseits die ben tigten gr eren Sicher heitsfreigaben f r das Applet von der Java Sandbox zu bekommen als auch es dem Benutzer zu erm glichen eine berpr fung durchf hren zu k nnen ob das Applet von dem richtigen Server geholt wurde Zus tzlich werden dadurch die Parameter die f r das Applet ben tigt werden nicht im Klartext bertragen In Abbildung 37 ist zusammengefasst welche Kommunikation n tig ist um ei ne Authentifikation mittels Wibu Key durchf hren zu k nnen Zwischen Identity Provider und dem Applet werden die ben tigten Daten mittels SSL abgesichert Das Applet greift auf der Client Seite ber die API auf den Wibu Key zu Die API allerdings greift nicht direkt auf den Wibu Key zu sondern auf einen Wibu Key 8 SPEZIFIKATION UND IMPLEMENTIERUNG 113 Server Dieser Server erledigt die Hardware Kommunikation mit dem Wibu Key und ist ber einen TCP Port erreichbar Hier w re zu kl ren in wieweit dieser Port des Wibu Key Servers nach aufen ge ffnet ist um nicht Angreifern von au erhalb die M glichkeit zu geben Angriffe auf den Wibu Key Server direkt t tigen zu k nnen Auf Seiten des Servers geschieht eine hnliche Kommunikati on Die Actionclass responseAction java greift auf die Java API des Wibu Keys zu um die kontrollierende Wibu Key Verschl sselung durchzuf hren Auch hier auf Seiten des Servers wird auf den Wibu Key mittels eines Wibu Key
205. tung m glicher Angriffe und Sicherheitsprobleme wird in Kapitel 7 durchgef hrt Hierbei hat sich heraus ge stellt dass der Identity Provider in diesem Konzept eine m gliche Schwachstelle darstellen kann Da durch einen denial of Service Angriff auf diesen Identity Pro vider auch alle angeschlossenen Service Provider au er Gefecht gesetzt sind ist in gro en Systemen unbedingt auf Redundanz bei den Identity Providern zu achten Das Problem des Session Hijackings durch das Stehlen von Cookies vom Browser des Benutzers ist ein weiteres m gliches gro es Problem Modularit t Es ist aber auch deutlich geworden dass die Trennung von Pro gramm und Sicherheit Probleme erzeugt da diese getrennt arbeiten Eine Ein schr nkung der Art Verkaufe keine Hunde wenn keine Hunde im Lager sind ist nicht formulierbar Diese Grenze wurde versucht aufzuweichen indem der Daten bankzustand der Wirtsapplikation mit in Betracht gezogen wird Allerdings fehlt hierbei noch eine bessere Formalisierung der Beschreibungssprache Momentan ist es nur m glich zu kontrollieren ob sich ein Parameter exakt in der Ergeb nismenge einer SQL Anfrage befindet Dies ist zu wenig als dass damit bereits Sicherheitspolicies formuliert werden k nnten 10 FAZIT UND AUSBLICK 127 Proaktivit t Die Proaktivit t wird durch ein Applet erreicht welches in jede erzeugte Webseite eingebettet wird Bei jeder Webseite muss der Browser das Applet beenden und neu starten Dies er
206. ture Notes in Computer Science Advances in Cryptology proceedings of EUROCRYPT S87 Seiten 267 278 1987 ASKP00 Gail Joon Ahn Ravi Sandhu Myong Kang und Joon Park Injecting RBAC to secure a Web based workflow system In Proceedings of the fifth ACM workshop on Role based access control Seiten 1 10 ACM Press 2000 URL http doi acm org 10 1145 344287 344295 BBF02 Roberto Barbuti Cinzia Bernardeschi und Nicoletta De Francesco Checking se curity of Java bytecode by abstract interpretation In Proceedings of the 2002 ACM symposium on Applied computing Seiten 229 236 ACM Press 2002 URL http doi acm org 10 1145 508791 508839 BDLD 03 Siddharth Bajaj Giovanni Della Libera Brendan Dixon Mike Dusche Ma ryann Hondo Matt Hur Hal Lockhart Hiroshi Maruyama Nataraj Naga ratnam Andrew Nash Hemma Prafullchandra und John Shewchuk Spe cification Web Services Federation Language WS Federation 2003 URL http www 106 ibm com developerworks webservices library ws fed 138 BDR86 BGP04 BHG87 BLFF BMo3 BN89 BS91 caf CK03 CNo2 Cor Cow01 DCW 99 DKM 97 DOTO3 Eck01 Eck03 FEO3 FK92 Bharat Bhargava John Dilley und John Riedl RAID a robust and adaptable distributed system In Proceedings of the 2nd workshop on Making distributed systems work Seiten 1 7 ACM Press 1986 URL http doi acm org 10 1145 503956 503965 Thomas B hren Volk
207. ufend das Verhalten eines Benutzers berwachen F r sicherheitsrelevate Aktionen ist ein wiederholter Nachweis der Identit t eines Benutzers w nschens wert Eck03 Kapitel 4 8 Ohne Reauthentifikationen ist das System m glichen Angriffen von Insidern ausgeliefert Es k nnte z B ein Angreifer Zugang zu einem Rechner gelangen der initial authentifiziert wurde und f r kurze Zeit unbewacht ist aber nicht ausgeloggt wurde Weiterhin gibt das einmalige Klauen eines Pass wortes einem Angreifer die M glichkeit sehr lange auf das System Zugriff zu bekommen ohne dass es bemerkt wird Viren Hackern und hnlichen Angriffen von au erhalb wird mittlerweile eine gro e Bedeutung zugeordnet und Systeme werden dementsprechend auch im mer besser abgesichert Die Angriffe die durch eine f lschlicherweiser vertrauten Person innerhalb eines Computersystems durchgef hrt werden k nnen sind da gegen zu wenig beachtet Der Schaden dagegen den eine solche Person duch den Diebstahl von geheimen Daten verrichten kann ist nach dem Computer Security Survey R W03b die teuerste Form von Computerverbrechen im Jahr 2003 Zero interaction Authentication Zur Reauthentifikation ist es schlecht ein Verfahren zu verwenden das st ndig die Interaktion des Benutzers fordert Ein solches Verfahren ist sehr aufdringlich und ermutigt den Benutzer das Verfah ren abzuschalten oder zu umgehen UN02 Eine Zero Interaction Authentication ZIO ist ein Authentifikationsv
208. und eine Kontrolle in der Tiefe durchf hren Hier gibt es verschiedene Einsatz m glichkeiten Es kann kontrolliert werden inwieweit Methoden zur Aus f hrung kommen die so sonst nicht ausgef hrt werden Auf diesem Weg k nnten sog Eastereggs in einer Software erkannt werden Es k nnte auch untersucht werden inwieweit sich die in BGP04 vorgestellten Wrapper aufsp ren lassen Es k nnte also u U eine Aussage ber die Sicherheit der JRE getroffen werden Daneben w re die M glichkeit des Caching gegeben Hiermit kann der f r den Benutzer entscheidende Seitenaufbau beschleunigt werden falls die Da ten der Webseite zu Teilen eine statische Antwort auf seine Eingaben ist Strutsbasierung Als Basis des Security Aspect haben wir das Struts Framework verwendet Es wird als Pointcut die ActionClass des Frameworks verwen det Um den Aspect f r beliebige Javaprogramme verwenden zu k nnen ist eine Ver nderung des Pointcut n tig und einige weitere Anpassungen im Sourcecode des Aspects Struts wurde gew hlt da hier die Besonderheiten der Webkommunikation versteckt werden und eine einheitliche Schnittstelle existiert Der Schritt vom Framework weg bedeutet dass ab dann statt die ser einen Methode des Frameworks drei Methoden gekapselt werden m ssen Innerhalb des Aspects wurde keine Funktionalit t von Struts verwendet so dass hier keine Probleme bei einer Portierung entstehen sollten Verifikation von Workflows Ein Workflow wird von ei
209. und einer Signatur Der Pointcut Type enth lt einen Join Point wie er weiter oben klassifiziert wird und die Signatur beschreibt die Stelle an der der Join Point angewendet werden soll Ein einfacher Pointcut kann so aussehen pointcut anchor HttpServletRequest request HttpServletResponse response within HTMLRewriterAspect amp amp execution void spService HttpServletRequest HttpServletResponse amp amp args request response Listing 4 Beispiel eines Pointcut Der in Listing 4 gezeigte Pointcut ist dem HTMLRewriter Aspekt siehe 8 7 ent nommen und selektiert jeden Aufruf der Methode die in einer Webapplikation den HTML Code erzeugt der dem Client bertragen wird Zus tzlich wird noch der Context des spezifizierten Join Points festgehalten Dies bedeutet dass in nerhalb des Advice ein Zugriff auf die Variablen besteht die auch die Methode bergeben bekommt Advice Der Advice ist der Code der zu einem bestimmten Join Point aus gef hrt werden soll Daneben kann angegegben werden zu welchem Zeitpunkt ein Aspect an den jeweiligen Join Point gebunden werden soll Dazu stehen die folgenden drei M glichkeiten zur Auswahl e Der Aspect wird vor before dem Joinpoint eingewebt 40 e Nach after dem Jointpoint wird der Aspect eingewebt e Der Aspect kapselt den Aufruf around Im Listing 5 wird ein before Advice gezeigt welcher jeweils vor dem Joint Point belowAnchor ausgef hrt wird Der after Advic
210. untHandler bergeben hat Falls ein Sub jekt direkt auf die Seiten des IDP zugreift gelangt er direkt auf die Login Seiten der Applikation Hierf r wird keinerlei Aufruf der SourcelD API durchgef hrt da sich der Benutzer nur lokal auf den Seiten des Identity Providers befindet 36 3 Aspektorientierte Programmierung Ein zweiter Baustein der in dieser Diplomarbeit verwendet wird ist die aspekt orientierte Programmierung AOP Wie im folgenden Kapitel beschrieben wird er ffnet diese Programmiertechnik v llig neue Wege in der Modularisierung von Software Die sp ter beschriebene M glichkeit ein Programm nach dessen Com pilation um Funktionalit t zu erweitern erm glicht eine starke Unabh ngigkeit in der Entwicklung eines Moduls welches die sicherheitskritischen Teile beinhaltet Ein Softwaresystem besteht aus verschiedenen Aufgaben die durch die Soft ware ausgef hrt werden sollen Hierbei kann grob zwischen Core Concerns und Crosscutting Concerns unterschieden werden Ein Core Concern enth lt die eigentliche Funktionalit t eines System wohingegen ein Crosscutting Concern sich meist um betriebssystemnahe Aufgaben oder IO k mmert Als ein Beispiel kann die Loggingproblematik gesehen werden Abbildung 9 Einsatz von Logging im Tomcat Die Aufgabe die sich stellt ist Verzeichne jeden Zugriff auf eine Methode und schreibe dies in eine Datei Diese an sich einfache Au
211. urch eine Konfigurationsm glichkeit angepasst werden kann um eine gr tm gliche Wiederverwendbarkeit zu errei chen Die in dieser Diplomarbeit vorgestellte L sung wird in den weiteren Kapiteln dargestellt Einen berblick gibt folgende kurze Zusammenfassung der Kapitel 12 Aufbau der Diplomarbeit Die Diplomarbeit teilt sich in zwei Abschnitte ein In den Kapiteln 1 bis 6 werden die Grundlagen erl utert auf deren Basis ein Sicherheitsmodell entwickelt wird Dieses Modell wird in den Kapiteln 7 bis 10 entwickelt Im Folgenden werden die Kapitel dieser Arbeit vorgestellt Im Kapitel 2 wird ein berblick gegeben ber verteilte Authentifikationstech niken im Internetbereich In diesem Rahmen werden verschiedene Single Sign On Protokolle betrachtet Kapitel 3 besch ftigt sich mit der verwendeten Programmiersprache Java und einer Erweiterung des Sprachkonzepts mit deren Hilfe eine st rkere Modularisie rung erm glicht werden soll Danach wird in Kapitel 4 der zentrale Begriff des Referenzmonitors eingef hrt und verschiedene Implementationsvarianten vorgestellt und der Einsatz einer rol lenbasierenden Zugriffskontrolle motiviert Es folgt in Kapitel 5 eine Vorstellung von verschiedenen Authentifikationsme chanismen die im Bereich des Internet verwendbar sind In Kapitel 6 werden die Voraussetzungen f r einen sicheren Betrieb eines Dienstes im Internet er rtert Au erdem wird betrachtet wie die durch unter schiedliche Ma nah
212. utzer das Recht hat auf eine Ressource zuzugreifen und e das User Management durch das die Benutzerinformationen angelegt und verwaltet werden Neben der Definition des Identity Management ber die ben tigte Infrastruktur kann versucht werden dies ber verschiedene Sichtweisen zu tun Hier werden in Vog04 von M Vogel folgende erw hnt User Administratorsicht Dies ist die Unterscheidung zwischen Endanwender und Administrator Der Endanwender ist an einem einfachen Zugang inter essiert Der Administrator legt auf eine schnelle und einfache Verwaltung der Benutzer und deren Rechte Wert Insider Outsidersicht Ein Insider ist ein Mitarbeiter f r den korrekte Iden tit tsdaten vorliegen m ssen Ein Outsider stellt den Kunden oder Partner einer Firma dar Deren Identit tsdaten unterliegen oft nicht so strengen Kriterien da diese h ufig durch Selbstregistrierungen der Kunden erlangt werden Prozesssicht Es wird zwischen dem User Access und dem User Lifecycle Mana gement unterschieden Der UserAccess behandelt die Autorisation Authen tifikation und Session Management Im User Lifecycle Management werden die administrativen T tigkeiten die sich auf Userdaten beziehen erfasst Weiter wird in Vog04 auf die Folgen des Fehlens eines durchg ngigen Identity Managements hingewiesen Als Hauptrisiken werden e Produktivit tsverlust e Sicherheitsrisiken und e Nichterf llung gesetzlicher Auflagen oder Vorschriften genannt Som
213. vider geholt und lokal auf dem Client Rechner innerhalb des Browsers ausgefiihrt 8 SPEZIFIKATION UND IMPLEMENTIERUNG 111 Das Authentifikationsverfahren mit dem Wibu Key wird nach dem im Kapitel 5 3 beschriebenen Verfahren durchgefiihrt Dem Applet werden die Para meter Firm Code User Code Salt und RAND mitgegeben Der Salt Wert wird dem Wibu Key als Selection Code in den Verschliisselungsalgorithmus tibergeben und dient dazu die Zufalligkeit zu erh hen Der RAND Parameter entspricht den Daten die mit Hilfe des Keys verschl sselt werden sollen Das aus der Verschliis selung mit dem Wibu Key erhaltene Ergebnis schickt das Applet ber eine Wei terleitung des Browsers an die Klasse responseAction java des Identity Providers zurtick Ein Beispielablauf ist in Abbildung 36 dargestellt und wird im folgenden Browser Service Provider Identity Provider T T _1 HTTP Anfrage auf Wibukey geschuetztem Bereich 2 Weiterleitung zum IDP AuthnContext 3 Weiterleitetung zum IDP i j S AuthnContext i 4 Rands erzeugen 5 Salt Rand i K f 6 Verschluesselung mit Wibukey i 7 Antwort i g 8 Verschluesselung mit Wibukey Ergebnisse vergleichen 9 Weiterleitung zum SP AuthnContext La 10 Weiterleitung zum SP AuthnContext gt 11 Nachfragen beim IDP 12 Antwort vom IDP i a 13 Webseite ge
214. zen S TT 27 such that S a N S b H and a b TT EP explicit permissions OP x TT IP implicit permissions OP x TI P set of permissions EP U IP EPA explicit assigned permissions C R x EP IPA implicit assigned permissions derived from EPA IPA ri execute ti 3 t execute t EPA At S t PA EPAUIPA Permission Assignment permissions R 2 jeder Rolle r wird eine Menge von Rechten zu geordnet permissions R 2 erweiterte Relation um Rollenhirarchie permissions r execute t ltr execute t EPA At permissions r execute t dr lt r r execute t EPA A t S t R Sandhu und S Kandala stellen in fest K502 dass diese Definition noch den Nachteil hat dass ein Task nicht notwendigerweise beendet wird Somit be steht keine Beschr nkung wie oft ein Task ausgef hrt wird Um diesem Problem gerecht zu werden f hrt Sandhu den Begriff der Zust nde eines Tasks ein Fiir jeden Zustand innerhalb eines Tasks gibt es zwei m gliche Operationen abort oder commit Fiir den Startzustand gibt es jedoch nur eine Operation die moglich ist execute Dies fiihrt den Task in den Executing Zustand wie in Abbildung 19 dargestellt execute Abbildung 19 Task Struktur Ein abort fiihrt in einen Fehlerzustand und von dort wieder zur ck in den Startzustand Commit f hrt den Task in einen neuen g ltigen Zustand Um
215. zeugt unn tigen Datentransfer da bei jeder bertragung einer Webseite auch das Applet bertragen werden muss Falls der Browser die Java Applets zwischenspeichert f llt die Verz gerung aufgrund der bertragungszeiten wesentlich geringer aus Daneben wird f r das Beenden und Neustarten Rechenleistung auf der Clientseite verbraucht Diese Probleme m ssen bei einer Implementierung des Systems in stark frequentierten Systemen in Betracht gezogen werden Da ein Benutzer gleichzeitig oder nacheinander mit Webseiten mehrerer Ser vice Provider arbeiten kann die Applikation kann z B zum Lastausgleich auf mehrere Server verteilt sein muss das Applet in jede Seite die generiert wird ein gebettet werden Nur dann kann kontinuierlich berpr ft werden ob der Benutzer an seinem PC ist Die Einbindung des Applets in den HTML Quellcode jeder erzeugten Webseite ist nur eine M glichkeit eine kontinuierliche berwachung des Benutzers zu errei chen Falls es m glich ist ein Programm auf dem Rechner des Clients zu starten das Zugriff auf die Aktivit t des Benutzers hat und dauerhaft ausgef hrt werden kann muss dies nicht ber ein wiederholt gestartetes Applet geschehen Da der Demonstrator speziell auf ein Nachr sten einer bestehenden Web Applikation ausgerichtet ist ist es in diesem Kontext nicht m glich ein Programm au erhalb des Browsers laufen zu lassen Identity Management Die Authentifikation im Demonstrator kann ber eine Komb

Diplomarbeit Sicheres Outsourcing mit verteilten Webservices

Contents

Download Pdf Manuals

Related Search

Related Contents