Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been working on an ASP.NET MVC 4 application that uses forms based authentication. Users are validated against a membership provider based on a provider selection on the login form. For example, at this moment there are two providers: active directory and a custom provider that calls an external web service. If the user is valid then we update information in our local users table, like last logon date, etc. If the user is valid and doesn’t exist in the local users table, we add them. Once all of this is done we set a cookie and move on to the main content. All of the controllers check User.Identity.IsAuthenticated and return to the login page if the test fails.

Now I am told that this application is going from a single web application to a multiple application solution. Each application should exist independently from the others, share the same look and feel, and use the same login functionality. Each application can require a new membership provider to be added. We will also add data for limiting access to the applications. One user may only have access to one of the applications while another user has access to all of them.

Setting up the data storage is not a problem. Sharing the layout from one application to be used in the others is not a problem either. What I am having trouble with is deciding how to “refactor” the login functionality such that adding a new membership provider and application “down the road” will not require us to republish existing applications. Right now they would also not want a single sign-on launch page for the applications. They would like for the users to go straight to an application, login, and do what they came there to do. Thus, I may go to http://site1.mysites.com, login and do my work while the guy next to me goes to http://site2.mysites.com, logs in and does his work.

I am having trouble wrapping my head around the best way to do this. My first thought was a WCF web service for the login. I would have a controller action call the webservice passing the login credentials. If the login was successful, then I could get a list of applications for the user from the local storage. Adding more applications would not require us to republish existing apps due to no changes in the web service for those apps.

I also keep hearing about this ASP.NET Web API stuff. Should I go that route instead? I may want to build a site around administering the local user database so having a site that hosted the web api could be an option.

Is the Web API stuff wrong for this situation? If not, does it hold advantages over the WCF web service? Are there alternative methods of achieving my end result?

share|improve this question

migrated from stackoverflow.com Jan 29 '13 at 18:10

This question came from our site for professional and enthusiast programmers.

1 Answer 1

up vote 1 down vote accepted

It sounds like your unique requirements dictate that you are indeed on the right track that you will need an external universal authentication provider for all of your applications, especially the requirement that a change in Membership Provider as you put it cannot and should not result in a new release for your application.

At a universal authentication provider you can control which sites use which membership providers and can even subjugate responsibilities like delegating Roles and Privileges to various users after authenticating them.

I advise caution however on the WCF approach as it seems SOAP based web services are slowly being replaced in importance by REST based web services like what is offered in ASP.NET Web API. The future of applications is mobile, and every major mobile development platform has strong support for REST based web services.

If you even have the slightest doubt that you might need to extend membership provider support to mobile applications eventually then it is a good idea to forgo WCF. Furthermore, REST based web services allow better integration by third parties (perhaps clients wanting to integrate with your software package?) to communicate with your application and retrieve information from it.

As far as authentication protocols for REST based web services, there doesn't appear to be a good out of the box way to do this, but security is rather essential. There is a good article on how to secure your authentication requests to your authentication provider application. http://codebetter.com/johnvpetersen/2012/04/02/making-your-asp-net-web-apis-secure/

share|improve this answer
    
Thanks for the input. I had thought as much regarding WCF. I believe I will work on building a solution based on REST and securing it based on that link. –  fkm71 Jan 29 '13 at 21:36

Your Answer

 
discard

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.