[thelist] Single Sign On Security

[Bill Moseley]

Sorry, this is a bit wordy.  In short I'm looking for pitfalls and security
issues you may be aware of when implementing Single Sign-On as well as
implementation suggestions.    I'm aware of OpenID and  OAuth approaches.
 In this case we will create a custom implementation.

I have a subscription site -- people normally create an account and log in
with their username and password to use my site.

A third-party partner site wants to provide access to my site but bypass my
account creation and login screens.  They want to have a sign-up form on
*their* site and then provide access to my site.  My site will still need an
account created for each user first, so that means I need an API to allow
the third party site to create an account and then provide a way to redirect
to my site bypassing the login page.

I'm looking for ideas how to make this easy for the third-party site, yet be
secure.

Note that once the user's account has been created on my site (by the
third-party site) the user would be able to directly log into my site
avoiding the third-party site completely.


The process might go something like this:


   1. User goes to third-party site and creates an account with a username
   and password.
   2. User logs into third-party site (if not part of the account creation
   process).
   3. User wishes to access services provided by *my* site via the
   third-party site.
   4. If not already done, third-party site uses a background API call to my
   site to create an account on my site, passing along username and password.
   5. Next, third party site makes a background API call requesting a URL to
   access my site.  My site creates the URL and returns it.
   6. Third-party site sends a the end-user a redirect to this URL.
   7. My site sees this URL and "logs in" the user, avoiding the login
   screen.
   8. End-user uses my site.


The biggest thing I don't like about this is that the end-user has given
their password to the third-party site, and now my site has that password.
 Yes, OAuth is a solution for that problem.  But, for now assume we don't go
that route.

Problems I see are for the account creation process (well, any third-party
request):

   1. Avoid man-in-the-middle modifications in transit: SSL addresses this.
   2. Make sure requests can not be replayed (Replay Attack): SSL again.
   3. Make sure requests come from authorized user:
      1. Can limit by IP address, although that only works if IP is static
      and known, no proxies, etc.
      2. Use authentication credentials (password/shared key)

Is that enough?

I've seen recommendations to have a shared key and then the third-party
creates a hash of some specific data in the request and then on my server
also compute the hash to make sure they agree.  But, that seem redundant.
 Seems SSL plus a password/secret in th e request achieves the same thing,
no?


Now for the single sign on, again the third-party application requests a URL
from my server.  Then the user is redirected to this URL. This URL bypasses
my login screen and logs in the user, then issues a redirect setting a
cookie and establishing a session.

The risk here is that the URL is leaked.  So, my plan is to make a
single-use URL that is short lived.  The idea is the third-party site should
fetch the URL and it is only valid for a short amount of time (about a
minute) and can only be used one time.

Thanks -- and thanks even more if you actually read this far.




-- 
Bill Moseley
moseley at hank.org