[intranet]single sign on voor alternatieve browsers

[Verwijderd]

Op het werk ben ik bezig met het opzetten van een signle sign on voor een bestaand intranet. We zijn vrij wat betreft keuze server side technologie (met een voorkeur voor jsp of perl/html).

Nu zijn hier al veel topics over in GOT en tweakers algemeen maar het komt er dikwijls op neer dat je alleen via internet explorer dit kan doen. Ik heb nu iets in elkaar gestoken dat de username uit de request uitleest in java. Dit is mogelijk omdat de browser ingesteld staat op "intranet".

Hierbij zijn drie problemen:

1)security:
Kan een werknemer (jos bvb) die intern aanlogd met zijn gebruikersnaam, misschien een aantal omgevingsvariabelen gaan wijzigen en zich voordoen als jeff? Als dit mogelijk is kunnen mensen toegang krijgen tot ongeoorloofde documenten!

2)compatible:
Op dit moment staan er in het bedrijf zo'n 50 computers met allemaal internet explorer. Dit gaat in de toekomst overschakeld worden naar firefox of opera. De huidige in elkaar geboxte techniek werkt alleen op internet explorer. Andere mogelijkheden zijn een signed appled. Weet iemand hoe ik daar aan begin?

1):VPN
Gebruikers kunnen op dit moment zelfs via vpn op het intranet (dat dus momenteel algemeen is en nog niet is gepersonallisseerd). Mensen die dan achter firewalls zitten enzoverder, kunnen we daaruit nog een gebruikersnaam uitlezen of bestaat er een truc waarbij je toch , speciaal voor vpn gebruikers, een gebruikersnaam moet vragen

Ik hoop dat het duidelijk is. De afgelopen dagen heb ik wel iets werkend in elkaar gekregen maar tegen de voorgaande problemen gebotst. Na lang zoekwerk heb ik niet echt alternatieven gevonden en plaats ik het maar op GOT

[Verwijderd]

Is er niemand die ervaring heeft in deze materie?

[elevator]

Een echte veilige oplossing hiervoor is -vziw- enkel mogelijk met NTLM van IE, en IIS aan de andere kant. Hiermee doe je een daadwerkelijke validatie op jullie domain controllers en weet je dus zeker wie wie is.

IE kent ook nog andere methodes (eg: via VBScript het WScript.Network object aanroepen en daar de user naam uit pakken), maar feitelijk ben je dan bezig om user input te vertrouwen en op dat moment is het ook te faken.

Welke methode je nu op dit moment in Java gebruikt zal bepalend zijn om te bepalen ofdat je daarmee al kwetsbaar bent of niet.

[Rukapul]

Waarom los je dit niet met 'standaard' technologie op ipv zelf te gaan ontwerpen?

Probleem 1 en 2: kies een fatsoenlijke identity federation/SSO technologie (Liberty's ID-FF 1.2 of de opvolger: OASIS' SAML 2.0). Dit zorgt er voor dat een eenmalige authenticatie (hoe die ook plaatsvindt, zie onder) te gebruiken is op alle intranet sites. Deze standaarden werken met security assertions wat als gevolg heeft dat na de authenticatie de gebruiker of een attacker niet zomaar even in z'n context/cookies/urls kan gaan verbouwen en zich als een ander kan voordoen.

Probleem 'authenticatie' en probleem 3: kies een authenticatie methode die sterk genoeg is en je bevalt. Als het volledig moet integreren in Windows en dus wilt voortbouwen op de Windows logon dan zal het aantal keuzes inderdaad erg beperkt zijn zoals bv Internet Explorer met NLTM. Wellicht dat er opties zijn om tijdens het inloggen een script te laten lopen wat de juiste assertions als cookie voor de juiste browsers ter beschikking stelt, maar dat zou je verder uit moeten zoeken.
Als je er genoegen mee neemt dat username/password/(token) authenticatie nogmaals wordt uitgevoerd zo nu en dan in een browser sessie dan is het vrijwel triviaal aangezien je dan de Windows logon loskoppelt van de browsersessie.

[ Voor 5% gewijzigd door Rukapul op 10-07-2005 11:38 ]

[MrBarBarian]

Ik ben een tijd bezig geweest om een sso oplossing te maken voor veel routers/switches/firewalls. Daaruit weet ik dat HET SSO protocool Kerberos is. Ook weet ik dat er voor Apache een module bestaat, alleen weet ik niet hoe het in de browser opgelost moet worden..

Het lijkt mij iig de moeite waard om even naar te kijken. Zoals je zelf al aangeeft is het zelf maken van een SSO protocol/oplossing zeker niet eenvoudig.

[Rukapul]

MrBarBarian schreef op zondag 10 juli 2005 @ 11:41:
Ik ben een tijd bezig geweest om een sso oplossing te maken voor veel routers/switches/firewalls. Daaruit weet ik dat HET SSO protocool Kerberos is. Ook weet ik dat er voor Apache een module bestaat, alleen weet ik niet hoe het in de browser opgelost moet worden..

Het lijkt mij iig de moeite waard om even naar te kijken. Zoals je zelf al aangeeft is het zelf maken van een SSO protocol/oplossing zeker niet eenvoudig.

Je hebt zeker een punt dat Kerberos van alle SSO oplossingen het meest gevestigd is, maar in dit geval is het niet het meest voor de hand liggend, zoals je zelf min of meer ook al aangeeft: kerberos is niet alleen een protocol, maar heeft ook een hele specifieke technologie binding. Het voordeel van de standaarden die ik hierboven aanhaalde is dat ze meerdere technologie bindings toestaan en standaard al een browser/http/javascript/cookies binding hebben. Het voordeel hiervan is dat je in elk geval op de client zo min mogelijk hoeft aan te passen.

[Verwijderd]

Rukapul schreef op zondag 10 juli 2005 @ 11:37: Wellicht dat er opties zijn om tijdens het inloggen een script te laten lopen wat de juiste assertions als cookie voor de juiste browsers ter beschikking stelt, maar dat zou je verder uit moeten zoeken.

Scripts en cookies is onveilig. Het is namelijk doodsimpel om scripts te faken en of cookies te kopieren.

Als je er genoegen mee neemt dat username/password/(token) authenticatie nogmaals wordt uitgevoerd zo nu en dan in een browser sessie dan is het vrijwel triviaal aangezien je dan de Windows logon loskoppelt van de browsersessie.

Tsja, maar de TS wil dat nu juist niet. Toch lijkt mij dit de beste oplossing. Zit je ook niet gelijk vast aan een windows client. Maar anders is IE eigenlijk de enige oplossing.

[Rukapul]

Verwijderd schreef op zondag 10 juli 2005 @ 18:48:
[...]

Scripts en cookies is onveilig. Het is namelijk doodsimpel om scripts te faken en of cookies te kopieren.


[...]

Tsja, maar de TS wil dat nu juist niet. Toch lijkt mij dit de beste oplossing. Zit je ook niet gelijk vast aan een windows client. Maar anders is IE eigenlijk de enige oplossing.

TS moet aangeven wat z'n threatmodel is: is de user vertrouwd en mag hij z'n login credentials dus zelf beheren en kan hij erop vertrouwd worden dat hij deze niet doorgeeft aan een ander? Hieruit volgt dan direct of een cookie met een security assertion aanvaardbaar kan zijn of niet.

[Gerco]

Firefox kan ook prima NTLM authenticatie aan hoor, gebruikte ik al eeuwen op het intranet van mijn vorige werkgever. Daarnaast kan apache met mod_ntlm en 1 of andere ldap module ok prima tegen Active Directory authenticeren.

Je kunt dus prima een single sign-on intranet maken met Windows clients, firefox/IE en apache of IIS, de mogelijkheden zijn in het geheel niet beperkt tot IIS/IE.

[MrBarBarian]

Ja, van NTLM moet je dus precies af. Vanaf Windows 2000 is (het eerder genoemde) Kerberos de manier die Windows gebruikt om op AD te authenticeren. Je kan ervanuit gaan dat NTLM een aflopende zaak is...

Primair wil Windows met Kerberos authenticeren, lukt dat niet, dan wordt NTLM geprobeerd en daarna wordt het opgegeven.

Ik zeg het nomaals () Kerberos is HET SSO protocol, ondersteunt door Windows (vanaf 2k) unix/linux/Cisco IOS. Kerberos is op alle punten superieur aan NTLM (o.a. dankzij mutual authenication)

Slightly offtopic:
Helaas heeft MS weer de nodige modificaties toegepast binnen hun Kerberos implementatie. Hierdoor is MS Kerberos erg lastig (maar wel mogelijk) te combineren met MIT Kerberos. Uiteraard wil MS geen exacte details geven over hun modificatie.

Helaas beperkt de huidige MS Kerberos ondersteuning zich tot authenticatie op AD en toegang tot shares.. Van echte SSO is geen sprake dus..

_{ik lijk wel een Kerberos verkopert}

[ Voor 39% gewijzigd door MrBarBarian op 10-07-2005 22:19 ]

[dingstje]

Verwijderd schreef op zondag 10 juli 2005 @ 18:48:
Scripts en cookies is onveilig. Het is namelijk doodsimpel om scripts te faken en of cookies te kopieren.

Dat valt te vermijden door te werken met tokens. Je zorgt dat bij het inloggen een door de server gegeven token (of combinatie van username/token) als cookie geset wordt. Vervolgens kan je met de gegeven token slechts eenmaal inloggen op het intranet (cookie moet dan wel geldig blijven de hele tijd dat de user is ingelogd op windows).

[Gerco]

MrBarBarian schreef op zondag 10 juli 2005 @ 22:14 een Kerberos verkooppraatje

Ik heb eens wat leeswerk over Kerberos gedaan en het is precies wat ik dacht dat het was: perfect

Ik heb er alleen was vraagjes over en die kun je misschien wel beantwoorden. Als ik Kerberos wil implementeren in een (web) applicatie moeten zowel de client als de server dat begrijpen.
Vraag 1: Snappen IE en Firefox dat? (Ik neem aan van wel)
Vraag 2: Snappen IIS en Apache dat (ik ga er vanuit van wel)

De echte vraag:
Moeten client en server nu zelf een manier verzinnen om de tickets en authenticators bij elkaar te krijgen of voorziet Kerberos daar al in? Stel dat ik een pop3 server wil Kerberisen, moet ik dan het pop3 protocol wijzigen of is daar een betere oplossing voor?

[MrBarBarian]

Gerco schreef op maandag 11 juli 2005 @ 14:11:
[...]

Ik heb eens wat leeswerk over Kerberos gedaan en het is precies wat ik dacht dat het was: perfect

Ik heb er alleen was vraagjes over en die kun je misschien wel beantwoorden. Als ik Kerberos wil implementeren in een (web) applicatie moeten zowel de client als de server dat begrijpen.
Vraag 1: Snappen IE en Firefox dat? (Ik neem aan van wel)
Vraag 2: Snappen IIS en Apache dat (ik ga er vanuit van wel)

De echte vraag:
Moeten client en server nu zelf een manier verzinnen om de tickets en authenticators bij elkaar te krijgen of voorziet Kerberos daar al in? Stel dat ik een pop3 server wil Kerberisen, moet ik dan het pop3 protocol wijzigen of is daar een betere oplossing voor?

Wat betreft browser ondersteuning kan ik je niets vertellen. Al eerder in dit topic zei iemand dat Mozzila NTLM ondersteunt. Ik denk dat je er daardoor vrij zeker van zijn dat Kerberos ook wel wordt ondersteunt.

IIS weet ik ook niet (heb niet zoveel intresse in MS produkten ) maar voor Apache is er een mod.

Kerberos veranderd niets aan protocollen zelf. Zowel de client als de server moeten wel Kerberos authenticatie ondersteunen. Vervolgens moet er dmv keys een trust relatie worden opgezet tussen client & server. Hierbij speelt de Ticket Granting Server (TGT, ben je waarschijnlijk al tegengekomen) een essentiele rol; de TGT bepaald wanneer een client of server haar identiteit heeft bewezen.

Als je dus voor een emailclient de authenticatie wilt laten uitvoeren dmv Kerberos heb je een server nodig die het ondersteunt (Sendmail hoogst waarschijnlijk wel) en een Client (Eudora bijvoorbeeld)

[MTWZZ]

Volgens de makers van de Apache module snapt mozilla Kerberos via GSSAPI:
http://modauthkerb.sourceforge.net/configure.html
En volgens deze pagina moet Firefox het ook snappen.

[Gerco]

MrBarBarian schreef op maandag 11 juli 2005 @ 15:16:
Als je dus voor een emailclient de authenticatie wilt laten uitvoeren dmv Kerberos heb je een server nodig die het ondersteunt (Sendmail hoogst waarschijnlijk wel) en een Client (Eudora bijvoorbeeld)

Dat gedeelte snap ik, de client moet een ticket en een authenticator naar de service sturen om zich bekend te maken. Wat ik alleen niet snap is hoe. Dat ticket is gewoon een beetje data, dat moet op de 1 of andere manier bij die service aankomen, mijn vraag is nu dus: "hoe gebeurt dat?".

Ik neem aan dat er dus een aanpassing nodig is in het protocol wat client en service spreken om het uitwisselen van tickets mogelijk te maken. Een "Krb-Ticket:" header in HTTP bijvoorbeeld, is dat juist?

[MrBarBarian]

Nee, er is geen aanpassing in een protocol nodig. Je moet authenicatie, authorisatie en de daadwerkelijke data-uitwisselingen zien als 3 aparte stages die doorlopen moet worden:

1. Jij klopt bij een server aan, en zegt dat je data wilt ontvangen. De server geeft jou in eerste instantie geen data, de server wil dat je eerst maar eens gaat bewijzen dat je bent wie je zegt te zijn (=authenticatie)
2. De server weet nu wie je bent en geloof dat ook (dankzij de authenticatie).. Nu wil de server nog eens gaan zien of jij wel recht hebt op de data die je opvraagt (=authorisatie)
3. Ook de authorisatie weet je te overleven, en nu ga je pas de data van de server krijgen.

Hoe jij de stapen 1 + 2 uitvoert is niet belangrijk, zolang zowel de server als de client weten hoe ze werken. M.A.W. of jij stap 1 uitvoert dmv een password, token, NTLM of Kerberos, dat maakt niet uit.
(onthoudt overigens wel erg goed dat Kerberos alleen stap 1 uitvoert!)

Hoe exact de ticket exchange uitgevoert wordt bij Kerberos is idd en lastig verhaal (na 10 keer lezen wordt het wel duidelijk ). Maar simpel gezegt komt het hierop neer:

1. Voordat je kan authoriseren mbv Kerberos moet je eerst jezelf authenticeren tegenover de TGT-server zelf. Dit gebeurt via een Ticketexchange en resulteerd uiteindelijk in een Ticket Granting Tcket (TGT). Dit is een ticket uitgedeelt door de TGT-server en is HET bewijs voor Kerberos dat je bent wie je zegt te zijn (ticket is dus geauthenticeert). Met behulp van dit ticket kan je andere tickets gaan aanvragen.
2. Je wilt toegang hebben tot een server. De eerste stap hierbij gaat zijn dat jij aan de TGT-server een ticket gaat vragen dat jou toegang gaat geven tot die server. De TGT-server geeft deze een je (als het goed is). Vervolgens biedt je dit ticket aan bij de server waar je toegang wilt hebben, en deze server valideert dit ticket op de TGT (ondertussen moet ook de server authenticeren op de TGT (=mutual authenication).
3. Als de gehele ticket exchange goed is verlopen, ben je geauthentiseert voor die server (en vervolgens zal de authorizatie beginnen.

(in werkelijkheid verloopt het process anders, maar dit is aardig de kern)

Kijk eens op deze pages:
http://web.mit.edu/kerberos/www/
http://www.isi.edu/gost/brian/security/kerberos.html
http://cryptnet.net/fdp/a...infra/en/kerby-infra.html

[Verwijderd]

Niet om te trollen, maar als je gebruik maakt van AD voor je gebruikersbeheer, Windows als je desktop client en Windows als je server platform, waarom zou je dan in hemelsnaam moeilijk gaan doen en een alternatieve browser gebruiken voor je intranet?

[Verwijderd]

Verwijderd schreef op dinsdag 12 juli 2005 @ 11:43:
Niet om te trollen, maar als je gebruik maakt van AD voor je gebruikersbeheer, Windows als je desktop client en Windows als je server platform, waarom zou je dan in hemelsnaam moeilijk gaan doen en een alternatieve browser gebruiken voor je intranet?

Een reden kan zijn dat men de browser ook gebruikt voor het internet en de gebruikers het alternatief prettiger vinden werken. Ook zijn er genoeg mensen die IE niet veilig vinden (maar ja, hoe veilig is het om allemaal trucs te gaan gebruiken om bij de alternatieve browser via windows in te kunnen loggen?)
De redenen voor een alternatieve browser voor het intranet hoeven helemaal niets met dat intranet te maken te hebben. Wel kun je natuurlijk de vraag stellen of de voordelen van de alternatieve browser de nadelen tov IE waard zijn. En zeker in omgevingen met een op Microsoft software gebaseerd Intranet kunnen die nadelen erg groot zijn.

[Verwijderd]

De reden voor IE op dit moment is "company" policy die we moeten overnemen vanuit amerika. Van de moment we onder een andere holding komen (dit gaat binnen enkele maanden gebeuren), hebben we de mogelijkheid om eindelijk IE buiten te gooien om zo al véél security leaks uit te sluiten. Uiteraard gaan er dan ook alternatieven worden gezocht voor het bestaande systeem maar andere browser zou dan wel eens mogelijk kunnen zijn;)

Alvast bedankt en ik luister aandacht naar deze discussie.

[Verwijderd]

Goed, ik snap jullie standpunt wel. Ik wil niet de hele discussie off-topic brengen door te discussieren over de voor- en nadelen van alternative browsers, maar gewoon even mijn ervaringen posten.

Ik ben nu zo'n 2 jaar werkzaam bij een middelgrote international (1000+ werknemers) om een aantal applicaties te ontwikkelen en uit te rollen. Wat ik tijdens deze jaren heb geleerd is dat echt 99% van de security problemen te wijten zijn aan menselijke fouten. Er worden bestanden gedownload en geopend van onbetrouwbare bronnen, er wordt vreemde software geinstalleerd, er wordt een besmette computer ingeprikt op het netwerk etc.

Zelf ben ik niet zo thuis op het gebied van het beheer, maar ik zie bij ons wel dat we nauwelijks problemen hebben door MS System Upate Services (en de opvolger), goede firewalls en consistent gebruikers- en rechtenbeheer. In principe zie ik alleen het security voordeel van een alternatieve browser als je deze dingen niet in orde hebt, eigenlijk meer als doekje voor het bloeden dus.

Hier tegenover staan dan de beperkte mogelijkheden voor integratie in je (neem ik aan) Windows omgeving en het ongemak voor de gebruikers. Voor veel mensen is Internet Explorer synoniem met internet en alles wat daar om heen hangt. Het deployen van een alternatieve browser is in dit geval weer een extra punt wat de integratie en acceptatie van je webapplicatie bij de gebruikers weer moeilijker maakt.

Klinkt misschien wat theoretisch, maar ik heb in de praktijk gezien dat dit wel degelijk een probleem is. En je wilt toch ook dat je applicatie gewoon goed gebruikt wordt en dat je het niet voor piet snot gemaakt hebt, niet?

[MrBarBarian]

We gaan nu wel erg offtopic hoor! (maar het is wel een leuke discussie EN ik kan weer wat over Kerberos vertellen)

Of je Mozilla of IE gebruikt maakt technisch gezien in deze niet zoveel uit. De authenticatie op W2K/XP verloopt dmv Kerberos, en is verder voor iedere applicatie beschikbaar die Kerberos ondersteunt. Zoals ik eerder zei, Kerberos is een (open) standaard. MS heeft deze standaard, op een kleine wijziging na, netjes geimplementeerd. Deze wijziging maakt het lastiger om MS SSO te integreren met Unix/Linux, maar het is zeker niet onmogelijk.

Ongetwijfeld is MS, met al haar aanvullende services, een degelijke oplossing. Alleen tip je een grote "maar" aan; als het maar goed geimplementeerd is. En daar ligt naar mijn mening een van de problemen van MS; het moedigt de gebruiker (of daagt de gebruiker) niet genoeg uit om goede implementatie/configuratie/enz uit te voeren.

Bovendien is het helaas waar dat MS voor veel gebruikers DE standaart is. Persoonlijk vind ik dat op alle vlakken een slechte ontwikkeling en het mag wat mij betreft absoluut geen argument zijn om nogmaals voor een MS-oplossing te kiezen. 90% van alle gebruikers kan vrij moeiteloos overstappen op een niet-MS-produkt, als hij/zij maar even nadenken (maar denken is voor veel mensen erg moeilijk )

Persoonlijk ben ik ongeveer 5 maanden geleden overgestapt op FF. Tot nu toe heb ik maar een nadeel weten te vinden (sommige sites werken niet, maar dat is niet de schuld van FF), maar meerdere voordelen (tabbed browsing, download manager, add blocking).. Grappig is dat de knoppen die 99% van de gebruikers gebruikt (en je mag er rustig vanuit gaan dat ze de andere knoppen niet eens kennen) gewoon op dezelfde plaats zitten

[ Voor 4% gewijzigd door MrBarBarian op 13-07-2005 09:24 ]

[whoami]

Dit gaat niet echt over programmeren.

Ik zal B&V wel kunnen verblijden met dit topic

P&W -> B&V

[Verwijderd]

Voorlopig gebeurt de authentificatie tegen een standaard domain controller en dus niet via Ad/ldap!