[CORBA, java] Security model

[Infinitive]

Ik ben momenteen een beetje aan het stoeien met de default CORBA implementatie in Java (1.4.2). Aan de server-side wordt de standaard ORB die bij java zit gebruikt en het serverproces is zelf geschreven in java. Als clients gebruik ik zowel een java-client als een c++ client.

Nu wil ik een client een eigen privé-remote object geven. De meest voor de hand liggende manier is om een well known remote object te maken die een methode heeft dat dergelijke privé remote objects returned. Zolang de clients de IOR niet uitwisselen, dan blijft dat wel een privé object. Alleen is er een probleem: in hoeverre is een IOR te raden? Zijn identifiers voor objecten een sequentieel nummer zodat je gewoon wat kan proberen, of zit er een random deel in verwerkt. En zo ja, zijn er dan voorzieningen tegen brute forcers? Allemaal vragen waarop ik geen antwoord kan vinden.

Toch lijkt me dat een dergelijke situatie wel vaker voorkomt. Als ik geen aanname kan doen op het gokken van IORs, dan is het eerst volgende wat ik kan doen het bekijken van het security model in CORBA. Want in principe is het probleem ook opgelost als je een client kan authenticeren en dan via een access control list de toegang tot de prive objecten regelt. Alleen heb ik hiermee het probleem dat ik niets maar dan ook niets van security level 1 en 2 in de corba packages van java kan terugvinden. Ik begin het vermoeden te krijgen dat corba security niet in de standaard corba implementatie zit?

In principe heb ik wel een sluitende oplossing voor het probleem. Ik zorg zelf voor een secret token en voeg deze als extra parameter toe aan elke methode die ik wil aanroepen. Dan voeg ik aan elke methode een check toe op deze parameter. Code duplicatie server-side zou ik wel kunnen voorkomen door de checks via AspectJ in te voegen, maar iedereen is vast wel met me eens dat dit geen mooie oplossing is en er vast wel een betere manier moet zijn.

Heeft iemand een idee? Of verwijzingen naar bepaalde literatuur? Ik moet erbij zeggen dat ik zelf weinig soeps online kan vinden. Of ik eindig in de corba specificatie waar ik geen wijs uit kan worden, of ik kom op een of ander site-je waarin een alineatje text staat, of ik kom op een site van een commerciele orb, wat zo wie zo afwijkt van wat in java zit. In de Java Corba tutorial wordt geen woord gesproken over security.

[Sammy]

Ik worstel momenteel met hetzelfde probleem en heb eigenlijk ook dezelfde oplossing gekozen. Nu is het overigens zo dat de IOR allerhande gegevens bevat, niet alleen IP-adres maar ook dingen als het pad naar de POA waarin het object zich bevindt. Als je je private objecten aanmaakt in een POA die als policy system-id heeft (en dat heeft de rootPOA standaard), dan wordt het raden eigenlijk onmogelijk. Maar ik ben het met je eens, 'eigenlijk onmogelijk' is niet genoeg.

[Infinitive]

Met de system-id policy kent toch de POA zelf IDs toe? Maar als dit sequenciele ids zijn, dan is een ID van een ander object eenvoudig te raden. Misschien dat als je user-id policy gebruikt, dat je zelf random IDs kan toewijzen, maar nog steeds ben je vatbaar voor brute-forcen, tenzij je IDs uit genoeg bits bestaan. Bovendien zou je ORB ook flootprotectie moeten hebben, maar dat zou je eventueel wel via een firewall kunnen regelen.

[Soultaker]

De ORB garandeert je nooit goede random object identifiers (want dat is het variabele deel van de IOR). Als je dat wil, moet je zelf je object identifiers genereren. Maar dat is natuurlijk een beetje een oplossing die vergelijken is met het maken van een 'beveiligde' website waarbij de 'geheime' inhoud in http://server/geheimeurl/ bewaart wordt.

De beste oplossing is misschien de standaard security API van CORBA te gebruiken, waarmee je per object kunt specificeren welke client er toegang toe heeft. Als Java geen CORBA Security ondersteunt (ik geloof dat de ORB in Java nogal beperkt is) of als je die oplossing te rigoreus vindt (omdat je dan bijvoorbeeld ook alle requests over SSL moet doen) dan kun je eventueel zelf een security systeem bouwen met behulp van een Interceptor, dan zou je zelf de requests kunnen screenen als ze binnenkomen (maar ik geloof niet dat er een portable specificatie is van wat voor informatie er over de client beschikbaar is, omdat dat nogal afhangt van het gebruikte transport en proxies enzo).

edit:
Oh, ik zie dat je zelf ook al naar CORBA Security had zitten kijken. Die zal er dan wel niet inzitten.

Anders misschien op zoek naar een alternatieve Java ORB die wel level 2 security ondersteunt? (JacORB?)

[ Voor 11% gewijzigd door Soultaker op 02-04-2005 16:26 ]

[Infinitive]

Ah, ik heb de naam PICurrent al een aantal keren voorbij zien komen. Ik zal er eens verder naar kijken. In principe zou ik zelf het liefst voor CORBA Security gaan omdat het er niet voor niets is

Ik wilde eigenlijk voorkomen om alternatieve ORBs te gebruiken. Ik heb echter via een lieve P&Wer het boek "Developing Secure Distributed Systems with CORBA" weten te bemachtigen, dus als daar CORBA Security een beetje duidelijk in uitgelegd wordt, dan denk ik dat ik toch maar wat tijd moet steken in het zoeken naar een goede ORB.

[Soultaker]

Het idee van CORBA met language mapping is dat je in principe van ORB kunt wisselen zonder dat je je code hoeft te wijzigen. In de praktijk moet je vast nog wel een aantal dingen aanpassen, maar de hoeveelheid werk valt meestal erg mee. (Voor C/C++ projecten hoef ik meestal alleen wat makefiles aan te passen, zodat andere libraries en headerfiles gebruikt worden.)

Natuurlijk is het niet de definitieve oplossing, maar het zou makkelijker kunnen zijn dan je eigen security implementeren. De vraag is een beetje hoeveel informatie je met portable interceptors ter beschikking hebt. Ik heb zelf alleen ervaring met interceptors in omniORB en dan heb je wel beschikking over IP-adressen enzo, maar dat was al voordat die portable interceptors geïmplementeerd waren, dus dat zal niet platformonafhankelijk zijn geweest.

[Infinitive]

Ik heb uiteindelijk besloten om toch de Portable Interceptors te gebruiken, het gebruik van de Security service van CORBA blijkt voor mijn doeleinde toch teveel overkill. Met Portable Interceptors kan ik nog gewoon de ORB gebruiken die in java zit.

Ik heb het op een vrij simpele manier opgelost. Toch is het resultaat niet eens onaardig: op wat initiele administratie na, hoef ik alleen op de plaatsen in de servercode waar ik een instantie van een remote object aanmaak (servant_to_reference) een extra methode aan te roepen.

De oplossing zit ongeveer als volgt in elkaar: de client logt in en krijgt een secret token van de server. Bij elke request zal de client dit token meesturen doordat de request interceptor aan de client side dit als een context-parameter toevoegt aan een request. Zodra voor een gegeven client een "privé object" wordt opgeleverd, wordt het paar (object-id, token) bij de server bijgehouden. De request interceptor van de server checkt van elke request of er een dergelijk paar opgeslagen is, zo ja, dan worden de tokens vergeleken. In het geval dat deze niet kloppen, wordt een exception gegooid; eventueel zou hier op herhaaldelijk misbruik gecheckt kunnen worden. Door middel van een weak-reference naar de daadwerkelijke instantie van het remote-object, zorg ik ervoor dat die token-paartjes ook weer opgeruimd worden (eigenlijk was dit meer iets voor een finalizer, maar omdat java geen multiple inheritance ondersteund, kon ik dat niet regelen omdat de servants al een automatisch gegenereerde class extenden).

Soultaker, iig bedankt voor die hint naar de Portable Interceptors. Ik was ze in de Java API al wel tegengekomen, maar zonder voorbeeldje is het toch lastig om aan voldoende informatie te komen. Vooral omdat die mini-tutorial bij het IDL spul op de sun website staat. Daar had ik het nooit gevonden

[ Voor 11% gewijzigd door Infinitive op 06-04-2005 18:32 ]