[php/iis] authenticatie

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • MadMan81
  • Registratie: April 2000
  • Laatst online: 08:49
Ik heb het volgende:

Een klant van ons wil graag dat we onze website koppelen met hun intranet website. Deze laatste draait op een IIS machine, de eerste op een linux/apache omgeving. Voor hun intranet gebruiken zij http authenticatie om gebruikers te laten inloggen en nu willen ze graag dat onze website dusdanig wordt geintergreerd dat dit niet op nieuw hoeft.

Het idee is om op de IIS machine een file er bij te plaatsen waarna de link op het intranet verwijst (dus op de zelfde machine). Deze file redirect dan door naar de echte website. Om te voorkomen dat men nog een keer moet inloggen zullen username/password via een post-request (over https) naar de pagina worden gestuurd.

Echter het loopt al spaak bij het opvissen van het password. Een var_dump van $_SERVER laat o.a het volgende zien:
code:
1
2
3
4
5
6
7
8
["HTTP_AUTHORIZATION"]=>
  string(1750) "Negotiate YIIFE <knip> ASyA=="
["AUTH_TYPE"]=>
  string(9) "Negotiate"
["AUTH_PASSWORD"]=>
  string(0) ""
["AUTH_USER"]=>
  string(13) "DOMAIN\testuser"

Men maakt dus gebruik van Negotiate als type ipv het veel gebruikte Basic. Ook valt op dat hier bijv AUTH_USER wordt gebruikt ipv PHP_AUTH_USER.

Volgens de documentatie van php (http://nl2.php.net/manual/en/features.http-auth.php) kan je met de volgende functie het username en password uit HTTP__AUTHORIZATION halen:
PHP:
1
list($user, $pw) = explode(':', base64_decode(substr($_SERVER['HTTP_AUTHORIZATION'], 6)));


Maar aangezien hier Negotiate (9 letters ipv de 5 van Basic) wordt gebruikt zou dit waarschijnlijk als volgt moeten:
PHP:
1
list($user, $pw) = explode(':', base64_decode(substr($_SERVER['HTTP_AUTHORIZATION'], 10)));


Echter dit geeft geen bruikbare informatie (het decoden lijkt niet (volledig) te lukken).

Is hier iemand die een mogelijk oplossing heeft?

Het betreft een IIS 6 met PHP 5 machine

Cupra Born


Acties:
  • 0 Henk 'm!

  • StevenK
  • Registratie: Februari 2001
  • Laatst online: 20-09 16:45
Als ze automatisch inloggen, gebruiken ze NTLM, maar dat had je al gemerkt; als je nu op de website ook NTLM draait, dan kun je daarna de passwordhash die dat oplevert via radius tegen die windows-server aanhouden.

Daarvoor moet je dus wel radius op het corporate netwerk draaien *en* toegang hebben vanaf de webserver tot die radius-server.

(tenminste, dit is dan de theorie, ik heb 't nog nooit gebruikt, waar nodig draai ik dan wel php op IIS)

edit 1:Kun je niet makkelijker NTLM op apache draaien, die dan tegen die radius-server authoriseert ?

edit 2:Bijvoorbeeld mod_ntlm (hoewel deze dan wel weer smb-verkeer met een DC nodig heeft)

[ Voor 20% gewijzigd door StevenK op 15-02-2006 14:34 ]

Was advocaat maar vindt het juridische nog steeds leuk


Acties:
  • 0 Henk 'm!

  • MadMan81
  • Registratie: April 2000
  • Laatst online: 08:49
Volgens mij maken ze geen gebruik van NTLM: de gebruiker krijgt nl wel een popup met de vraagn om zijn/haar username/password als de intranet site wordt bezocht.

Verder heb ik zelf geen ervaringen met NTLM, maar wat ik van kenissen heb begrepen is het nogal lastig (zo niet onmogelijk) om dat voor elkaar te krijgen onder apache

Cupra Born


Acties:
  • 0 Henk 'm!

  • StevenK
  • Registratie: Februari 2001
  • Laatst online: 20-09 16:45
MadMan81 schreef op woensdag 15 februari 2006 @ 14:36:
Volgens mij maken ze geen gebruik van NTLM: de gebruiker krijgt nl wel een popup met de vraagn om zijn/haar username/password als de intranet site wordt bezocht.
Dat hoeft niet noodzakelijk; ook met NTLM krijg je die vraag, behalve wanneer je wat IE instellingen aanpast. Maar alleen met NTLM (en de juiste IE instellingen) kun je het zo maken dat een MS client automatisch, zonder iets te vragen, inlogt. En dat is toch wel het mooiste, toch ?
Verder heb ik zelf geen ervaringen met NTLM, maar wat ik van kenissen heb begrepen is het nogal lastig (zo niet onmogelijk) om dat voor elkaar te krijgen onder apache
Hm.. ander idee: kun je niet proxy draaien bij de klant ? Dan kun je volgens mij de username waarmee geauthentiseerd is op de proxy uitlezen.

Was advocaat maar vindt het juridische nog steeds leuk


Acties:
  • 0 Henk 'm!

  • MadMan81
  • Registratie: April 2000
  • Laatst online: 08:49
Zeker, NTLM is natuurlijk het mooiste. Ik zal nog wel eens een blik werpen naar die module mod_ntlm..

Ze draaien ook een proxy, maar die wordt alleen gebruikt voor externe websites: alle interne websites gaan rechtstreeks.

Maar klopt mijn vermoeden dat HTTP_AUTHORIZATION bij Negotiate anders wordt versleuteld dan bij Bacis? Of zelfs dat MS hier een eigen "standaard" voor gebruikt?

Zo ja, hoe moet ik hem dan decoden?

Cupra Born


Acties:
  • 0 Henk 'm!

  • StevenK
  • Registratie: Februari 2001
  • Laatst online: 20-09 16:45
MadMan81 schreef op woensdag 15 februari 2006 @ 14:51:
Zeker, NTLM is natuurlijk het mooiste. Ik zal nog wel eens een blik werpen naar die module mod_ntlm..

Ze draaien ook een proxy, maar die wordt alleen gebruikt voor externe websites: alle interne websites gaan rechtstreeks.
Maar jullie site is toch extern ?
Maar klopt mijn vermoeden dat HTTP_AUTHORIZATION bij Negotiate anders wordt versleuteld dan bij Bacis? Of zelfs dat MS hier een eigen "standaard" voor gebruikt?

Zo ja, hoe moet ik hem dan decoden?
In principe kun je die niet decoden, omdat het MS eigen éénweg encryptie is; controle doe je door het gecodeerde wachtwoord aan een authenticatie-server te voeren.

overigens nog een alternatief voor mod_ntlm: http://drupal.org/node/44718

[ Voor 5% gewijzigd door StevenK op 15-02-2006 14:54 ]

Was advocaat maar vindt het juridische nog steeds leuk


Acties:
  • 0 Henk 'm!

  • MadMan81
  • Registratie: April 2000
  • Laatst online: 08:49
Nee niet extern, maar wel een andere machine..

Cupra Born


Acties:
  • 0 Henk 'm!

  • StevenK
  • Registratie: Februari 2001
  • Laatst online: 20-09 16:45
MadMan81 schreef op woensdag 15 februari 2006 @ 15:04:
Nee niet extern, maar wel een andere machine..
Gebruik je speciale apache mods ofzo ? Anders kun je in principe je site volledig op een php/iis combi draaien.

Ik schrijf alles op een php/IIS combi (php als cgi) en de produktie daarvan is soms op IIS (vaak intranet) en meestal op linux en hoef *nergens* in de code rekening te houden windows/linux of apache/iis.

[ Voor 28% gewijzigd door StevenK op 15-02-2006 16:47 ]

Was advocaat maar vindt het juridische nog steeds leuk


  • MadMan81
  • Registratie: April 2000
  • Laatst online: 08:49
Dat klopt, dat is ook geen probleem. Het is alleen zo dat de webaplicatie afhankelijk is van andere (deels zelf ontwikkelde) applicaties die op die linux machine draaien. Daardoor is het noodzakelijk dat die website op die linux machine kan blijven draaien.

Maar is er niemand die mij kan vertellen waarom het decoderen van die HTTP_AUTHORIZATION niet lukt? Zo nee, is er geen andere methode om er voor te zorgen dat het password bekend wordt?

Ik had zelf al geprobeerd om opnieuw een de authenticatie te doen, maar dit keer basic:
PHP:
1
2
3
4
5
6
7
8
  if ($_SERVER["AUTH_TYPE"]=="Negotiate") {
   header('WWW-Authenticate: Basic realm="My Realm"');
   header('HTTP/1.0 401 Unauthorized');
   echo 'Text to send if user hits Cancel button';
   exit;
  } else {
   var_dump($_SERVER);
  }


Helaas blijft dit in een loop hangen: AUTH_TYPE blijft Negotiate...

Cupra Born


  • StevenK
  • Registratie: Februari 2001
  • Laatst online: 20-09 16:45
Kun je dan niet makkelijker iets met een shared sessie-database doen ? Dus op het intranet een sessie-id aanmaken, waarvan je auth_user naar een db logt, en dan de user met dat sessie-id redirecten naar je linux doos, waarna je op de linux-doos de auth_user weer uit de database haalt ?

Was advocaat maar vindt het juridische nog steeds leuk


  • MadMan81
  • Registratie: April 2000
  • Laatst online: 08:49
Dat zou idd een optie zijn, ware het niet dat die intranet site van een andere leverancier is en we daar dus geen aanpassingen in kunnen doen :|

Cupra Born


  • StevenK
  • Registratie: Februari 2001
  • Laatst online: 20-09 16:45
MadMan81 schreef op donderdag 16 februari 2006 @ 09:40:
Dat zou idd een optie zijn, ware het niet dat die intranet site van een andere leverancier is en we daar dus geen aanpassingen in kunnen doen :|
Maar kun je niet op die server een enkele index.php draaien op een andere virtuele server ?

Was advocaat maar vindt het juridische nog steeds leuk

Pagina: 1