Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

At my current job (we're in a MS environment), we have multiple deployed web applications, both inter/intra net. The internal apps generally use an Active Diretory sign in, the forward facing sites each have their own membership implementation. Some use a custom provider we wrote, some use Asp.Net membership.

Yes, we have created a problem for ourselves. The question is how to fix it.

What would be the best (or at least good) solution for a authentication/authorization service that would allow us to consolidate sign in to one place? Should we implement an oAuth/xAuth provider? Something else?

Some questions I was thinking of:

  1. Should roles be left to each application to implement? In general, we could think of each resource as having CRUD permissions and perhaps decorate controller actions with required permissions.

  2. We have a few really, really legacy web apps (.Net 1.1) that mostly just sit there and run. Where should we draw the cutoff for what we apply this new service to?

If there's something else I should be considering, please let me know.

share|improve this question
Since you're in an MS environment, how about configuring SSO on Sharepoint ? – Jas May 19 '11 at 13:04
Are you trying to move to single sign-on? If not, OAuth might not be worth the hassle. Although it appears that with the new Windows Server App Fabric (wish they wouldn't re-use the name because it causes confusion with the Cloud version), creating an OAuth provider sounds like it's a bit easier nowadays. – Michael Brown May 19 '11 at 13:43
Well...It wasn't until recently ASP .NET even had its own authentication system built in. My suggestion would be to use windows authentication for intranet stuff at the very least. – Ramhound May 19 '11 at 15:05
Single sign-on is what we are looking for, yes. One of our problems, for example, is the proliferation of developer accounts on the various sites, requiring manual cleanup. AppFabric, I hadn't thought of that. Hmmmm.... – KevDog May 19 '11 at 15:29
up vote 2 down vote accepted

To answer the specific questions first:

  1. Roles are always application specific. Unless your applications either have very, very similar role requirements or are very simplistic, I would not attempt to centralize role management
  2. You should draw the cutoff at the point where the effort outweighs the benefits.

Now to the more generic question:

Since all your internal apps use AD already, I would probably go down the road of adding a separate entity in AD for "Guest Users", which could hold simple user accounts for all external users, and then upgrade all external apps to also use AD. In which case you can then use a centralised oAuth provider for single-login. And if your web apps are written on different platforms, then write a little frontend to expose the oAuth provider as a web service, similar to OpenID.

share|improve this answer
In case there are only applications that can easily be adapted to support AD in his environment (ASP.NET apps in principle can), he doesn't even need an oAuth provider for single-sign-on. – oleschri Jul 21 '11 at 9:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.