Einmal einloggen und in mehreren Applikationen eingeloggt sein

Hallo,

ich bin gerade dabei für meine Masterarbeit ein Browsergame zu programmieren.
Hierfür verwende ich ASP.NET 5 MVC 6, SignalR 3 und AngularJS.

Ziel ist es, dass sich der Spieler einmal einloggt und dann im Benutzerportal landet.
Dort sieht er, in welchen Welten des Spiels er einen Charakter hat und soll dann mit einem Klick den jeweiligen Charakter in der Welt spielen.

Ich hätte gern für jede Welt eine eigene gestartete Instanz der Spielanwendung.
Diese werden nicht unbedingt auf dem selben Server ausgeführt.
Das Portal soll unter www.domain.tld und die einzelnen Welten unter den Subdimains welt1, welt2 usw. erreichbar sein.

Nun zu meiner Frage:
Wie kann ich es ermöglichen, dass der der eingeloggte Spieler auch in den Welten als eingeloggt erkannt wird? Ich habe schon von distributed session states gelesen, weiß jedoch nicht, wie ich das mit Identity verbinde.

Gruß pinki

Sowas nennt man Single-Sign on (prinzipiell).
Du musst im Cookie setzen, wie tief und welche Subdomains auf diese Session Zugriff haben.

Sofern Du noch SSL Zertifikate verwendest brauchst Du ein Wildcard Zertifikat.

Wenn Du Login auf domain.com ermöglichst, dann kann das auch für *.domain.com gelten.
Ein Login auf welt1.domain.com gilt aber nicht auf welt2.domain.com; aber kann für api.welt1.domain.com gelten.

Super, danke für die Info!
Nutzt Identity denn automatisch den Distributed Cache, wenn ich folgendes hinzufüge oder muss ich den noch irgendwie zusätzlich bekannt machen?

public void ConfigureServices (IServiceCollection services) {
    [...]
    services.AddCaching();
    services.AddSession(
        options => {
            options.IdleTimeout = TimeSpan.FromMinutes(30);
        }
    );
    [...]
}

public void Configure (IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerfactory) {
    [...]
    app.UseDistributedSession(
        new MongoCache(
            new MongoCacheOptions {
                ConnectionString = Configuration["Data:DefaultConnection:ConnectionString"],
                Database = Configuration["Data:DefaultConnection:Database"]
            }
        )
    );
    [...]
}

Wie abt sagte, geht SSO über Keks oder aber auch über reine Umleitung via Session. Geht also auch per UrL. Es gibt viele Verfahren. Für kleine Seiten lohnt sich eher ein "Abo" der grossen Seiten:Facebook, Google, MS. Ein eigenes SSO nur bei hohen Ansprüchen.

ikaros, wie genau hilft hier ein SSO von FB und Co?
Das schränkt ja die Nutzer immens ein.

Ein Distirbuted Cache allein sagt mal nichts aus.
Damit ermöglicht man primär, dass die Sessions auf mehreren Servern funktioniert, da ansonsten jede Webseiten-Instanz seinen eigenen Cache hat - und das "geht" natürlich nicht.
Egal auf welchem Server eine Webseite betrieben wird und Dein Request behandelt wird; die Session soll ja bestehen bleiben.

Was für Dich eben interessant und wichtig ist, ist der Rahmen und die Umgebung, in der eine Session gültig ist.
Mir ist noch nicht ganz klar, auf welchen Subdomains Dein Login erfolgen und gültig sein soll.

Wenn Deine Session einfach nur auf allen Domains gültig sein soll, dann reicht

<httpCookies domain=".domain.com"/>

in der Web.Config.

Achte drauf, dass alle Applikationen den gleichen Machine Key in der Config haben, sonst sind die Sessions ungültig.

Es vereinfacht und stellt eine gewisse Sicherheit bereit.
Ein eigenes Verfahren bedeutet einen höheren Aufwand und oft auch mehr Angriffsfläche(bei schnellkram).
Was die richtige Entscheidung wäre hängt von der Applikationsvernetung und vom Anwendungsfall ab.
Für reines WWW mit Kram den jeder angemeldete lesen darf ist diese Art von SSO genehm und günstig und praktikabel.
In anderen Fällen sieht es natürlich anders aus und der Ersteller der Lösung bräuchte einen mindestKurs(in security)oder so, und muss es umsetzen können..

Du hast kaum weniger Angriffsfläche; Du gibst sogar die Hoheit der Kontrolle nach extern aus und musst "blind" vertrauen.
Angesichts des Hijackings von Konten von FB, das man immer wieder hört, würde ich das nicht als höhere Sicherheit bezeichnen 😃

Das Hosten eines OAuth 2.0 ist kaum komplexer als normales Identity Managament.
Es ermöglicht Dir sogar die Verwaltung der Logins pro Gerät, was bei einer eigenen Implementierung umständlicher ist.

Und OAuth2.0 Clients gibts wie Sand am Meer - für alle Stacks und Plattformen.

Davon abgesehen sehe ich hier die Anforderung eines OAuth2.0 Stacks gar nicht 😉
Im selbst bringt das jetzt ja auch nichts, denn die Beschränkung wäre ja ebenfalls pro Subdomain, sodass er sich bei jeder Subdomain erneut authentifizieren muss und er bei Facebook jede Subdomain auch anmelden muss 😃

Da wäre also die Maßnahme des Config-Eintrags genauso notwendig.

Die deinerseits Antwort ist eine Technologie die erstmal beherrscht werden muss.
OAuth ist kein SSO, man kann es aber implementieren.
Und da fängt der Zirkus wieder an.
Es ist besser für kleine Dinge was zu nutzen als eine komplette SSO sinnlos neu zu implementieren.

Ähh ja. Genau deswegen meine Frage wieso Du bei SSO Facebook und Co erwähnst, wenn diese hier auf den ersten Blick ersichtlichen Anforderungen einfach nur durch einen entsprechenden Config-Einträg abgedeckt werden 😉

Es ist die einfachste Form von SSO.

Problem ist das Vertrauen.

Dein seltsamer ConfigEintrag ist kein SSO. Es ist nur lokal. Nicht übergreifend.

Was meinst Du es sei nicht vertrauend, nicht übergreifend?
Wenn Dir die Domain gehört, dann vertraust Du mal pauschal Dir - und es ist übergreifend 😃

Ich denke das Vertrauen hier is deutlich höher als jetzt FB und Co ins Boot zu holen, wenn es gar nicht nötig / gewünscht ist.
Und SSO ist es dann implizit über einen gemeinsamen Cache und dem gültigen Cookie. Die einfachste Form eben.

Es kann genauso gut sein, dass er alle Subdomains über eine Applikation abbildet und es einfach über das Routing trennt.
Dann kannst Du sogar den externen Cache weglassen und kommst trotzdem an das "Shared Cookie".
Es ist ja explizit so gewollt (im RFC Standard), dass das funktioniert, wenn man es definiert.

Innerhalb der gekauften Domain, natürlich kein Problem. Geht auch mit Config 😉
Hier ging es aber um SSO. SSO ist Domainübergreifend und auch Netzübergreifend. Kann sein das wir uns da missverstanden haben.
SSO ist einmal Einloggen für verschiedene Dienste unter anderem auch Websites unter verschiedenen Domains.

Naja ob es SSO ist oder nicht das ist so gar nicht 100% erkennbar.
Das hab ich mal rein geworfen aus dem Grund, dass man das Prinzip an für sich so nennt.
Wenn man das ganz arg streng sieht, dann würde sich SSO im ursprünglichen Sinn ohnehin auf die lokale Umgebung begrenzen.

Er will ja prinzipiell erstmal von verschiedenen Subdomains auf eine Session zugreifen.
Und wenn er pro Subdomain ein Stack hat dann kann man das durchaus als SSO bezeichnen; meinetwegen aufgrund des impliziten Verhaltens auch SSO-light 😉

Es kann aber genauso gut alles über eine Anwendung abgedeckt sein und er will nur das Sharing aktivieren.
Ich würd das nicht so eng sehen mit dem SSO; vor allem da wir hier eine abstrakte Schicht haben, die uns das "Feature" schenkt 😃

Ich ging halt von echtem SSO aus.
So war imho die Fragestellung.
Bei Subkram vonAnwendungsstapeln sieht es natürlich anders aus. Auf einem Sever 😉

Besten Dank für eure Hilfe! 👍

Durch den Tipp mit den MachineKeys bin ich auch auf diese Seite aufmerksam geworden:
Sharing cookies between applications. - ASP.NET 0.0.1 documentation