3 Webservices: ichain

Internet, Intranet & Webservices

9/3 Webservices: iChain 9/3.1 Inleiding Novell Portal Services is een geweldig platform om tal van verschillende webservices aan te bieden aan gebruikers. De nadruk van portalservices ligt op het aanbieden van die diensten. Als de portalservice alleen wordt gebruikt als een mooi vormgegeven pagina met links (of eigenlijk de inhoud van publiek toegankelijke webpagina’s) is de functionaliteit ervan voldoende. Als er echter ook toegang moet worden verleend tot interne databases of applicaties die geen onderdeel uitmaken van de eDirectory tree óf als er bronnen moeten worden gebruikt van (bijvoorbeeld) leveranciers – waarvoor authenticatie noodzakelijk is – wordt de gebruiker in het algemeen steeds geconfronteerd met de noodzaak om verschillende malen in te loggen.

Novell Netwerkoplossingen, aanvulling 5

9/3.1-1

Webservices: iChain

Natuurlijk kunt u aan uw gebruikers wel uitleggen dat u niet in staat bent om de wachtwoordverificatie voor de site van bijvoorbeeld Novell of Amazon te regelen. Maar lastig is het wel. En bovendien onnodig. Want met de implementatie van iChain is het mogelijk om uw gebruikers een echte 'single sign-on'-ervaring te geven binnen uw portal. Naar welke site uw gebruikers dan ook willen gaan en ongeacht op welke webserver de site dan ook draait, één keer inloggen is voldoende. Een bijkomend voordeel van iChain is dat het tevens een internet cache appliance betreft, waardoor de toegang tot de websites ook nog eens tot maximaal tachtig procent kan worden versneld.

9/3.1-2



9/3.2

Installatie

Het product iChain kan op een aantal manieren worden aangeschaft. Als VLA- of MLA-klant via Novell zelf, maar ook rechtstreeks via Compaq, Dell of IBM. Deze leveranciers bieden iChain namelijk als een black box cache appliance aan, met hun eigen logo in het managerscherm.

Gecertificeerde hardware

Tot en met versie 2.0 van iChain kon het product alleen op gecertificeerde hardware worden geïnstalleerd. Versie 2.1 doet hier gelukkig minder 'moeilijk' over. Op de productpagina van iChain (www.novell.com/products/ichain) is een lijst met gecertificeerde hardware te vinden, maar feitelijk kan alle hardware die dienst doet voor een NetWare 5.1server worden gebruikt. iChain 2.1 is namelijk opgebouwd rond de kern van NetWare 5.1. De minimale hoeveelheid geheugen is 256 Mb. Hiermee kan ongeveer 18 Gb aan cache worden opgebouwd. Verder heeft iChain minimaal een Pentium III processor nodig. Ook hier geldt: hoe meer geheugen, hoe beter het systeem zal draaien. De installatie van iChain verloopt vrijwel geheel vanzelf. Als u gecertificeerde hardware gebruikt, dient u alleen bij de licentieovereenkomst eenmaal akkoord te geven. Verder loopt de installatie volledig automatisch.


9/3.2-1

Webservices: iChain

Bij gebruik van niet-gecertificeerde hardware kan het voorkomen dat de installatie staat te wachten op input (bijvoorbeeld als u een 3c90x netwerkkaart gebruikt, vraagt de installatie welke driver gebruikt moet worden). Bij de installatie van iChain is het scherm echter gelockt, waardoor het niet mogelijk is deze vraag te beantwoorden. Via de debugger lukt het echter wel de locking van het scherm op te lossen. Ga de debugger in door middel van de toetscombinatie SHIFT+SHIFT+ALT+ESC en voer de volgende handelingen uit (let er op dat de commando’s case sensitive zijn!):

9/3.2-2



Hiermee is de screenlock opgeheven en kunt u bekijken op welke module de installatie is blijven hangen en dit (zo mogelijk) oplossen. Tip Gebruik de debugger niet zomaar in een willekeurige productieomgeving, alle processen worden namelijk tijdelijk gestopt! Het is natuurlijk beter om gecertificeerde hardware te gebruiken – zodat u deze handelingen voorkomt – maar het is via deze 'truc' wel veel eenvoudiger geworden om (bijvoorbeeld) een testinstallatie uit te voeren. Na de installatie zal de server een reboot uitvoeren en dan met een gelockt console opnieuw opstarten. Een van de eerste zaken die zal moeten worden aangepast, is het IPadres dat iChain gebruikt. Het unlocken van het console gebeurt door het UNLOCK-commando. Bij een schone installatie van iChain heeft iChain nog geen password, dus kan het password gewoon leeg worden gelaten. Geef hierna het commando: set eth0 address=ipaddress,mask=subnet. Toets vervolgens het commando apply en reboot. Om het IP-adres van de iChain-server op 172.25.0.1 te zetten, worden dus de volgende commando’s gegeven: Type: unlock Type: ENTER

(geen password)

Type: set eth0 address=172.25.0.1,mask= 255.255.0.0 Type: apply Type: reboot


9/3.2-3

Webservices: iChain

Indien security een belangrijk punt is, kan het unlocken van het console voor de toekomst wel worden beveiligd met een password. Gebruik hiervoor het commando: set password=password,user=config.

Let erop dat dit het exacte commando is. Als bijvoorbeeld de komma tussen password en user wordt vergeten, is het password niet meer te achterhalen.

9/3.2-4



9/3.3

Portal Services en toegang tot externe data

In de naam Portal Services zit het woord portaal al opgesloten. De naamgeving is daarmee goed gekozen, want deze wijst precies op de taak van Portal Services. Portal Services zorgen ervoor dat web-based informatie op een consistente manier wordt aangeboden aan gebruikers. De oorsprong van de informatie is daarin van ondergeschikt belang. De gadgets die worden geïnstalleerd binnen de portal zorgen ervoor dat gegevens vanuit verschillende bronnen worden samengevoegd tot een punt van informatie.

Twee redenen voor authenticatie

Veel van de informatie is gelukkig ook vrij toegankelijk. De Portal Services-software heeft dan ook geen enkel probleem om deze informatie te benaderen en vanuit de uniforme portal aan te bieden. Een groter probleem vormen databronnen die wel authenticatie nodig hebben. Organisaties kunnen feitelijk twee redenen hebben om ervoor te kiezen om gegevens alleen na authenticatie beschikbaar te maken. Namelijk: • als het om vertrouwelijke informatie gaat; • als er moet worden betaald voor de informatie. Als de bronnen van binnen de eigen organisatie komen, is er vaak wel een manier om de authenticatie eenvoudig te houden. Door bijvoorbeeld altijd dezelfde username/password te hanteren of door de applicatie directory enabled te maken – waardoor een single sign-on binnen eDirectory mogelijk wordt. Als de bronnen echter van buiten de organisatie komen, wordt het lastiger. Iedere aanbieder/website heeft eigen wensen en gedachten als het gaat om authenticatie. Afgezien van de vraag of het wenselijk is om voor alle websites dezelfde username/password-combina-


9/3.3-1

Webservices: iChain

tie te gebruiken (denk aan de kans dat uw username en password bekend worden) is het vaak ook onmogelijk. Een voorbeeld: bepaalde leveranciers eisen bijvoorbeeld minimaal 8 karakters in een wachtwoord of hebben het loginid piet.janssen al aan iemand anders verstrekt.

9/3.3-2



9/3.4

iChain: accelerate, authorate & authenticate

iChain is voornamelijk bekend als een zeer snelle reverse proxy-server (accelerate). Dit betekent dat het als een front-end tussen de feitelijke webserver en de gebruiker wordt gezet. Doordat iChain de statische informatie, zoals teksten en plaatjes, van de webserver zo veel mogelijk cached, zal de webserver minder zwaar worden belast, waardoor de dynamische informatie sneller kan worden getoond. Authorate slaat op de mogelijkheid van iChain om toegang tot (bepaalde delen) van de sites die worden aangeboden, te beschermen. Hierdoor is het niet langer noodzakelijk om deze configuraties op de webserver zelf te doen. Dit lijkt onlogisch, maar als u erbij stilstaat dat niet alle webservices hun security informatie uit eDirectory kunnen halen, begrijpt u dat het eigenlijk veel logischer is om dit centraal te doen. Hierdoor wordt de bescherming van webbronnen veel inzichtelijker: alle informatie wordt vanuit het security framework van iChain beschermd, ongeacht of dit nu een IIS-, Netscape- of Apache-webserver is. Hoewel ook de authorate-insteek van iChain goed kan worden gebruikt in combinatie met Portal Services, zal de nadruk in dit hoofdstuk liggen op de mogelijkheden die iChain biedt op het gebied van authentication. iChain maakt het namelijk mogelijk om toegang te krijgen tot iedere willekeurige webserver door gebruik te maken van gegevens die opgeslagen worden in eDirectory.


9/3.4-1

Webservices: iChain

9/3.4-2



9/3.5 Configuratie Voor deze demonstratie wordt gebruikgemaakt van een secure netwerk 172.25.0.0/16 en een publiek toegankelijk netwerk 10.0.0.0/8. Vanaf het private netwerk moet het mogelijk zijn om via de iChain-configuratie een GroupWise-webaccess-systeem te benaderen waarbij iChain de authenticatie uitvoert. Als LDAP-server (dit is waar iChain de userinformatie van leest en opslaat) wordt 10.10.10.10 gebruikt. Om te beginnen wordt ervoor gezorgd dat de eerste netwerkkaart in het private netwerk wordt geconfigureerd en de tweede in het publieke netwerk. Dit gebeurt door het uitvoeren van de commando’s zoals al eerder beschreven: Type: unlock Type: ENTER

(geen password)

Type: set eth0 address=172.25.0.1,mask= 255.255.0.0 Type: set eth1 address=10.10.10.5,mask= 255.0.0.0 Type: apply Type: reboot

Na de reboot is het mogelijk om via een webbrowser het configuratiescherm te bereiken. Dit kan gedaan worden op de private interface met het volgende commando: http://172.25.0.1:1959/appliance/config.html. Om de noodzakelijke veiligheid te kunnen garanderen, wordt er omgeschakeld naar een https-verbinding. Hiervoor dient een certificaat te worden geaccepteerd (eventueel kan deze aan de lijst met geldige certificaten worden toegevoegd). Hierna wordt de Java-applet gestart


9/3.5-1

Webservices: iChain

waarin de configuratie wordt uitgevoerd. Dit begint met het inloggen op de applicatie. Als er nog geen password aan de config-user is toegekend, kan hier simpel door het klikken op OK worden doorgegaan, anders moet het hierboven ingevoerde wachtwoord ingegeven worden.

De eerste taak die we uit gaan voeren in de administratietool, is het controleren en configureren van de netwerkadapters. Deze configuratie vindt u bij de button 'network' en dan het tabblad 'ip addresses'.

9/3.5-2



Multi-homing

Behalve dat de juiste IP-adressen hier kunnen worden ingesteld, kan ook een secondary IP-adres worden gekoppeld aan de adapter. Voor deze configuratie wordt 172.25.0.2 toegevoegd aan de netwerkadapter op het lokale netwerk. Voor iedere webserver die we willen gaan aanbieden via de iChain-server zullen we normaal gesproken een eigen (secondary IP-address) toevoegen. iChain kan ook gebruikmaken van multi-homing (meerdere sites met hetzelfde adres) en van niet-standaardpoorten (alleen poorten 80 voor http-verkeer en 443 voor https-verkeer worden normaal gesproken gebruikt voor websites). Selecteer het subnet waarop u het secondary IP-adres wilt configureren en kies dan voor de optie 'add address'. Vergeet niet deze aanpassingen via de apply-button veilig te stellen. De tweede taak in de voorbereiding is het configureren van de LDAP-koppeling. In dit geval wordt de koppeling gemaakt naar een NetWare-server, maar het mag iedere directory-server zijn die via LDAP informatie kan geven. De configuratie van LDAP wordt gedaan door in de linkerkant van het scherm te kiezen voor 'configure' en daarna het tweede tabblad te kiezen ('authentication'). Op dit moment is er nog geen authentication profile beschikbaar. iChain kan voor verschillende proxy’s ook verschillende authenticatiemechanismen gebruiken. Configureren van een authenticatie profile gebeurt via de 'insert'-button.


9/3.5-3

Webservices: iChain

Voor dit hoofdstuk configureren we alleen een LDAPauthenticatie. Zoals op de screenshot op de volgende pagina is te zien, is het echter ook mogelijk om een SSLcertificate of een radius-authenticatieprofiel aan te maken. Bij de koppeling met een bepaalde proxy is het mogelijk om ofwel een van de authenticatieprofielen te gebruiken, ofwel een combinatie van profielen te verlangen.

9/3.5-4



Voor LDAP-authenticatie is het noodzakelijk om het adres van een LDAP-server aan te geven, de poort waarover moet worden gecommuniceerd en (eventueel) username en password. Omdat deze LDAP-server niet publiek toegankelijk is, wordt er geen gebruikgemaakt van secure access of een user-authenticatie. Tevens wordt bij LDAP login name informatie aangegeven dat een DN (distinghuised name) wordt gebruikt en dat gebruikers in de context ou=users,o=ddirks moeten worden gezocht. Let er op dat we een connectie maken via LDAP en dat de syntax dus ook moet voldoen aan LDAP. Dit betekent het gebruik van komma’s in plaats van punten en verplicht gebruik van objecttype aanduiding (cn=, ou=, o=).


9/3.5-5

Webservices: iChain

Na het gereedmaken van de iChain-server en het authenticatieprofiel kunnen we een proxy toevoegen die (in dit geval) wijst naar de webaccess-server. Dit wordt gedaan door vanuit de proxy-server configuratie tool te kiezen voor de button 'configure' aan de linkerzijde van het scherm. Het volgende scherm wordt nu getoond:

9/3.5-6



In dit scherm vind de feitelijke configuratie van de proxyserver plaats. De hele rechterkolom geeft aan welk adres en welke poort van de originele webserver (212. 129.213.998:443) met welk IP-adres van de iChain-server moet worden gekoppeld (in dit geval 172.25.0.2:80). De 'name' die gegeven wordt, wordt alleen gebruikt om later gemakkelijk de juiste proxy terug te kunnen vinden in het configuratiescherm. Een waarde die wel belangrijk is, is de 'DNS name'. Dit is de naam waarop de proxy reageert. iChain kan namelijk zo worden geconfigureerd dat er meer dan een webserver gebruik kan maken van hetzelfde IPadres op de proxy-server. De iChain-server 'kijkt' dan in de URL die wordt gebruikt en kan aan de hand van de DNSnaam dan beslissen welke proxy gebruikt moet worden.


9/3.5-7

Webservices: iChain

Het 'cookie domain' wordt gebruikt voor een deel van de single sign-on. Deze informatie slaat de iChain-server namelijk op in een session-cookie, wat ervoor zorgt dat als u naar een tweede site in hetzelfde domein wilt (waarvoor u opnieuw zou moeten authenticeren) de informatie die u al ingegeven hebt, wordt gebruikt. Tweede hostname

Eventueel kan een tweede hostname worden opgegeven die ook voor deze proxy gebruikt kan worden. Dit is met name zinvol als er consolidatie van webservers plaatsvindt, waarbij verschillende servers uiteindelijk op één webserver komen. De optie 'return error …' zorgt ervoor dat als mensen een verbinding proberen te maken op basis van het IPadres of een niet-officiële naam, ze een foutmelding terugkrijgen. Dit kan onder andere gebruikt worden om het zogenaamde deep linken tegen te gaan. Voor deze configuratie is alleen de optie 'enable authentication' verder nog van belang. Deze zorgt er namelijk voor dat alvorens de informatie wordt doorgegeven, er eerst authenticatie via de iChain moet plaatsvinden. Dankzij deze optie heeft de webserver die benaderd wordt, geen beveiliging meer nodig. Het valt buiten het kader van dit hoofdstuk, maar het is zeer eenvoudig om delen van een website voor iedereen beschikbaar te maken en andere delen via iChain te beschermen. Als gekozen wordt voor 'enable authentication' dienen de opties hiervan te worden geconfigureerd via de 'authentication options'-button die naast deze optie staat. Deze button brengt u in het volgende scherm:

9/3.5-8



De opties die hier kunnen worden ingesteld, vormen de configuratie van de communicatie tussen de iChain-server en de LDAP-server. De idle time geeft aan hoe lang een browser geen contact hoeft te hebben met de iChain-server voordat de communicatie wordt verbroken. De opties 'Forward iChain Cookie to web server' en 'forward authentication information to web server' zorgen voor een single sign-on-mogelijkheid. De keuze tussen deze twee opties is afhankelijk van de gebruikte webserver. In ons geval is forward authentication een goede oplossing. De laatste keuze is of username/password via http moet worden geforward. Er zijn helaas webapplicaties die alleen op deze manier een single sign-on kunnen bereiken. Het is echter de minst wenselijke methode aangezien er geen beveiliging gebruikt wordt. De kans dat sniffers het pakket bemerken en zo achter de username/password-combinatie Novell Netwerkoplossingen, aanvulling 5

9/3.5-9

Webservices: iChain

komen is misschien niet zo heel groot, maar is wel degelijk aanwezig. Voor webservers die in het eigen netwerk staan, is dat risico wellicht nog wel te lopen, maar bij servers die extern staan, weet u nooit wat voor route een packet aflegt en wie de informatie kan zien.

9/3.5-10



9/3.6

Form-fill

Tot slot

Een single sign-on is mogelijk door de combinatie van het cookie-domein en de idle time. Niet alle websites ondersteunen echter de opties die iChain standaard biedt voor een single sign-on (forward iChain cookie en forward authentication information). Ook voor deze websites biedt iChain een oplossing, in de vorm van form-fill. Als een form-fill wordt gemaakt, dient de iChain-beheerder een script te maken dat bij een specifieke webpagina de gegevens over inloggen vergaard. De eerste maal dat een gebruiker naar deze webpagina gaat moet hij nog wel zijn informatie ingeven, maar deze informatie wordt dan in eDirectory opgeslagen en alle volgende keren zorgt formfill ervoor dat de gegevens automatisch worden ingevuld. Natuurlijk is dit bewerkelijker dan de tot nu toe beschreven opties, maar het werkt bij alle websites en webapplicaties. Zeker als de Portal Services goed worden ingezet, is het zeer goed denkbaar dat er een aantal externe websites wordt gebruikt voor het vergaren van informatie (denk aan weerberichten en beurskoersen). Al die externe bronnen kunnen dan als 'onderdeel' van de portal worden aangeboden. Na het gebruiken van iChain voor het verkrijgen van een single sign-on voor webservices is het ook mogelijk om de toegang tot de portal zelf via de authenticatie van iChain te laten verlopen. Hierdoor hoeven gebruikers daadwerkelijk nog maar één wachtwoord in te voeren voor het inloggen als voor de eerste maal een bron wordt gebruikt waar een username/wachtwoordcombinatie voor nodig is. Door een proxy aan te maken voor de portal zelf, verloopt de communicatie naar de portalserver via iChain. Hierdoor


9/3.6-1

Webservices: iChain

wordt de toegang tot de portal versneld, maar wordt het inloggen op de portal ook afgehandeld door iChain. De portal toont de gebruiker vervolgens alle bronnen die ter beschikking staan.

De portalserver gebruikt hiervoor echter de aangemaakte proxy’s in iChain waardoor ook deze sites worden versneld en ook hiervoor de authenticatie via iChain gaat lopen. Het eindresultaat is een snelle, veilige en eenvoudig te gebruiken portal.

9/3.6-2


3 Webservices: ichain

Recommend Documents