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?
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.