Automatisch inloggen op leverancierswebsite

[Verwijderd]

Beste Tweakers,

Ik ben op zoek naar een manier om op een leverancierswebsite in te kunnen loggen met een algemeen account (naam/wachtwoord) zonder dat de eigen medewerker ziet met welke gegevens hij/zij inlogt.
Ik heb er wel iets over gevonden maar dit richt zich niet specifiek op onderstaand probleem. Er word veel over php scriptjes gesproken enz maar vraag me af of dit de enige mogelijkheid is.
Het betreft hier een onderneming met 350 binnen medewerkers waarvan een x aantal mensen zich met inkoop/calculatie/werkvoorbereiding bezig houden

Probleemomschrijving:
Als je een naam en wachtwoord hebt gekregen van je leverancier om op zijn website spullen rechtstreeks in te kopen of voorraad te checken enz dan werkt het dikwijls zo dat je meerdere accounts krijgt zodat je met een x aantal mensen gelijktijdig in kunt loggen. Nu is het in de praktijk dikwijls zo dat wanneer een medewerker verkast naar de concurrent hij nog steeds kan inloggen op onze leverancierssite en zo dus onze inkoopcondities kan zien. Ja zal zeggen verander gewoon het wachtwoord en je bent klaar maar zo werkt het meestal nu net niet in de praktijk. Ook bij navraag aan de leverancier meld deze eigenlijk dat dit de zorg is van de klant zelf en dat hun daar niets aan doen. Ook zij geven aan dat ze wel meer horen dat de gegevens eigenlijk gewoon op straat liggen.

Oplossing:
Mogelijke oplossing zou zijn dat je een script of wat dan ook maakt waarmee je domainusers of een bepaalde gemachtigde groep een link geeft (het liefst middels sharepoint) waarop hij klikt en er rechtstreeks ingelogt word op de site van de leverancier met de inloggegevens die je hebt gekregen van de leverancier. Onderwater worden de inloggegevens ingevult en logt de user automatisch in , de afd automatisering beheerd de inloggegegevens en veranderd deze indien nodig in het script of programma. Hiermee vang je af dat iedereen de gegevens weet en het beheer is vrij eenvoudig en op 1 plaats.
Wij gebruiken sharepoint waarop diverse sites draaien waar eventueel links op geplaatst kunnen worden naar leveranciers.

Is hier een oplossing voor ?
Ik weet zeker dat dit in de praktijk een veelvoorkomend probleem is waar in grotere omgevingen niet juist mee omgesprongen word.

[F_J_K]

Een en ander hangt nogal af van de manier waarop de server van de leverancier werkt. Aangenomen dat het simpelweg loginnaam/password is via een html formuliertje:

Kijk even naar de SSO-mogelijkheden van Sharepoint (natuurlijk niet de SSO om op, maar juist om via MOSS in te loggen). Een van de eerste Google-hits die ik tegenkwam was http://www.synergyonline....sts/Posts/Post.aspx?ID=49

[Verwijderd]

Ik wil echt niet onbeleefd zijn, en snap je probleem ook wel, maar in mijn ogen is dit weer een niet technisch probleem proberen op te lossen met een technische oplossing. Te begrijpen hoor, want zo gaat dat nu eenmaal meestal in zijn werk.

Naar mijn mening:

1) Als het je leverancier al niks kan schelen, zou het mij ook niks kunnen schelen
2) Ik vermoed niet dat al die 350 medewerkers hier op moeten, maar eerder een 10/15-tal ? Waarom dan niet gewoon individuele logins? Zelfs nog als het er meer zijn, het beheer van die accounts blijft voor jouw leverancier. Als hij hier al geen tijd in wilt steken zegt dat in mijn ogen genoeg over de leverancier zelf.
3) Als je dit toch zo wilt, denk ik dat het idd af gaat hangen van het systeem zelf. Alles is te scripten / automatiseren, maar niet zonder kennis van het doel-systeem

[Verwijderd]

Verwijderd schreef op dinsdag 14 april 2009 @ 14:43:
Ik wil echt niet onbeleefd zijn, en snap je probleem ook wel, maar in mijn ogen is dit weer een niet technisch probleem proberen op te lossen met een technische oplossing. Te begrijpen hoor, want zo gaat dat nu eenmaal meestal in zijn werk.

Naar mijn mening:

1) Als het je leverancier al niks kan schelen, zou het mij ook niks kunnen schelen
2) Ik vermoed niet dat al die 350 medewerkers hier op moeten, maar eerder een 10/15-tal ? Waarom dan niet gewoon individuele logins? Zelfs nog als het er meer zijn, het beheer van die accounts blijft voor jouw leverancier. Als hij hier al geen tijd in wilt steken zegt dat in mijn ogen genoeg over de leverancier zelf.
3) Als je dit toch zo wilt, denk ik dat het idd af gaat hangen van het systeem zelf. Alles is te scripten / automatiseren, maar niet zonder kennis van het doel-systeem

Nou ik denk dat er niets mis is met het beveiligen van je eigen toko, ook als je leverancier niet meewerkt. Als jij van jouw concurrent weet wat hij betaald voor zijn spullen kan je dat meenemen in je calculatie. Dit heeft verder weinig met je leverancier te maken want die heeft de wachtwoorden niet afgegeven, die liggen op straat door het verloop in je eigen toko.
De oplossing hiervoor schaar ik toch wel in de technische hoek, bv zoals je zelf al aangeeft dmv scripting.
Dit oplossen met de leverancier lijkt me wenselijk en daar staan ze denk ik ook wel voor open, zolang je maar genoeg inkoopt kan er veel.

[DJSmiley]

En bv een paar accounts?

1 met alleen leesrechten (calculatie, werkvoorbereiding) en 1 met orderrechten (inkoop) en bv deze wachtwoorden maandelijks (of wekelijks) wijzigen en intern doormailen naar de betreffende personen?

Dan heb je, itt tot de huidige situatie, toch een scheiding, en zullen oude werknemers hoogstens tot de volgende ww wijziging erin kunnen.

2e optie is 1 login maken die restricted is op IP, zodat mensen alleen intern (of via terminal server) erop kunnen (in overleg met leverancier).

Mooier is natuurlijk scripting oid.

[Verwijderd]

Iemand hier al ooit een scipting oplossing voor gemaakt ?
Voordelen/nadelen ?

[Motrax]

Een mogelijke andere oplossing is een verlopend wachtwoord op de accounts, maar dan moet de leverancier wel mee werken.

Om de zoveel tijd moet je dan aangeven welke accounts weer geheropend moeten worden. Zo heeft een ex-medewerker een beperkte periode waar hij kan inloggen.

[RaZ]

Kan je niet aan leverancier vragen om het aan het IP van de zaak vast te zetten?

Daarnaast ben ik het met Jay-Jay eens. Als jullie intern bijhouden welke werknemer die info heeft, weet je dus ook als die werknemer vertrekt dat er een account veranderd moet worden. Dit doe je neem ik aan ook met het account binnen het bedrijf.

Een andere optie is gewoon een soort van portal te maken waarbij er niet meer dan een POST-methode is, die direct inlogt bij de leverancier. Dan hoeven de werknemers niet eens de codes te weten. Kwestie van een intranetje opzetten.

[Verwijderd]

Motrax schreef op woensdag 15 april 2009 @ 10:39:
Een mogelijke andere oplossing is een verlopend wachtwoord op de accounts, maar dan moet de leverancier wel mee werken.

Om de zoveel tijd moet je dan aangeven welke accounts weer geheropend moeten worden. Zo heeft een ex-medewerker een beperkte periode waar hij kan inloggen.

Het valt me op dat er veel richting de leverancier word gedacht. Met de oplossing aan je eigen zijde afvangen heb je alles in eigen hand. Is dit lastig te maken ?
Het zou natuurlijk mooi zijn als een leverancier dit item voor je kan afvangen maar de praktijk laat het anders zien. Afvangen in eigen toko lijkt me echt de beste oplossing.
-1 inlog plek voor je mensen (bv Sharepoint)
-Geen gevoelige info op straat
-Beheer op 1 plek (makkelijk rechten beheer middels AD)

Het gaat hier om een grote organisatie waar tientallen mensen inloggen op leverancierssite's.

[Motrax]

offtopic:
Je hebt gelijk, maar ik heb er helaas niet meer verstand van en kan je niet verder helpen met single signon truuk

[ralpje]

Verwijderd schreef op woensdag 15 april 2009 @ 10:54:
[...]


Het valt me op dat er veel richting de leverancier word gedacht. Met de oplossing aan je eigen zijde afvangen heb je alles in eigen hand. Is dit lastig te maken ?

Het is een applicatie van de leverancier, dus hij regelt de beveiliging. Geen gekke gedachte, toch?

[DiedX]

Hoe dan ook, ik ben van mening dat het fout gaat bij de toko van TS.:

* Wachtwoorden worden gegeven door leverancier: dan moet $toko een signaal afgeven dat $medewerker weg is gegaan. Kan prima op genomen worden in de ontslagprocedure (of zeg ik nu iets heel geks?)
* Wachtwoorden worden geleverd door $toko. Nog erger: direct op te nemen in de ontslagprocedure.

cq: reacties over al dan niet technische oplossingen prima, maar tenzij je 10 man per maand hebt is dit prima te doen. Bij meer dan 10 man heb je een heel ander probleem.

Overigens vermoed ik niet dat $leverancier mee gaat werken. Of hij houtjes verkoopt aan A of B zal hem biet wezen.

[Verwijderd]

RaZ schreef op woensdag 15 april 2009 @ 10:45:
Kan je niet aan leverancier vragen om het aan het IP van de zaak vast te zetten?

Daarnaast ben ik het met Jay-Jay eens. Als jullie intern bijhouden welke werknemer die info heeft, weet je dus ook als die werknemer vertrekt dat er een account veranderd moet worden. Dit doe je neem ik aan ook met het account binnen het bedrijf.

Een andere optie is gewoon een soort van portal te maken waarbij er niet meer dan een POST-methode is, die direct inlogt bij de leverancier. Dan hoeven de werknemers niet eens de codes te weten. Kwestie van een intranetje opzetten.

Het onderste is waar ik id aan denk.
We hebben sharepoint draaien waarop we een (leverancier)site kunnen maken met daar de links op.
De AD groep bepaalt wat je wel en niet ziet en rechten toe hebt.

[Verwijderd]

DiedX schreef op woensdag 15 april 2009 @ 11:01:
Hoe dan ook, ik ben van mening dat het fout gaat bij de toko van TS.:

* Wachtwoorden worden gegeven door leverancier: dan moet $toko een signaal afgeven dat $medewerker weg is gegaan. Kan prima op genomen worden in de ontslagprocedure (of zeg ik nu iets heel geks?)
* Wachtwoorden worden geleverd door $toko. Nog erger: direct op te nemen in de ontslagprocedure.

cq: reacties over al dan niet technische oplossingen prima, maar tenzij je 10 man per maand hebt is dit prima te doen. Bij meer dan 10 man heb je een heel ander probleem.

Overigens vermoed ik niet dat $leverancier mee gaat werken. Of hij houtjes verkoopt aan A of B zal hem biet wezen.

Bij grotere bedrijven zie je dat het verloop ook groter is als bv bij een knus familiebedrijf. In onze sector (installatietechniek) zie je dat medewerkers van bedrijf A naar B gaan in dezelfde sector en dus naar directe concurenten. Je moet dan op een gegeven moment mischien wel wekelijks de wachtwoorden gaan wijzigen. Begrijp me goed dit is zeker een optie maar ik vind het persoonlijk een knullige en niet gebruikersvriendelijk.
Ik zie geen reden waarom een gebruiker de inloggegevens moet hebben als alles netjes gefaciliteerd word middels het LAN of Terminalserver.

Een melding in het contract opnemen is leuk en aardig maar heb je in principe weinig aan. Bewijslast ligt bij jou en bewijs maar dat ik het was die vanaf IP 0.0.0.0 ingelogd heb. Is een extra waarschuwing niet meer en niet minder.

[DiedX]

Maar deel je nu 1 wachtwoord, of heeft ieder zijn eigen account?

[0X55AA]

Kan je niet een eigen website/database aanleggen waarbij de gegevens worden gesynched met die van de leverancier? Zo kan je bijvoorbeeld onmiddelijk bij een product de prijzen laten zijn van 2 of meerdere leveranciers en kan je onmiddelijk vergelijken.

Voordeel is ook dat als de leverancier plat ligt je toch nog naar de prijzen kunt kijken.

[Verwijderd]

DiedX schreef op woensdag 15 april 2009 @ 11:21:
Maar deel je nu 1 wachtwoord, of heeft ieder zijn eigen account?

Dit ligt aan je leverancier denk ik. Sommige kennen de mogelijkheid dat je met meerdere mensen onder 1 account kan inloggen andere maken een gebruikers inlog.

Maar het oplossen aan de leverancierszijde zie ik als 2e optie.
1e optie is wat mij betreft oplossen aan onze zijde.

[Verwijderd]

0X55AA schreef op woensdag 15 april 2009 @ 11:33:
Kan je niet een eigen website/database aanleggen waarbij de gegevens worden gesynched met die van de leverancier? Zo kan je bijvoorbeeld onmiddelijk bij een product de prijzen laten zijn van 2 of meerdere leveranciers en kan je onmiddelijk vergelijken.

Voordeel is ook dat als de leverancier plat ligt je toch nog naar de prijzen kunt kijken.

Is dit niet hogere wiskunde

[DiedX]

Dan de-bookmark ik dit topic. Het is naar mijn idee onbegonnen werk. Die leverancier zal je nodig hebben.

Mijn eerste optie zou zijn om de verantwoordelijkheid bij de leverancier te leggen: meerdere accounts, en die intrekken bij ontslag/vertrek. Het mooiste zou zijn als iemand bij jullie zelf die accounts aan kan maken.

Mijn tweede optie: 1 account, maar dan locken op IP.

Ik ben benieuwd wat eruit gaat komen. Ik zie de tech-oplossingen alweer voorbij komen. Wellicht is een Citrix-server die permanent ingelogd wel wat... (yes, phun intented)

[Verwijderd]

DiedX schreef op woensdag 15 april 2009 @ 11:45:
Dan de-bookmark ik dit topic. Het is naar mijn idee onbegonnen werk. Die leverancier zal je nodig hebben.

Mijn eerste optie zou zijn om de verantwoordelijkheid bij de leverancier te leggen: meerdere accounts, en die intrekken bij ontslag/vertrek. Het mooiste zou zijn als iemand bij jullie zelf die accounts aan kan maken.

Mijn tweede optie: 1 account, maar dan locken op IP.

Ik ben benieuwd wat eruit gaat komen. Ik zie de tech-oplossingen alweer voorbij komen. Wellicht is een Citrix-server die permanent ingelogd wel wat... (yes, phun intented)

Het begint net leuk te worden en ga jij hem De-bookmarken
Kan je ook aangeven waarom je denkt dat het onbegonnen werk is ?

Eigenlijk is de vraag simpel:
Kan ik via sharepoint (of ander medium) een mogelijkheid creeren waarmee ik op een website automatisch inlog middels een tool waarin ik de inloggegevens vermeld welke onzichtbaar zijn voor de gebruiker. ?

Nu nog het antwoord, en hopelijk ook niet al te ingewikkeld

[DiedX]

Verwijderd schreef op woensdag 15 april 2009 @ 12:28:
[...]


Het begint net leuk te worden en ga jij hem De-bookmarken
Kan je ook aangeven waarom je denkt dat het onbegonnen werk is ?

Volgens mij heb ik dat gedaan

Serieus: ik denk dat je het veel te moeilijk zoekt. Je hebt een leverancier, die wil verkopen.
Jij wilt er voor zorgen dat je inkoopprijzen niet bekend worden (vraag is of je daar daadwerkelijk iets mee opschiet. Een vertrekkend collega weet die prijzen, en kan gewoon direct met de leverancier contact opnemen)

Heel KISS beschouwd:

* Je deelt een gebruikersnaam en wachtwoord. Ik zou dan sterk aanraden om dit wachtwoord aan te passen per maand. Hierbij neem je een uniek wachtwoord wat je over inkoopt strooit. Bij voorkeur (?) laat je dit vastzetten op IP.
* Je geeft per medewerker een unieke gebruikersnaam en wachtwoord. Zodra iemand vertrekt trek je het account in (of laat je het intrekken)

Wil je het echt lastig maken dan ga je inderdaad naar de Citrix-thin clients toe. Dan moet je je serieus af gaan vragen waar je mee bezig bent. CQ: is het zo erg dat je oud collega het wachtwoord weet? Of moet je gewoon dat wachtwoord toch veranderen?

De vraag die ik stel: waartegen bescherm je jezelf?

Het importeren van gegevens werd nog even genoemd. Dit is een kluif werk, maar door middel van EDI (=XML) kan je wel mooie zaken leveren. Wellicht meer werk, maar het sluit netter aan dan eerder genoemde oplossingen.

[Verwijderd]

DiedX schreef op woensdag 15 april 2009 @ 12:52:
[...]


De vraag die ik stel: waartegen bescherm je jezelf?

Het importeren van gegevens werd nog even genoemd. Dit is een kluif werk, maar door middel van EDI (=XML) kan je wel mooie zaken leveren. Wellicht meer werk, maar het sluit netter aan dan eerder genoemde oplossingen.

Tsja ik probeer gegevens te beschermen waar eventueel "misbruik" van gemaakt kan worden als deze bij de concurrent liggen. De gedachte is zo te zien een veelvoud makkelijker als de oplossing. Alles wat je af kan vangen zonder de gebruiker te benadelen in zijn werken is denk ik een goed iets. Dit leek me nu net zo'n puntje. Je benadeeld de gebruiker niet want die kan inloggen en zijn ding doen en je inloggegevens zijn beschermd. Tis ook net hoeveel waarde je er aan toekent, hier doen we dat nu wel maar als we misschien dadelijk horen dat het kan maar tig duizend euro kost word de noodzaak misschien ook anders
Sommige vinden ook dat stagelopers op de IT afdeling het admin ww moeten hebben want dat is wel makkelijk......ik vind van niet en ben daar altijd nogal wantrouwend in...mischien wel te.

[KillerAce_NL]

Niet iest mogelijk met b.v. roboform en encrypten ofzo ?
Ik denk maar mee...

[DiedX]

Verwijderd schreef op woensdag 15 april 2009 @ 13:45:
[...]


Tsja ik probeer gegevens te beschermen waar eventueel "misbruik" van gemaakt kan worden als deze bij de concurrent liggen. De gedachte is zo te zien een veelvoud makkelijker als de oplossing.

Dan zou ik het professioneel aanpakken, en kijken of de leverancier zelf gegevens kan ontsluiten dmv XML/EDI oid. Weet jij wat er mogelijk is?

[Verwijderd]

RaZ schreef op woensdag 15 april 2009 @ 10:45:

Een andere optie is gewoon een soort van portal te maken waarbij er niet meer dan een POST-methode is, die direct inlogt bij de leverancier. Dan hoeven de werknemers niet eens de codes te weten.

Bovenstaande oplossing kreeg ik net ook door van iemand.
Je hebt schijnbaar de Post en de Get methode en dan moeten wij de Post methode hebben. Het maken hiervan gaat via scripting in PhP of Html.

Nu ben ik geen scripting goeroe. Is dit een idee en zoja is dit lastig om te maken of is dit voor een scripter een eitje ?

[F_J_K]

De allereerste reply in dit topic (die van mij) gaf al een mogelijkheid inclusief een paar pagina's codevoorbeeld. Waar loop je vast / waarom voldoet dat niet?

Geen scriptingguru: het is linksom of rechtsom (of rechtdoor ). Leren zelf doen, door een ander laten doen of niet technisch maar organisatorisch oplossen.

[Rukapul]

F_J_K schreef op donderdag 16 april 2009 @ 16:43:
De allereerste reply in dit topic (die van mij) gaf al een mogelijkheid inclusief een paar pagina's codevoorbeeld. Waar loop je vast / waarom voldoet dat niet?

Elke methode, waaronder die van jouw link, waarbij de logingegevens via de client naar de server worden gestuurd is niet veilig. Een handige Harry weet die wel te onderscheppen. Het voorbeeld uit de link werkt in dat geval wel, omdat het threat model anders is: de user is geen mogelijke attacker en mag wel kennis hebben van de login credentials (maar wil SSO voor het gemak).

Eventueel kan er een variant gebruikt worden waarbij er een aparte machine als proxy gebruikt wordt welke ook de inlog voor z'n rekening neemt. Dat vereist echter wat engineering.

Daarnaast vraag ik me af of zo'n gedeeld account niet allerlei andere security (authorisatie, settings, ...) issues met zich meebrengt in het geval van gedeelde credentials.

Nette (non-hack) oplossingen voor dit probleem zijn:
• proces: individuele accounts bij de leverancier
• technisch: SSO waarbij een lokale authenticatie sessie gebruikt wordt om in te loggen bij de leverancier middels een signed credential (authentication assertion). Buzzword: SAML, maar er is ook zelf wel wat te klussen op deze wijze.
+ combinatie van bovenstaande

[ Voor 29% gewijzigd door Rukapul op 19-04-2009 18:15 ]

[Verwijderd]

We gaan het eens bekijken, moet wel iets van te maken zijn lijkt mij

[Verwijderd]

Een vriend van mij kan wel iets van scripting. Hij maakte een script dat zichzelf inlogde op Smarschool ( een online leerplatform voor scholen ). Zo kon hij kijken als er iets nieuws gebeurd is.
Misschien kan op deze manier ook wel iets gedaan worden. Ik denk dat dit al bij al niet zo moeilijk is. Het enige nadeel is, dat je de interne code van deze site nodig hebt ( als dit met php werkt ), tenminste, dit is wat hij nodig had.
Ik hoop dat je hierdoor al iets verder bent, en wens je nog veel succes