I have 3 ASP.NET MVC websites running with Entity Framework on SQL-Server. Each site runs as an independent app with independent databases. I want to enable business clients to create "Passports" aka tokens that allow them to login into one site while simultaneously logging them into other sites. In order to log into a site, the passport must have a valid"Visa" issued via the Passport system, Passports can be administrated with a Passport Site Manager, which can be used by administrators to access user account information from websites A,B, and C and do admin stuff. In a sense, a Passport can be thought of as having one-to-one correspondence with people's real identity.
Here are my questions, how do I pass a user login attempt from site A to check it with the passport database, and return the result to Website A? How do I keep this communication hidden? In other words, so that only the Website apps A,B,C can check a login attempt with the passport database? Should there be another app that provides that interface? Would it be an ASP.NET Web API?
The second part of my question, once a user logs into site A, they should not have to retype their credentials to get into sites B and C. Instead, upon logging into site A they create sessions with sites B and C, or generate a key that can authorize sessions with sites B and C. What would this process look like?
I'm not looking for a complete solution, but If you can point me towards an example, towards the documentation for the technologies/libraries/objects I would find useful.
What you are looking for is available in Windows Identity Foundation. Look through the developer kit on the site and what you want is fairly easily accomplished.
Your "Passport Site" is referred to as a Security Token Service(STS). Website A,B and C are called Relying Parties (RP). Considering a simple case where you implement your STS using ADFS 2.0 (all your users are maintained in Active Directory). Windows Identity Foundation (WIF) has ASP.NET authentication modules that can work out of the box with ADFS 2.0 over SAML. The STS represents user information in form of "Claims" and creates a X509 signed token with all the claims and provides that as a cookie to the user. RPs can read the token, verify the signature and use the claims for their authentication and authorization purposes.
A sample flow is explained below:
a. User visit's Website A for first time
b. Consider now that the user visits Website B.
User did not have to log in again with his user name and password.
The complexity of this system is handling individual site log outs and communicating log out of a user across multiple RPs. There is also a need for maintaining the correct SSL certificates as the whole system relies on it.
Some cases also have an "Active" scenario (the one I described was "Passive" with the browser doing all the running around) where programmer has to code the redirects.