Skip to content

Instantly share code, notes, and snippets.

@bloudermilk

bloudermilk/soa.md

Last active December 9, 2015 20:18
Show Gist options
  • Save bloudermilk/4322403 to your computer and use it in GitHub Desktop.
Save bloudermilk/4322403 to your computer and use it in GitHub Desktop.
Download ZIP
A collection of notes/resources on implementing SOA.
Raw
soa.md

Single sign-on in a service-oriented architecture

The following document outlines a basic design for implementing single sign-on in a service-oriented architecture with many user-facing apps. I have posted it here hoping to get feedback, so don't be afraid to fork and/or comment with your thoughts.

The design relies on two main components in addition to the user-facing servers (apps) and app-facing servers (services):

  • An authentication proxy that sits in front of all apps
  • An authentication/authorization service that manages user accounts

Auth Proxy

A simple HTTP proxy is used to field incoming requests and integrate a central authentication and authorization service with all user-facing applications. The proxy is responsible for handling two basic scenarios, outlined below.

Users without authentication cookies

A request from a user that is not authenticated (no auth cookie present) gets passed immediately to the appropriate app. From there, two things can happen:

  • If the app responds with 401 Unauthorized the proxy responds to the original request with 302 Found, setting the Location header to the login/register page of the SSO service.

  • If the app responds with any other status code the proxy simply forwards the reponse to the user.

Handling authenticated users

When a request comes in from a user that has an authentication cookie the contents of the cookie are passed to the Auth Service via an HTTP endpoint which responds with the user's account information (unique id, email, roles). The account information is then passed to the app (and every service the app communicates with) via TBD.

Auth Service

Questions

  • Does this make sense at all? Have we effectively decoupled auth from the various apps and their backing services?
  • Is there a better status code to use in place of 401 when apps require authentication? In order to be rfc2616 compliant we would have to specify some arbitrary WWW-Authenticate header field, which could be bogus (e.g. WWW-Authenticate: Null) and technically compliant, or meaningful (e.g. WWW-Authenticate: AuthService) and tightly coupled.
  • What should we use to pass account info arround the system? Headers? Params? Probably not params...

Concerns

  • Authentication cookie processing needs to be

Tools

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment