Umgehung und Aufhebung der Einschränkungen

Da der SecurityManager auf Browser-Seite die oben angegebenen Regeln für aus dem Netz geladene Applets bestimmt, ist es ihm möglich, die Einschränkungen individuell zu lockern. Dies macht etwa dann Sinn, wenn ein Applet von einer vertrauenswürdigen Organisation oder aus einem Intranet stammt.
Wie wird aber die Unterscheidung zwischen vertrauenswürdigen und nicht vertrauenswürdigen Applets vorgenommen? Das Verfahren bedient sich des in 2.2.2 vorgestellten Public-Key-Mechanismus': Zunächst wird der Applet-Bytecode oder ein jar-Archiv von seinem Erzeuger mittels eines privaten Schlüssels signiert. Daraufhin wird der zugehörige öffentliche Schlüssel einer vertrauenswürdigen Organisation (einer Certficate Authority, CA) übergeben, die nach hinreichender Überprüfung den Schlüssel unter dem Namen des Erzeugers speichert und auf Anfrage zugänglich macht. Vertraut man nun der CA, bzw. ist man der Meinung, sie bei Inkorrektheit der gelieferten Information rechtlich belangen zu können, so kann man sicher sein, daß der Code von dem angegebenen Erzeuger stammt. Vertraut man nun auch diesem Erzeuger, so kann man seinem Browser erlauben, Applets dieser Herkunft - einmalig oder dauerhaft - zusätzliche Privilegien einzuräumen. Genaues dazu findet sich unter [Net]. Da die Verteilung dieser Privilegien äußerst feinkörnig ist, besteht auch die Möglichkeit, einem Applet ``ein wenig'' zu vertrauen, ihm also z.B. lediglich lesenden Datei-Zugriff einzuräumen.
In dem für unsere Betrachtungen interessanten Spezialfall des CORBA-Applets auf einer WWW-Seite ergibt sich noch eine weitere Möglichkeit, zumindest Zugriffe auf andere Server zu tätigen: Der Ursprungsserver fungiert als Proxyserver für IIOP-Requests. Dazu im folgenden Unterkapitel mehr.