15.1.3 | Historische Entwicklung der Sicherheitsmodelle |
In der Entwicklung Vom JDK 1.0 bis zum JDK 1.2 gab es einige Änderungen in punkto Sicherheit. Das Sicherheitsmodell des JDK 1.0 war noch vom Alles-oder-nichts-Prinzip geprägt. Das heißt, eine Java-Anwendung hatte entweder alle Berechtigungen oder überhaupt keine. Zu welcher Kategorie eine Anwendung gehörte, hing primär davon ab, ob sie als Applet oder Applikation lief. Bei Applets musste man zusätzlich zwischen Applets auf der lokalen Platte und Applets im Netzwerk unterscheiden.
Dieses Modell erwies sich als äußerst unflexibel. Es war z. B. nicht möglich, Applets im Netzwerk erweiterte Berechtigunen zuzuteilen, was z. B. im Intranet Sinn machen würde. Um diesen Schwachpunkt zu beheben, wurden mit dem JDK 1.1 signierte Applets eingeführt. Der Programmierer hat hierdurch die Möglichkeit, seine Applets mit einer digitalen Unterschrift zu versehen. Applets mit einer bestimmten digitalen Unterschrift kann man dadurch dieselben Berechtigungen einräumen wie einer Stand-alone-Anwendung.
Das Modell des JDK 1.1 erlaubte es damit zwar, signierten Applets weitere Berechtigungen zu erteilen, die Zuteilung erfolgte aber dennoch binär. Entweder hatte das Applet alle Berechtigungen oder überhaupt keine. Dieses Problem wurde erst mit dem in JDK 1.2 eingeführten Sicherheitsmodell behoben, dessen Konzept auf Berechtigungen und der Herkunkft des Codes beruht.
In diesem Modell ist es möglich, Applets entweder nach Herkunftsort (Codebase) oder nach Urheber (Signierer) differenziertere Berechtigungen zuzuteilen. Dadurch kann man einem Applet beispielsweise den Zugriff auf ein ganz bestimmtes Verzeichnis gestatten, aber Zugriffe auf den Rest des Dateisystems zu verwehren. In Version 1.4 wurde mit der Einführung des Java Authentication and Authorization Service (JAAS) die Möglichkeit geschaffen, eine Benutzerkennung als drittes Kriterium für die Zuteilung von Berechtigungen zu nutzen. Insgesamt ist man mit diesem Modell nun in der Lage, Berechtigungen sehr gezielt zu vergeben.