I have a server-client project written in c#.
I want to change the client side to a web client so we can open it with the browser. So I decided to make a WCF rest service that will replace the server side. The binding that I am using for the service is webHttpBinding.
My problem is with the behavior of the service. The service data (vars etc..) is initialize after every call. If i add the [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
it doesn't change anything. If I use [ServiceBehavior(InstanceContextMode = InstanceContextMode.Single)], it works but I guess that the service instance will be the same for every client.
I have a simple html web page that get a username and password from the client and post it to the service. The service check the Login info with the user database and response. My problem is that i can't save the user status as logged in or not because after every post/get method the service is reset.
what should I do?
This is a pretty standard issue you have to deal with when trying to maintain a session over HTTP, which is what webHttpBinding is using. Even if you try to force it to have a session, it won't. RESTful services don't work that way.
A high level overview of what you have to do is have the service create a token it gives the client upon initial authentication (probably to be stored in a cookie), which the client will then send back with each request. The service can then use that token to check if the client is logged into a particular account with each request. You probably want to make tokens expire after a certain duration (might be 1 month, 1 week, 1 day, 10 minutes, depending on your application).
You can find some more information here:
RESTful Authentication
SPA best practices for authentication and session management
Authentication, Authorization and Session Management in Traditional Web Apps and APIs
Related
I have a big system. This system consist of client desktop app and many wcf services. Each of wcf service have it's own logic and isolate it from client code. One of the services is authorization service. It's main task is to authenticate user and let all other services to know what user is logged on without additional stuff. For example, as i think i should at the start of client to make authentification of the user, check it's login and password and next generate some token and use this token in all requests to other services to let any service know what user is working with it. Well, firstly, i wanted to use claims authentification, but it is quite complicated for realization. Now an idea of my algorithm is to generete some kind of token, put it into the header of any request and pass to services. Service will send this token to the authorization service and service will check it.
The question is: is there any more beautiful and more easy for realization algorithm to let any service know which user is now working with him? Or maybe wcf have some standard solution for this problem?
Update 1. I can't use active directory and any windows default authorization mechanism. I have my own database of users, their roles and permissions. I need just to let other services to know the name of the user. I need to write this mechanism once and let other developers to use it in any wcf service of our system. Is it a bad idea to send a login in every request?
I have created a WCF Service that runs in IIS and is published in a website.
I also have a MVC application that uses indentity 2.0 to authenticate and authorize my users and this application is connected to a SQL Server database with user information. This applications consumes the WCF service.
What I want to know is if it is possible to use the user credentials from authenticated user in the MVC application to make calls to the WCF Service and, if yes, which is the best practice for doing this.
I've finally found an answer for this subject.
When calling the web services from your asp.net mvc app you can pass the cookie like this:
var request = HttpContext.Current.Request;
var cookie = request.Cookies.Get("IdentityCookie");
var ticket = cookie.Value;
Pay attention that in this line var cookie = request.Cookies.Get("IdentityCookie") It will not work in your case because I renamed the cookie, if you didn't rename the cookie you replace "IdentityCookie" for ".AspNet.ApplicationCookie" otherwise just replace it for your cookie name.
(In my case I have a class that auto sends message headers in every request, the cookie goes in that header, you can make something similar)
Then you just need to make a message Inspector in WCF side so that every request pass to that inspector before calling the service. In that Inspector you can decrypt the cookie and check if the user is authenticated.
It resolved the problem for me, I hope this can help.
i need to build this architecture and i need some orientation on "how should i build". I've read many docs and examples but i can't find and figure how to do trying to be efficient and secure:
External app (android app, ios app) where users, after a login, can access to their personal info and manage the account (updating personal data, showing personal documents related to their account and much more). The username / pwd input must be done only 1 time.
A public wcf service will receive their actions and will call to a another internal wcf service. It will work like a 'bridge'.
The internal wcf service will get the request and do the operations needed (logical and db operations). This will return data to the external wcf service and this one to the client (obvious).
UserName/PWD are stored in a database.
WCF services can only be accessed with the correct credentials and are IIS hosted.
So i find many problems/questions:
I don't know HOW and WHERE should I build the AUTH (internal, external, both?). How can i manage a session between wcf services and app clients to avoid sending credentials every time?
The client app needs to send credentials every time? This means every service requires to SELECT the database for checking the username?
SOAP? Rest Services? It doesn't care? (on internal wcf, external wcf, both?).
I need work with asp.NET sessions or i really don't need? I don't see how services that needs username/pwd that are called frequently and repeatedly are efficient without old asp.net sessions.
Thanks for your help and orientation.
Regards!
If someone interested... seems Routing Service seems to fit for my design and can solve my problem after some tests i have done.
I am trying to implement role-based authentification to the REST WCF service . I read a lot of information on this theme but didn't got a clear understanding of what I have to do.
I understand how to restrict an access to the service using the [PrincipalPermission] attribute but don't know how to check whether the user belong to the certain role or not.
Therefore I will be very grateful if somebody can direct me to the right way (e.g. make a roadmap what should I do to achive this goal).
Let me describe this situation. I have a remote services which hosted on the server A and ASP.Net MVC client hosted on the server B.
All of these rest services has an access to the database where I can read an information whether the user has access to the service or not.
OK, Tequila, IMO what you really want, based on your description, is a normal, REST WCF service with a Login(ID as string, PWD as string) method that (perhaps) returns a SessionID. This Login() or SessionID() check method would then preceed access to all of your other methods. And since it's a webHTTPBinding -- effectively a stateless web service -- you'll need to check the SessionID or ID/Password before each request is processed.
So the workflow would be something like this:
1) client sends Login() request to host
2) host checks ID/Password against DB, creates SessionID in DB that times out after x hours, forcing new Login(). SessionID is returned in response to client,.
3) In all subsequent requests, client must provide that SessionID. That SessionID would be checked on the DB, returning stored information about the client (Role, name, ID, address ... whatever is useful) before the remainder of the request is processed.
There are methods for authenticating users BEFORE the request gets to your working code (like client authentication using Forms or client certificates (see http://msdn.microsoft.com/en-us/library/ff405740.aspx)). This shifts the Login() / SessionID check to a method executed BEFORE the request hits your main program, but the steps are basically the same.
And since passing ID/Pwd in clear text over the web is a no-no, you'd want to implement SSL on your web service (see http://msdn.microsoft.com/en-us/library/ff650785.aspx)
Everything I've describe is basically platform independent, so if you'll have iOS or Android clients, there's nothing in what I've described that would prohibit those OSs from successfully interacting with your web service.
Good luck.
I have a Windows Service running a Web API hosted as a OWIN middleware - the server. The API uses application cookie authentication and validates users against a database, using OWINs identity model. Now I would like to authenticate a user who accesses the API through a standard MVC web application (the client), but I'm unsure how to achieve this, e.g. after I received a response along with the cookie from the API, where do I have to store it inside the MVC application so that the cookie will be automatically sent along with further API calls.
You won't need to. Cookies are stored by the client's browser, and are sent to the web server with every request on the same domain name. Each subdomain will have its own sandbox for cookies. The main domain's cookies can be accessed by all subdomains.
MVC application will store it in the users browser the cookie. If you need to find an alternate way to achieve it, why not try localstorage. You can then send the authorization token with every request header using your Ajax calls. If you are interested in an Angular Application, here is an excellent tutorial that should help clarify a lot of question.