Skip to content
Central Login for All My Applications
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
lib
src
.gitignore
LICENSE
README.md

README.md

AK-Login

By Aashish Koirala

This is the central login system that I use (or am in the process of migrating them to use) for all of my applications. Once you log in using this application, the idea is for you to be able to navigate to any of my applications without logging in again or having a separate user account. When you navigate to one of my applications and are not logged in (or don't have a user account), you will be redirected to the login page that is hosted by this application. The login page will display information about the target application and will let you login using a number of providers (such as Google or Facebook).

Technical Overview

AK-Login uses Windows Identity Foundation (WIF) as its core component. It acts as a passive STS (Security Token Service) while dividing the role of IP (Identity Provider) between the target application (or "Relying Party") and one or more third-party providers such as Google or Facebook. It is built so as to be able to support multiple protocols between the Relying Party and the STS, but currently only WS-Federation is implemented. I hope to build in support for SAML and OAuth at some point in the future.

I also hope to integrate more identity providers other than Google and Facebook (and perhaps also extend this to be an identity provider itself) at some point in the future. The third-party providers are used for authentication, but the responsibility of storing whatever user information is needed by each application is the responsibility of that application (thus my statement that the identity provider role is divided between the Relying Party and the third-party Identity Providers). Another plan for the future is to enable this to be an Active STS (i.e. an endpoint that any application can use to get authenticated and get back a token - that will primarily be useful for mobile applications).

How It Works

  • Each Relying Party is registered with the application through configuration - needs to have three settings populated: the realm URI, the reply-to URL and the login service URL.
  • The realm URI is a unique identifier for the party - an example being **urn:**ApplicationName.
  • The reply-to URL is the URL that this application will redirect to once the user is authenticated. + This is usually the main entry point URL for the Relying Party application.
  • The Relying Party also needs to implement a WCF service with a predefined contract (defined in ILoginService - available in the Commons Library). The service is responsible for providing information about the application as well as any given user to AK-Login, as well as exposing a way to create new users to AK-Login.
  • The Relying Party application then needs to be configured for WIF and with AK-Login designated as the token issuer. There are methods available in the Commons Library that facilitate this.
  • Communication between the Relying Party and AK-Login is encrypted and signed using a shared X.509 certificate.
  • When you navigate to a protected endpoint in the Relying Party, and are not authenticated, you are redirected to the login page hosted by AK-Login. This redirection request is generated by WIF and follows standard WS-Federation protocol
  • AK-Login then uses the realm information passed in the request to look up information about the party. It gets more information from the Relying Party using the ILoginService WCF endpoint. It uses this to display application-specific information in the login page.
  • From the login page, you can use Google (using it's OAuth API) or Facebook (using its JavaScript API) to authenticate yourself.
  • AK-Login then communicates with the Relying Party using the ILoginService WCF endpoint to see if a user matching credentials just provided by Google or Facebook exists. If so, it uses this information to instruct WIF to write an encrypted session token cookie, and redirects back to the Relying Party reply-to URL - where it is now authenticated thanks to the encrypted session token cookie.
  • If a user is not found, AK-Login prompts you to enter a display name for the user that is going to be newly created. Once you provide the information, the ILoginService WCF endpoint is again used to create a new user record in the Relying Party application, and the rest of the process is same as above.
  • When you logout from the Relying Party application, WIF sends a logout WS-Federation message to AK-Login which takes care of processing the logout operation.
You can’t perform that action at this time.