Upload dienst & Authenticatie

[ViNyL]

Voor een upload dienst binnen onze organisatie ben ik hier een idee voor op papier aan het zetten. De bedoeling is dat gebruikers middels LDAP met onze Active Directory geauthenticeerd worden.

Dit is allemaal geen probleem maar ik vraag me af hoe ik het ingelogd blijven het beste kan aanpakken. Alle sessies worden in een database opgeslagen. Nu moet je natuurlijk weten welke sessie/uploads bij welke user horen. Wat is daar het beste voor cliënt side? Een sessie met een random uniek nummer zodat er cliënt side verder niets wordt opgeslagen?

Iemand ideeën?

[Janoz]

Ik mis een heleboel context. Wat is het idee voor de client? Wat is het idee voor de server? Allemaal leuk en aardig die LDAP, maar dat zegt helemaal niks over de communicatie tussen client en server. Is er uberhaupt wel een server?

[ViNyL]

Ja sorry, het ging me eigenlijk alleen om het laatste stukje.

Het is een server met Windows Server 2008 waarop Apache/PHP en MySQL draait. Via een front end kunnen mensen inloggen, deze login wordt gecheckt in de Active Directory en er moet op een manier opgeslagen worden dat mensen ingelogd zijn.

Voor dit stukje vraag ik me dus af wat het beste is om dat op te slaan. In een database onder een uniek nummer, en client side een sessie met dit nummer?

[Janoz]

Zolang je niet verteld dat het hier om een webapplicatie gaat is er een weinig zinnig antwoord te geven. Zelfde geldt voor het beschikbaar zijn van SSO en of we hier met een intra- of internet applicatie te maken hebben.

[ Voor 35% gewijzigd door Janoz op 08-02-2010 10:58 ]

[ViNyL]

Klopt helemaal, soms vergeet je dat er ook nog wat anders is

[Alex)]

Is er een reden dat je kiest voor PHP/MySQL? Ik hoor "Windows Server", "Active Directory" en "Intranet". Dan denk ik eerder aan IIS en Internet Explorer met Windows Integrated-authentication zodat je single sign-on hebt (dmv de Trusted Zones).

[Janoz]

@Alex)
Nou, ik weet nog niks. Ik vraag inter- of intranet en krijg alleen 'klopt' terug .

Maar mocht het inderdaad intranet zijn dan haal je me de woorden uit de mond

[ViNyL]

De applicatie komt aan de buitenkant van onze organisatie te hangen zodat mensen ook vanuit huis bestanden kunnen plaatsen.

De keuze voor PHP'/MySQL is gebaseerd op het feit dat ik daarmee ontwikkel.

[Alex)]

Nouja, hij schreef "binnen onze organisatie", en LDAP/AD zijn meestal genoeg hints dat het om een intranet gaat.

Edit: ah, toch extern.

Evenzogoed blijft staan dat je authenticatie prima door de webserver kunt laten afhandelen... je hebt dan meteen AD-integratie en je kunt vanuit PHP ook uitvragen wie de ingelogde user is.

[ Voor 48% gewijzigd door Alex) op 08-02-2010 11:06 ]

[ViNyL]

Ja klopt, maar ook binnen onze organisatie draait een PHP/MySQL gebaseerd intranet. Er zijn inderdaad ook bij ons wel applicaties die met IIS en Windows Integrated-authentication werken.

Alex) schreef op maandag 08 februari 2010 @ 11:05:
Nouja, hij schreef "binnen onze organisatie", en LDAP/AD zijn meestal genoeg hints dat het om een intranet gaat.

Edit: ah, toch extern.

Evenzogoed blijft staan dat je authenticatie prima door de webserver kunt laten afhandelen... je hebt dan meteen AD-integratie en je kunt vanuit PHP ook uitvragen wie de ingelogde user is.

Dat klopt en dat doe ik ook met adLDAP. Het is alleen heel moeilijk om iemand die vanuit huis inlogt en dus niet in het domein zit in LDAP te checken. Daarvoor moet je ze dus laten inloggen. Om ingelogd te blijven moet er een sessie gemaakt worden.

Ik vraag me dus af wat ik het beste in de sessie kan opslaan.

[ Voor 67% gewijzigd door ViNyL op 08-02-2010 11:10 ]

[Janoz]

Goed, extern en PHP. Waarom voldoet de standaard sessie functionaliteit van PHP niet?

[ViNyL]

Dat voldoet prima, maar dus een sessie wordt het. Maar hoe 'veilig' is het om in een sessie een gebruikersnaam op te slaan. Vandaar mijn idee om het met een random uniek nummer te doen.

[Janoz]

Ik wil je aanraden om eens even uit te zoeken hoe de standaard sessie van php is geïmplementeerd. Dat zal namelijk al de in deze thread door jouw gestelde vragen beantwoorden.

[ Voor 5% gewijzigd door Janoz op 08-02-2010 11:19 ]

[ViNyL]

Ik weet dat een sessie niet op de computer van de gebruiker staat. Niet geheel client side dus. My bad. Alleen als ik rondlezen over het gebruik van sessie dan zie ik bijvoorbeeld dit:

"it is not recommended that you use sessions on a website that requires high-security, as there are security holes that take some advanced techniques to plug."

Daarom de vraag hoe verstandig het is om een username etc in een sessie te zetten of andere info. Is het dan niet beter te kiezen voor een random nummer in de sessie en de overige info die daar bijhoort in een database?

[Janoz]

Wat je beter kunt doen is doorlezen of uitzoeken waarom dat in high-security omgevingen afgeraden wordt. Het punt is namelijk dat de oplossingsrichting die jij op lijkt te gaan alleen maar een brakkere herimplementatie van de standaard sessie functionaliteit is en daardoor niet alleen de security problemen niet oplost, maar ook nog vast een heleboel andere bugs gaat bevatten omdat je alles compleet zelf overnieuw gaat doen.

Kortom, zoek eerst uit specifiek waarom iets niet voldoet en ga dat dan oplossen. Zomaar doelloos wat anders doen geeft natuurlijk geen enkele garantie dat je uberhaupt het probleem oplost.

[ Voor 4% gewijzigd door Creepy op 08-02-2010 11:38 ]

[Creepy]

Misschien moet je jezelf toch even inlezen in de materie? PHP genereert een sessieID voor je (een random nummer) en houdt in het geheugen (serverside!) bij welke gegevens daaraan vast hangen.
Edit: wat die enorm slimme Janoz zegt dus...

offtopic:
En whoops, deze edit deed ik eerst in de post van Janoz...

[ Voor 23% gewijzigd door Janoz op 08-02-2010 11:41 ]

[ViNyL]

Janoz schreef op maandag 08 februari 2010 @ 11:35:
Wat je beter kunt doen is doorlezen of uitzoeken waarom dat in high-security omgevingen afgeraden wordt. Het punt is namelijk dat de oplossingsrichting die jij op lijkt te gaan alleen maar een brakkere herimplementatie van de standaard sessie functionaliteit is en daardoor niet alleen de security problemen niet oplost, maar ook nog vast een heleboel andere bugs gaat bevatten omdat je alles compleet zelf overnieuw gaat doen.

Kortom, zoek eerst uit specifiek waarom iets niet voldoet en ga dat dan oplossen. Zomaar doelloos wat anders doen geeft natuurlijk geen enkele garantie dat je uberhaupt het probleem oplost.

Ok, ik zie op phpsec.org wat goede artikelen erover dus ik ga dat eens even doornemen.