tags:

views:

915

answers:

3

Client requires major applications to provide users with “single sign on” authentication feature based on the corporate solution (Active Directory). This means the business application trusts the credentials provided by the browser and does not request user to provide standard login/password pair. The server/browser trust is built on Windows Integrated Authentication mechanism.

Ours is an ASP.Net Web application on dot net framework 2.0 hosted on IIS 5.We need to implement the SSO feature.How do we do it?

A: 

In general, SSO requirements are best addressed by Claims-based protocols such as WS-Federation or SAML 2.0. In principle, you can implement these protocols yourself since they are open standards, but it requires a lot of specialist knowledge.

The new Windows Identity Foundation (formerly known as Geneva framework) contains protocol implementations that can enable SSO scenarios, although it will require you to upgrade your platform.

Mark Seemann
+3  A: 

I'm pretty sure this is the same requirements that almost all intranet apps follow.

If you just enabled Windows Integrated Logins in IIS, then you'll be set for the #1 item.

I don't know if #2 is even possible, because it conflicts with your other requirement. The browser only passes the locally logged in user's credentials (as required by #1). If you built a web form to authenticate via AD, then you would be in violation of the requirements listed in your narrative/paragraph.

What do your clients think #2 really means? What do they want here? A way to log in as a different user? They can just log off the computer and log in as the other user.

Jim W
A: 

Use Custom Forms Auth instead that wont ask user to enter ID and password.

Prerequisites: 1> Database table having user details such as email, role etc 2> Enterprise active directory where user profiles are stored 3> Write a VBCOM or ActiveX or other components that can read user's domain and name from the windows machine through browser.

Steps: On pageload for all the forms call the component<3> to connect to Active Directory<2>. That method should read current user's name, domain from windows system. Search AD with these details. If exists then query and extract the email address or whichever is the unique key in the AD user profile. Using this key query the database<1> where you stored application specific user details such as email, roles. If user email from AD match with email in Table then grant the user appropriate rights else deny access if user does not exist or role is null/restricted. If valid user then create a cookie that is encrypted and can be read by other applications to really implement any sort of SSO.

patkap