Da CORBA Services häufig durch ein Fremdprodukt, das nicht im Quelltext vorliegt, realisiert werden, ist der in Abschnitt 6.7.2 benutzte Weg des direkten Einbaus der Autorisierung in die Java-Methoden, welche die CORBA-Funktionen implementieren, ausgeschlossen. Außerdem verhindern Quelltextmodifikationen die generelle Austauschbarkeit verschiedener Implementierungen, wie sie durch die CORBA-Standards eigentlich möglich wären.
Da gängige Produkte entsprechende Schnittstellen zur Autorisierung nicht bereitstellen, müssen für diese Fälle dann spezielle Security-Proxy-Objekte implementiert werden. Diese werden dann den CORBA-Schnittstellen des ursprünglichen Services ``vorgeschalten'' und ersetzen so dessen CORBA-Funktionen durch eigene, in denen Authentisierung und Autorisierung vorgenommen werden, um schließlich, falls beide Schritte erfolgreich waren, die korrespondierenden Funktionen des eigentlichen CORBA-Services aufzurufen.
Ebenso ist häufig die zu verwendende ORB-Instanz vorgegeben, die dann nicht SSL-fähig ist. Durch den Einsatz von Security-Proxy-Objekten wird diesem Problem ebenfalls begegnet, indem diese eine SSL-fähige ORB Instanz benutzen, die dann wiederum die nicht-SSL fähige Implementierung des Services benutzen. Dabei muß beachtet werden, daß der Kanal zwischen Security-Proxy-Objekt und CORBA-Service sicher ist, was sich dadurch realisieren läßt, daß beide in einer gemeinsamen JVM ablaufen, und somit der Kanal ein Java-Methodenaufruf ist, und damit sicher ist.