ACTION-11 SSO & Federated Identity

This is a rough first cut, with none of the underlying protocol
handshakes given. 

SAML, WS-Federation and most proprietary Web SSO schemes have flows
similar to these.

Case 0. User establishes TLS session, signs on with username/password
(usually with form post, sometimes http basic auth) server takes down
TLS for rest of session. 
[Should we worry about this case? Although password is protected from
interception, there is no binding to rest of interaction allowing
session hijack, interception of app data, etc. User sees lock during
initial interaction and believes session is "secure." Usual logic is for
performance, however unclear this is even true as most of TLS overhead
is in setup (key exchange.)]


Case 1. User connects to Identity Provider (IdP), signs on, typically
with username/password over TLS, but possibly w/o TLS, or via
alternative such as onetime password from hdw token. User then clicks on
link to Service Provider (SP) which may be in same or different domain
as IdP. Generally user is unaware that distinct site is being accessed.
(By design.)


Case 2. Like case 1 except user begins by clicking on link to SP. App
site detects that no login has been done (typically via cookie) and
redirects user to IdP. Idp does login as in 1 and redirects user back to
SP. Second request is performed without intervention by IdP.


Case 3. Like case 2 except, IdP to use may vary for different users. SP
first determines IdP to user (e.g. by asking user, querying service,
redirecting to canonical location, etc.) then all proceeds as in case 2.


Hal

Received on Monday, 4 December 2006 21:30:51 UTC