Apache authenticatie door middel van database en cookie

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • mauricedb
  • Registratie: Maart 2007
  • Laatst online: 12-10 11:50
Ik heb zitten nadenken en zoeken, maar ik begin een beetje radeloos te worden over onderstaand :(

Ik heb een login 'portal' voor mezelf in PHP gemaakt waarmee ik mijzelf toegang kan verschaffen tot enkele webapplicaties (Owncloud, DokuWiki en Shell in a Box). In Owncloud en DokuWiki kan ik eigen code plaatsen die in een database en een cookie checked of je juist bent ingelogd. Dit werkt prima. Omdat Shell in a Box een executable/package is en ik hierom geen PHP code in de applicatie kan frutselen, is denk ik mijn enigste optie om de verificatie in Apache af te vangen. Nu is het plaatsen van een htpasswd snel gedaan, maar zoals je al raadt wil ik dit gedaan hebben op dezelfde manier zoals dat bij Owncloud en DokuWiki gaat: één en hetzelfde login systeem dat in principe toegang verschaft tot de applicatie.

Ik maak gebruik van LXC containers en hierbij is de login portal de proxy server die verzoeken naar applicaties juist doorstuurt naar de betreffende container. Owncloud en DokuWiki gaan beiden vanaf de proxy naar hun eigen containers via poort 80. Shell in a Box draait op poort 4200. Extern komen alle applicaties op poort 443 binnen.

Waar ik naar gekeken heb is of ik op de één of andere manier een (PHP) script aan kan roepen in Shell in a Box, tot dusver zonder succes. Shell in a Box kan ook niet in een iframe worden gestopt (met PHP verificatiecode eromheen), omdat de applicatie dan via buiten aangeroepen wordt op poort 443 (proxy) -> 4200, oftewel geen verificatie mogelijk met PHP voor de url die je aanroept in de iframe. Heb ook zitten kijken naar Apache verificatie (mijn laatste hoop) waarbij ik een check kan doen of de waarde van een cookie die aangemaakt is na het inloggen overeenkomt met een waarde in een database. Ik kom mod_authnz_external tegen als ik op dit vlak naar mogelijkheden zit te zoeken, maar kom niet echt iets concreets tegen.

Weet iemand hier meer over of is het iemand gelukt om mijn probleem min of meer te omzeilen? Alvast bedankt! _/-\o_

Acties:
  • 0 Henk 'm!

  • Trucker Her
  • Registratie: Juni 2009
  • Niet online

Trucker Her

Someone ate my cookie :(

Is het een idee om een applicatie als Nginx of haproxy als frontend proxy te draaien en daarin je authenticatie te doen?

Deze kan je dan als transparante proxy gebruiken om je authenticatie af te vangen en de rest door de sturen naar de betreffende applicaties? ;)

Het kan zijn dat ik er hiermee compleet naast zit, heb geen ervaring met Shell in a Box, of DokuWiki; maar met OwnCloud cq webapplicaties zou dit geheel wel moeten werken.

Gestoord word je toch...


Acties:
  • 0 Henk 'm!

  • mauricedb
  • Registratie: Maart 2007
  • Laatst online: 12-10 11:50
Als ik je goed begrijp heb ik die constructie al werkend (vanuit Apache/Nginx de verwijzing naar een simpel htpasswd bestand met daarin de logingegevens). Maar ik wil het dus juist op de manier zoals ik dat omschrijf zoals dat bij Owncloud/DokuWiki gaat.

Acties:
  • 0 Henk 'm!

  • Trucker Her
  • Registratie: Juni 2009
  • Niet online

Trucker Her

Someone ate my cookie :(

mauricedb schreef op dinsdag 14 juli 2015 @ 10:28:
Als ik je goed begrijp heb ik die constructie al werkend (vanuit Apache/Nginx de verwijzing naar een simpel htpasswd bestand met daarin de logingegevens). Maar ik wil het dus juist op de manier zoals ik dat omschrijf zoals dat bij Owncloud/DokuWiki gaat.
Als ik dat goed begrijp wil je eenheid hebben voor het inloggen erop.
Volgens mij (pin me dr niet op vast), kun je gewoon een "derde" php-login-script aanroepen via een url; hiermee een bepaald cookie zetten en in je loadbalancer/forwarding proxy checken of het betreffende cookie aanwezig is -> zo ja, toegang verschaffen.
Op die manier heb je één wijze van inloggen.. Of het nou de veiligste manier is durf ik je niet te zeggen..

Gestoord word je toch...


Acties:
  • 0 Henk 'm!

  • mauricedb
  • Registratie: Maart 2007
  • Laatst online: 12-10 11:50
Weet niet of dat wat jij zegt mogelijk is, want welke (externe) url zou dat dan moeten zijn? Het kan niet de url zijn waar Shell in a Box op draait, want dan is er geen (PHP) script aan te roepen. Het zou dan alleen kunnen als je van extern door wordt verwezen naar een PHP bestand en als je geverifieerd bent je dan lokaal (!) wordt doorgestuurd naar de juiste poort van Shell in a Box, maar dat is voor zover ik weet niet haalbaar.

Heb nu dit gevonden met wat nieuwe/andere zoekwoorden: http://httpd.apache.org/docs/2.4/mod/mod_auth_form.html

Eens kijken of ik daar verder mee kom :)

Acties:
  • 0 Henk 'm!

  • mauricedb
  • Registratie: Maart 2007
  • Laatst online: 12-10 11:50
Waar het op neerkomt bij de dingen die ik tegenkom is dat er nog ingelogd moet worden, maar in mijn situatie is er al ingelogd. Als je inlogt dan krijgt iedere applicatie in de database zijn eigen unieke code en hiervan worden dan ook dan losse cookies gemaakt. Bij Owncloud en DokuWiki heb ik dus een stukje PHP bovenaan de code kunnen plaatsen die checked of de waardes van de database en cookies met elkaar matchen, zo ja dan heb je toegang tot de applicatie. Bij Shell in a Box moet deze check in de vhost gebeuren, maar hoe ... geen idee. Weet niet eens of dit mogelijk is :?

Acties:
  • 0 Henk 'm!

  • Douweegbertje
  • Registratie: Mei 2008
  • Laatst online: 11-10 16:28

Douweegbertje

Wat kinderachtig.. godverdomme

Hoezo werkt een iframe niet?

Gewoon username:password@shellinabox.local zeg maar.. Je kunt me niet wijsmaken dat het alleen remote benaderbaar is namelijk :p

Acties:
  • 0 Henk 'm!

  • mauricedb
  • Registratie: Maart 2007
  • Laatst online: 12-10 11:50
Met een iframe kun je alleen externe url's gebruiken, maar de manier zoals jij 't wilt doen maakt gebruik van een htpasswd (al betwijfel ik of het mogelijk is om de logingegevens in de url te zetten met een htpasswd), wat ik dus juist anders wil :P Alsnog bedankt voor de reactie en het meedenken!

[ Voor 19% gewijzigd door mauricedb op 15-07-2015 23:18 ]

Pagina: 1