We have several customer using our web application (not intranet), some customers want their login should be integrated with their organizations Active Directory. They just want that user should login to their windows account and can access the web application without entering any user credentials.
I have read some articles regarding ADFS, but still not sure how to integrate that or implement it. Any proposed solution ?
Thanks!
If you develop a .NET based application, Microsoft provides a library called WIF, which is used to communicate with the AD FS in a +- comfortable way (configuration + little code adaptations to get the claims from the authentication message provided by the AD FS).
There are few protocols that both AD FS 2.0 and WIF support, to make the SSO work, the most common ones are (afaik) SAML 2.0 and WS-Federation. Both are built on XML messages, but you are not required to know the details, if you use WIF.
For WS - Federation, the WIF library provides a plugin for Visual Studio, which allows you to configure your site as the relying party with your AD FS.
You CAN use the credentials within your DB to identify users, you can actually customize AD FS's entire login page and authentication events. However the basic installation requires each user to be defined within your Active Directory. You can also use your DB as a claims store (another data base AD FS will use to provide the relying applications with information about users). Note that if you intend to use an AD behind the AD FS, your AD FS service must be able to access it and LDAP query it, which I'm not sure will work for you, if your users login to their local domain that the AD FS is not familiar with.
IF you are not required to support industry SSO standard protocols (SAML 2.0 I've mentioned), I'm not sure implementing AD FS will be such a good solution. It forces you to work in a certain way, which is not always that comfortable.
Your question doesn't explicitly state that whether you are limited to using ADFS for implementing SSO. ADFS is certainly one way of doing this. You may want to look at OpenID-LDAP (was at www.openid-ldap.org, but project is now defunct) and other identity providers as alternatives for implementing SSO.
One alternative is to implement an OpenID provider that uses integrated windows authentication. They can install it in their DMZ exposing that to the internet, instead of ADFS. It may allow single sign on from Internet Explorer and Chrome.
Implementing an OpenID provider is a non trivial matter. You'll have to pay close attention to security. Fortunally, there are a number of frameworks like DotNetOpenAuth that may help you.
When using OpenID, your "cloud" application will act as an OpenID rely and get a claimed identifier amongst other attributes from the OpenID provider. You should store this in your database to uniquely identify the user. You may choose to implement the OpenID provider such that it can also provide your cloud application with the minimal information like email address, the person's name etc.
The benefit of using OpenID is that your "cloud" application can continue to support other well known OpenID providers like Google and Yahoo without much change.
In the end you'll need to ask your customers what technologies they are comfortable with. You'll find that a lack of trust (a business trait) between organizations is more often than not the challenge rather than technology.
More detail needed as per comments.
There's a good source here: AD FS 2.0 Content Map.
The "e-book" is here.
I could imagine one scenario where you bind your cloud application to Azure ACS, your customers install ADFS on top of their AD and federate their ADFS with ACS. That would give you the functionality you require.
Update after comment:
ADFS can only authenticate against AD. It cannot authenticate against a DB. It can get attributes from a SQL Server DB which it can then transform to claims i.e. it can use a SQL DB for authorisation.
If you want to authenticate against a SQL DB, you can two choices.
