[PHP]Cross domain login, hoe?

[AtleX]

Het doel
Ik wil een loginsysteem dat mij bij meerdere sites op meerdere domeinen inlogt. Dus, als ik inlog op domein1.nl ben ik ook ingelogd op sub.domein1.nl en domein2.nl. Om het probleem nog groter te maken zijn het allemaal bestaande webapplicaties die niet zomaar grondig te verbouwen zijn.

De bedoeling hiervan is ons gebruikersbeheer makkelijker maken, nu moeten we per applicatie een login aanmaken en dan kunnen we het allemaal centraal regelen.

Het probleem
Er zijn natuurlijk verschillende mogelijkheden om een login te bakken. Een veelgebruikte manier is sessions icm cookies. Het probleem daarmee is dat je door het Sandbox model alleen cookies uit kan lezen die bij het domein horen. Subdomeinen (sub.domein1.nl) zijn niet zo'n probleem, je kan een cookie zo maken dat hij voor het hele domein geld, dus ook de subdomeinen, maar domein2.nl kan er dan natuurlijk nog niet bij.

Je kan natuurlijk server-side iets opslaan in de database zodat je daar geen last van hebt, maar je hebt client-side toch echt iets nodig om je login te controleren. Cookies (practisch de enigste mogelijkheid) vallen daarvoor al af.

Mogelijk oplossingen
Ik heb wel wat dingetjes bedacht:

• Alleen server-side dingen doen, server-side een login koppelen aan een IP bijvoorbeeld. Deze methode staat me niet echt aan aangezien het zo lek als een mandje is.
• Een unique ID altijd meegeven in de URL. Het probleem is dat het bestaande applicaties zijn die allemaal gebruik moeten gaan maken van dezelfde login, om die allemaal aan te gaan passen is in principe mijn laatste optie.
• Frames () gebruiken, in een hidden frame wat dingen bijhouden. Deze pagina komt constant van 1 domein af zodat hij wel bij cookies kan, ik ben er alleen nog niet helemaal uit over hoe ik dan die login ga transferen naar de pagina van bijvoorbeeld domein2.nl die in het zichtbare frame wordt geladen.

Alle 3 de opties staan mij niet echt aan eigenlijk, ze zijn óf lek, óf ontzettend vies.

De search?
Ik heb natuurlijk even gezocht. Dat levert wel wat topics op, geen oplossing. Google komt ook voornamelijk met ideeën voor nieuw te ontwikkelen dingen, en over het algemeen zijn het ook geen sluitende oplossingen. Ze zijn ook weer ranzig, of zeer lastig te implementeren in bestaande applicaties.

De mogelijkheden
In principe kan ik vrij veel doen op de server met cronjobs en databases, daar hoeven dus niet echt problemen te liggen. Waar ik wel toe beperkt ben is PHP voor het server-side spul: ASP is niet beschikbaar op de server en van de overige talen is mijn kennisniveau dusdanig laag dat ik daar geen loginsysteem mee ga maken. Als het even kan moet het dus wel een oplossing zijn die in PHP is te maken. Ook is het gewoon allemaal shared hosting, rare PHP modules/plugins zijn dus niet echt mogelijk.

De vraag
Wie weet er dus nog een betere oplossing die vrij eenvoudig toe te voegen is aan de bestaande applicaties? Wat zetjes in de goede richting kunnen me waarschijnlijk gigantisch helpen .

[RedRose]

Kijk eens naar de principes van pubcookie:

http://www.pubcookie.org/docs/how-pubcookie-works.html .

[AtleX]

Pubcookie ziet er goed uit, maar het heeft een module nodig en die mogelijkheid is er eigenlijk niet. Het principe zelf ziet er goed uit maar het zal niet eenvoudig te implementeren zijn in bestaande applicaties.

[ Voor 36% gewijzigd door AtleX op 08-07-2005 12:30 ]

[RedRose]

Het idee is dan ook volgens mij dat je bestaande applicaties achter een https hangt en dat je je webserver en de pubcookie server de authenticatie laat afhandelen, zodat je juist geen modules op bestaande apps hoeft te schrijven. * leest ook nog een keer na.

[ Voor 5% gewijzigd door RedRose op 08-07-2005 12:32 ]

[Eskimootje]

Gebruiker logt in op server1
server1 stuurt gecodeerde info naar server2
server2 stuurt geheime code naar server1
server1 stuurt geheime code naar gebruiker
gebruiker bezoekt server2 (via iframe/img oid)
server2 controleert geheime code

Alleen zou ik dat wel via SHTTP doen.

[Janoz]

Optie drie werkt niet (altijd). Ook bij frames geld het sandbox gebeuren. Hier kun je ook niet een frame aanspreken die van een ander domein komt.

Er is nog een vierde optie. Je kunt na het inloggen op een site serverside een bepaalde token doorgeven aan de applicatie op het andere domein. Dit token heeft dan bijvoorbeeld een geldigheids duur van een minuut. Vervolgens stuur je naar de client een redirect naar het andere domein met daaraan meegegeven het eerder genoemde token. De andere applicatie weet dan dat hij pietje met token x kan verwachten en dat hij dan pietje op dat domein automatisch in kan loggen. Omdat dit bezoek gewoon via domein2 verloopt kan deze rustig een cookie zetten.

De gebruiker heeft op dat moment dus 2 verschillende sessies lopen terwijl hij maar 1x ingelogd is.

[AtleX]

RedRose schreef op vrijdag 08 juli 2005 @ 12:32:
Het idee is dan ook volgens mij dat je bestaande applicaties achter een https hangt en dat je je webserver en de pubcookie server de authenticatie laat afhandelen, zodat je juist geen modules op bestaande apps hoeft te schrijven. * leest ook nog een keer na.

SSL is niet mogelijk eigenlijk . Wat dat betreft ben ik vrij beperkt in de mogelijkheden. Verder zijn van alle webapplicaties bepaalde functies gewoon public. Deze moeten te bekijken zijn zonder in te loggen. Het probleem is dus dat ik dan ook niet zomaar de bestaande login uit applicaties kan slopen natuurlijk kan ik het wel aanpassen.

Janoz schreef op vrijdag 08 juli 2005 @ 12:39:
Optie drie werkt niet (altijd). Ook bij frames geld het sandbox gebeuren. Hier kun je ook niet een frame aanspreken die van een ander domein komt.

Er is nog een vierde optie. Je kunt na het inloggen op een site serverside een bepaalde token doorgeven aan de applicatie op het andere domein. Dit token heeft dan bijvoorbeeld een geldigheids duur van een minuut. Vervolgens stuur je naar de client een redirect naar het andere domein met daaraan meegegeven het eerder genoemde token. De andere applicatie weet dan dat hij pietje met token x kan verwachten en dat hij dan pietje op dat domein automatisch in kan loggen. Omdat dit bezoek gewoon via domein2 verloopt kan deze rustig een cookie zetten.

De gebruiker heeft op dat moment dus 2 verschillende sessies lopen terwijl hij maar 1x ingelogd is.

Goed idee, dit gaat op mijn veelbelovende-mogelijkheden-lijstje .

[ Voor 67% gewijzigd door AtleX op 08-07-2005 12:42 ]

[Janoz]

Eskimootje schreef op vrijdag 08 juli 2005 @ 12:35:
Gebruiker logt in op server1
server1 stuurt gecodeerde info naar server2
server2 stuurt geheime code naar server1
server1 stuurt geheime code naar gebruiker
gebruiker bezoekt server2 (via iframe/img oid)
server2 controleert geheime code

Alleen zou ik dat wel via SHTTP doen.

Waarom zo moeilijk en eventueel beveiligd? Ik neem aan dat beide servers gewoon als trusted kunt beschouwen. Daar kun je gewoon enkel aanvragen vanaf een bepaald ip accepteren. Wanneer beiden trusted zijn is een bericht met "pietje komt zo met token x (evt vanaf ip x.x.x.x)" genoeg. Al die gecodeerde data en geheime codes heen en weer valideren is onnodig complex zonder toegevoegde waarde. Zorg gewoon dat het token kort houdbaar is.

[JHS]

Is het mogelijk om een login script wat voor de andere scripts te hangen is te bouwen? Oftewel: zowel op domein1.nl als sub.domein1.nl als domein2.nl verwijzen naar loginscript.xxx (eventueel op één server), welke de drie login scripts aanroept, waardoor de cookies/sessies/whatever in het leven worden geroepen. Oftewel een facade vóór de drie loginscripts. Met drie simultane sessies. .

[Eskimootje]

Janoz schreef op vrijdag 08 juli 2005 @ 12:42:
[...]


Waarom zo moeilijk en eventueel beveiligd? Ik neem aan dat beide servers gewoon als trusted kunt beschouwen. Daar kun je gewoon enkel aanvragen vanaf een bepaald ip accepteren. Wanneer beiden trusted zijn is een bericht met "pietje komt zo met token x (evt vanaf ip x.x.x.x)" genoeg. Al die gecodeerde data en geheime codes heen en weer valideren is onnodig complex zonder toegevoegde waarde. Zorg gewoon dat het token kort houdbaar is.

Ik weet niet maar om nou plain text over internet te versturen lijkt me niet het allerhandigst. En een ip is redelijk makkelijk te faken als je geen data terug hoeft te krijgen.

[djluc]

Gaat het nu om het eenvoudig beheren van gebruikers of om crossdomain in te kunnen loggen? Als het je namelijk om het beheer gaat is het veel eenvoudiger om een useradmin te maken welke de diverse usertabellen gelijktijdig kan beheren. Bijvoorbeeld door de bestaande userids van de gebruikers in de verschillende applicaties aan elkaar te koppelen in een koppeltabel. Als je dan een gegeven in je nieuwe admin wijzigt zorg je er voor dat dit bij alle applicaties ook gebeurt.

[jochemd]

De mogelijkheid voor cross-domain authentication is gewoon ingebouwd in HTTP. Zie RFC 2617 voor HTTP Digest Authentication.