I'm building a system which will use a web layer (ASP.NET MVC) to connect to a service layer which has multiple WCF services hosted in a windows service.
User will login once to the web layer. Then, according to the function he called, a connection will be made to WCF services. I need to use same user in each service for authorizing user, auditing and logging.
What is the best practice for this? Should I save credentials in Session and each time I need to connect to WCF service and pass those credentials to it?
Related
I have a multilayer asp.net mvc application consisting of the following levels:
Database (with stored procedures, views and tables)
WCF service (containing business logic and connection to the database through Entity Framework)
Asp.net mvc application communicating with the WCF service and generating html
Browser
The end-users are authenticated in the asp.net mvc layer using Identity 2.0.
The web server is the only client for the WCF service.
Are there any best-practices for this scenario?
The web server and the WCF service might be running in different locations so we cannot use the intranet protocols.
Since we control both the web server and the WCF service we know that the communication will be point-to-point. This means we can use transport security to avoid the extra overhead with message security.
According to this, Improving Web Services Security: Scenarios and Implementation Guidance for WCF, there are two choices for transport security over internet:
Basic authentication with basicHttpBinding
Certificate authentication with wsHttpBinding
Which one would be best suited to this scenario where there basically is only one client for the WCF service?
Due to the stateless nature of http for each new request to the web server a new service-proxy is instantiated.
Is there a way to cache the authentication info from the WCF service on the calling web server to better performance?
You can set up certificate authentication between your WCF and MVC servers using BasicHTTPBinding ... I've done it. But I'm not sure why you use BasicHTTPBinding when, from your description, all the backend services (WCF and MVC) are Microsoft based.
BasicHTTPBinding is a generic WCF protocol that will accept any properly formatted HTTP request (Gets/Post), whether the request comes from a Windows machine or the JAVA/PHP world. It's also, as you say, stateless. That makes BasicHTTPBinding good for interop situations, but more complex (than say wsHTTPBinding) when setting communication between two MS-centric systems.
By default, for instance, NONE is the default encryption for BasicHttpBinding. Adding Transport takes programming and lot of trial and error to get running, from my experience. BasicHttpBinding, also, doesn't support transactions or sessions while WSHttpBinding does. So, based on your description, WSHttpBinding will be simpler and easier to setup and maintain in the long run. But you might also consider NetTCPBinding since you're going server-to-server.
Below you'll find a great MS site explaining all the different WCF protocols, including to pros and cons of each approach.
http://msdn.microsoft.com/en-us/library/ms730879.aspx
I have to develop a WCF callback service which will be accessed by the ASP.Net web application hosted in IIS or public internet. In this implementation clients should keep getting the updates from the service, so I thought of using WsDualhttpBinding, but I found few disadvantages of WCF callback service over internet.
How to use a WCF Dual Service over the internet? Any one please suggest any sample application for this?
I have a WCF service hosted in IIS. I have another website hosted in asp.net mvc. It is a public web site. I want to secure my WCF service so that it won't be accessible from any applications other than my MVC application, or which I give access.
Can I do this using forms authentication?
Update:
I had gone through several examples, but I couldn't get an effective one. I dont want to use ssl. Login feature is not there in my web spplication. If required, a programitic login can be implemented. All I need is, deny access if the service is not called from my website. I've done this in web service using forms authentication. But here, the httpcontext is null.
Yes, you can. WCF calls go through the same pipeline so that if you check for specific principals (usernames or roles), your checks will fail/succeed depending on the Forms cookie.
More details in my blog entry
http://netpl.blogspot.com/2010/04/aspnet-forms-authentication-sharing-for.html
where I show how to share the forms identity between a web app and hosted silverlight app which calls WCF services.
In case of yet another type of the client application, the way you get the cookie value at the client side can vary. Silverlight just inherits cookies from the web application it is run from.
Assuming your client is a console application, you could even expose an unguarded method from the WCF service which accepts loginname+password and returns the cookie to the client. This way, the console application would first call this unguarded method to login the user and then, using returned cookie, would call other WCF services guarded with forms authentication.
Following is the architecture of my MVC application that is built using WCF service and EF:
MVC application >> WCF Service >> Business Logic Layer >> Data access layer >> Data Store
I have created MyDbContext in Data Access layer, and it's interacting with the database.
I have created a connection string in web.config file of MVC application with the name MyDbContext. I believe this should work, but instead it is trying to create a new database on my sql server. What can be the reason? Or if I am missing anything?
If I put the connection string in web.config of WCF service, it works fine. but I believe this should be part of MVC application only, and WCF shouldn't be limited to using this connectionstring only.
If you are using WCF service to access business layer and data access layer your ASP.NET MVC application should not access the database directly - it should even don't know about database existence at all. That is the reason why you are using WCF service, isn't it? Otherwise you can delete whole your WCF service layer and call the business layer directly from ASP.NET MVC.
Connection string is not automatically transferred from MVC application through WCF call. The correct solution is to define connection string in WCF application because it is the tier where the database is accessed.
Since the WCF service is hosted in the same container which is also hosting the data access layer then it is entirely reasonable to configure it with the correct connection string.
Why would you not want to do this?
I wanted to get some peoples opinions on adding a web serivce layer. At my work, we want to start using web services to handle some of our operations.
Our current project structure that we follow for our ASP.NET MVC apps:
MVC App (View/Controller/ViewModel/Service Layer) --> BAL (Business Access Layer) --> DAL (Data Access Layer)
The MVC app, BAL, and DAL are separate assemblies.
There is a Domain (model) assembly as well that is shared among the MVC/BAL/DAL layers.
The plan is to create a web service that will handle all security functions. This web service will be used by multiple web applications. When we make changes to the Security Web service we only want to modify code in one place and not every web app. So I'd prefer if the MVC project has nothing in it that is tied to a web service.
So I was thinking of adding a Web Service Layer between the BAL and DAL layers.
So something like this:
MVC project (View/Controller/View Model/Service Layer)
calls
BAL Layer (Handles caching / DB Transactions)
calls
Web Service Layer
calls
DAL Layer
What are your opinions?
A couple thoughts.
You are putting your web service layer between you BAL and DAL. This means everything will need to go through your web service, including functions which aren't related to security. I think this is adding an additional layer of complexity. If multiple websites are using the web service, create it as a stand along application/service. Then you can call the service from the different layers of your application depending on what layer needs the service. Generally you would create a Webservice wrapper with a clean interface so you can easily call the Web Service from your any layer in your application.
For the sake of discussion, lets say your web service handled validation of login and password of a user. You can connect to your webservice wrapper directly in your MVC project to see if the user data is valid, then you can log them in if it is. Later, if the user performs a function, and the business layer needs to check if the user has permissions, that layer can use the api wrapper which calls the api to see if user has permissions, and so on.
MVC APP
/ \
BAL --> Web Service Wrapper
/ \
DAL WCF WEB SERVICE
As someone who supports an application that is ridiculously layered as so.
GUI
BAL
DAL to WebService
Webservice
WebBAL
WebDAL
I would suggest putting your GUI as close to your webservice as possible.