[PHP] OpenId, multiple sites, multiple domains, SSO?

[Rekcor]

Ik ben me aan het verdiepen in OpenId, maar er zijn zoveel bomen, dat ik het bos niet meer zie

Wat ik wil:

• de gebruiker logt in op www.site_a.com m.b.v. OpenId op OpenId provider X
• www.site_a.com praat tegen www.site_b.com
• www.site_b.com praat tegen www.site_c.com
• www.site_a.com toont resultaat www.site_c.com

Nu moeten site_b en site_c.com wel weten of de gebruiker ingelogd is. Wat is de beste manier om hiervoor te zorgen? Mogelijkheden die ik ben tegengekomen:

1. site_b geeft variabele 'loggedIn=1' door aan site_c
2. site_b geeft hash van username, pw, timestamp, salt door aan site_c
3. site_b geeft sessieId/token door aan site_c
4. site_b en site_c vragen aan OpenId provider X of gebruiker is ingelogd.

[Sgreehder]

Even melden welke gebruiker is ingelogd is voldoende (en uiteraard veel veiliger). Verder gebruik je dan deze methode:

Wikipedia: Hash-based message authentication code

Jouw sites onderling controleren dan zo of ze zeggen wie ze zijn dat ze zegggen. En dat het bericht dat werd verstuurd ook niet onderweg aangepast is.

[ Voor 9% gewijzigd door Sgreehder op 09-03-2014 08:15 ]

[Rekcor]

Bedankt!

Even kijken of ik het goed heb begrepen.

• Gebruiker logt in bij site A
• Site A zegt tegen site B: hier heb je een userId + bericht X + een salted hash van o.m. userId en bericht X
• Site B kijkt of hash klopt --> ja --> user is ook geauthenticeerd bij site B
• Site B zegt tegen site C: hier heb je een userId + bericht Y + een salted hash van o.m. userId en bericht Y
• Site C kijkt of hash klopt --> ja --> site C doet wat met bericht Y.
• Site C zegt tegen site B: hier heb je een userId + bericht Z + een salted hash van o.m. userId en bericht Z
• enzovoort

[Janoz]

Je doet het veel te moeilijk.

OpenId heeft ten eerste helemaal niks te maken met je probleem. OpenId is alleen van toepassing bij de eerste inlog. Jouw probleem gaat over de 'handoff'.

Je moet niet moeilijk gaan doen met userId's en berichten en weet ik veel wat. Je moet geen afgeleide gegevens gebruiken. Wat je wel meot doen is het voglende.

Zodra de gebruiker op een link drukt om naar de andere site te gaan stuur je een token naar die andere site samen met de userId (door bijvoorbeeld een URL aan te roepen vanaf de server van site A naar site B. Deze URL mag alleen door site A aangeroepen worden). Dit token onthoud Site B voor ongeveer een seconde. Vervoglens forward je de gebruiker naar site B met dat token. Site B heeft via een vertrouwd kanaal de userId ontvangen die bij het token hoort en de gebruiker is ingelogd bij site B. Token kan 1 malig gebruikt worden en leeft kort waardoor een replay attack tot het minimum beperkt wordt.

[Alex)]

Als ik je verhaal zo eens lees heb je geen behoefte aan OpenID, maar zou je meer gebaat kunnen zijn bij een implementatie van OAuth (zoals o.a. Twitter gebruiken). OAuth kent een technologie, OAuth Echo genaamd, waarmee je de credentials kunt delegaten naar een andere partij.

Afgezien daarvan, waarom doe je zo moeilijk met drie sites die de gebruiker gaat bezoeken voordat hij wat informatie kan zien? Waarom kan site_A dat niet meteen?

[Rekcor]

Bedankt! Ik ga Janoz' oplossing implementeren.

@Alex): het idee is dat e.e.a. uit een set services bestaat, die in principe los van elkaar staan. Dit is handig, bijv. vanwege herbruikbaarheid van een service.