Say SSO one more time :)

Honza @Novoj Novotný

The task was simple

Client has several high traffic sites and e-shops on different domains. He wanted to consolidate user accounts in a single place and share accounts among them.

AND SO WE DID IT

... HAVE A LOOK ...

But SSO is "solved" problem, isn't it?

Problem solved!

What enterprise solutions offered:

Enterprise!

  • multiple systems federation - email clients, wiki, revision controls
  • LDAP / ActiveDirectory integration
  • complexity + costs

They're much more suitable for "intranet" usage than for e-shops.

What OpenId, OAuth offered:

OAuth!

  • proven concept
  • several implementations

Very good to accept outside identities to create internal accounts in the e-shop. Not much suitable to transfer logged user among the shops (any idea?).

What were our starting points?

  • websites are owned by the same organization
  • no external applications needs to share authentication
  • single shared database with accounts accessible from all websites
  • request for natural registration and login process in each of site
  • request for diversity of the profile and reqistration in some sites
  • fast homepage access (no redirects if possible!)

Maybe too simple for "enterprise" solutions?!

Why is it so hard?

  • user sessions are located by cookies
  • cookies are not shared between different domains of the same level
  • the only solution is to use shared account domain

Mmm, the problem doesn't sound that difficult. Does it?!

How is it usually done?

SAML message exchange model for achieving Web SSO looks like this:

Credit: http://www.cs.wustl.edu/~jain/cse571-07/ftp/websso/

How we did it?

Mechanism #1

1. user visits https://www.fraus.cz

2. page embeds https://account.fraus.cz/user/www.fraus.cz/123abc

3. account server stores into session and DB: USER NOT LOGGED IN
www.fraus.cz = token 123abc

4. account server returns user is not logged in (public JSON)

5. user logs in on https://www.fraus.cz against shared user DB

6. www.fraus.cz securely sends information to account server about user login USER novoj LOGGED IN
www.fraus.cz = token 123abc

Mechanism #2

1. user visits https://www.flexibooks.cz

2. page embeds https://account.fraus.cz/user/www.flexibooks.cz/567def

3. account attaches new token to existing session and DB: USER novoj LOGGED IN
www.fraus.cz = token 123abc
www.flexibooks.cz = token 567def

4. account server returns novoj is logged in (public JSON)

5. www.flexibooks.cz verifies securely that novoj is logged in for token 567def

6. account server confirms novoj is logged in - it paired both tokens through single session

7. www.flexibooks.cz refreshes page contents and display correct user prices

Challenges

  • clustering - 2x2 nodes
  • synchronizing session with background API requests
  • tolerance to different invocation order (login before lead token request)
  • ensuring single session active for user over all devices

Thats it!

Honza Novotný, FG Forrest
@novoj
http://blog.novoj.net