Web Application - User Authentication Across Domains

Question

A client of ours has approached us to develop an application, and as usual the scope grows day by day.

Initially it started as a dedicated app confined within their corporate network. User Authentication was established by aquiring the user's Windows login and using a SQLServer Database to host the access rights. All quite straight forward.

They now want the following:
- Application to be Web Based
- Application to be hosted outside of the corporate network
- User authentication to work in the same way (no using passwords, just windows logins)

To complicate it further, they want the various functions of the application to to be usable by another application which just fires of HTTP requests.
- User logs in to corporate network
- User launches corporate application
- User processes customer details
- User clicks a button
- Corporate Application fires a HTTP request to our hosted web app
- HTTP request included necessary authentication and customer details
- User authentication is completed 'automatically' (No human involvement)
- Customer data is transmitted securely

They are very keen for us to do this for them as our initial approach was very much what they wanted. They still want us to do this even though such hosted web apps are not our speciallity. So I now approach the experts;
- Does anyone have any advice on how to approach this?
- Does anyone have any warning about the possible pitfalls to avoid?

Answer 1

I'd use a private OpenID provider/server for this.

Answer 2

Maybe WCF Communciation with Certificate based Authentication i.e. to external users who use the service the company provides them with a valid certificate. This would then not require a username password but take the user straight through.

Answer 3

Did you already have a look at SAML?

Answer 4

Check out Windows CardSpace since it does integrate with your windows login and allows for the SSO scenario they require.

Answer 5

Basically they're talking about federated access. You would host an authentication point inside their network which in turn forwards a token to your application which parses it and allows (or stops access). This is pretty standard, and MS provide a good base for this in the Geneva Framework. This will also work for web service calls providing they can change their application to use WSFed as a protocol and talk to a security token service which silently issues the authentication token. In most cases you'll be using SAML for this. It also has the added bonus of authentication details never going outside of their corporate network.

The suggestion of Certificate Based authentication is an interesting one, but requires more work in rolling out a PKI infrastructure. This can be costly.

CardSpace won't work - it's not silent as they seem to want. OpenID is a non starter as well, it's not silent either.

Extra points if you're looking at Azure - the authentication bits of Azure also use SAML/WSFed under the hood, and has bits of Geneva in it. So if you moved to the cloud then each of your customers would just have to configure a login page within their network - all you would have to do is trust that page to issue authentication tokens to you and parse them according to your rules.

Answer 6

Depending on how your app is constructed, you can fiddle with the machineKey in your web.config to allow for AJAX calls with single-sign-on (SSO). This would involve an small asp.net app within the corporate network just to dish out authentication tokens and redirect to your hosted app.

If the two apps share the same machineKey then the asp.net authentication system will happily allow users into your hosted app.

There are problems with this approach:

• You introduce another dependency into your system (the authentication app within the corporate network.) It'll be a simple app, but you will face problems when trying to diagnose problems if you don't have access.
• You need your hosted service to the in the same domain as the authentication app (so the authentication ticket in the HTTP cookie gets passed around.)
• You'll also need an SSL certificate for your hosted service to secure the information. (Not really a downside per-se, you'd probably want to do this anyway.)
• Because you and your client will have a shared machineKey, you will tie down an instance of your app to that particular client.