About web, sessions, and SSO

1

• About web, sessions, and SSO
• Oslo, 2007-06-12
• Andreas Åkre Solberg
• andreas_at_uninett.no

2
Session handling in HTTP

• HTTP from the beginning was state-less.
• Cookies introduces states inrfc2965 HTTP State
  Management Mechanism
• Cookies let you establish a browser session
  between a HTTP request and the subsequent
  requests.

3
Cookies

• Browser sends a Set-Cookie header in the HTTP
  reponse, connecting attribute-value pairs to the
  relevant host.
• Browser will keep the attribute pairs for some
  time and send them back to the server in a
  Cookie header for every HTTP request to that
  host.

4
Session data client-side

• Sending the session data to the client, and let
  the client send everything back for each request
• Not Effective
• You can not trust that the same values are send
  back
• Data is visible to user

5
Session data server-side

• Server generates a random session ID,
• Sends the session ID to the client in a
  Set-Cookie.
• Stores session data server-side in a hash-storage
  with the session ID as a key.

6
Session data server-side
7
Cross-site sessions

• Cookies can not be used for cross-site sessions
  directly, because they are related to domain
  names.
• A concept used in many WebSSO protocols
  introducing a central server that keeps a session
  with the user, and all services communicates with
  this central storage.

8
Central session model and WebSSO

• If you keep an authenticated session in a central
  place, then others may asks whether the user is
  authenticated over a secured front-channel
  protocol.

9
Central session
10
Front channel communication

• Front-channel communication means that when host
  A sends a request to host X, then it is an
  redirect via the users browser. In example
• 510 Temporary redirectLocation
  http//x.com?messageltrequestgt
• Front-channel communication is asynchronous and
  allows
• Central host to get browser cookies
• Central host to get control of user interaction

11
Back-channel communication

• Messages sent between hosts without the user
  noticing, not visible to browser.
• Example SOAP
• Usually syncronous request/response
• Receiving host cannot map to the correct session
  because cookies are not accessible.

12
Securing communication

• Front-channel communication can be modified by
  user even in encrypted (HTTPS), because browser
  decrypt and encrypt again in a redirect.
• Messages then needs to be signed, and sometimes
  encrypted.

13
Web Single Sign-On

• Host A asks whether user is authenticated?
• Host X gets UI control and asks for credentials.
• Creates a central authenticated session
• Responds with signed message to host A.
• Host A verifies message and creates local session
• Follows a link at site to host B
• Host b has no session and asks central host
• Host x looks up existing session and responds
  with signed message.
• Host B verifies message and creates local
  session.

14
Single logout

• Message exchanges to ensure sessions are killed
  or invalidated accross multiple hosts.

15
Last slide

• Questions?