Overview of the architecture (unfortunately I am not able to change this in any regard):
.net mvc site that requires authentication, lives on "Machine A"
wcf data service that handles authentication against an "authentication file", lives on "Machine B"
I created a custom principal (inheriting IPrincipal) and custom authorize attribute (inheriting AuthorizeAttribute) to do a couple of unique checks required of this system (similar to checking for roles). Every public controller action, with the exception of those in the "LoginController", have my custom Authorize attribute.
In my controller action to handle login request, which has the "AllowAnonymous" attribute, I post a request to the data service on Machine B and it just hangs. I've debugged the service and I can see that it receives the requests, does its work, and sends a response. The site on Machine A doesn't appear to receive the response.
Here is what I have tried to do so far:
I created a little app on Machine C to post the same data to the data service, the process runs to completion and the app on Machine C receives a response.
I have rolled back to a revision that doesn't contain any of the authentication restrictions, tried posting the same data, still no response received.
I have disabled all the security software I am able to on Machine A to see if the response was being captured by firewall or something, no luck.
If I simulate authentication then other calls to the data service for non-authentication data from the site receive responses and behave as expected.
So if you have any suggestions of other things to try, or if you would like more detail (I unfortunately cannot share code) I will do my best to provide it.
Thanks
The issue here was that there were nested async calls. When i move the async call to the data service out of the async method that was calling it it works just fine.
Related
I have a standard C# Web Api running on IIS that has a custom AuthorizeAttribute to properly authorize calls via a key in the request header variables. Recently, one of my clients calls to the API over SSL have started to fail with an 403 Forbidden error. He is successful when calling the non-SSL url.
The same call - same url, api key etc. works perfectly over SSL from my machine, and none of my other clients are having any issues with this. What could possibly be the issue for this specific client? I have checked some basic things like his client machine time settings etc. are all in order, not sure if this could be some kind of certificate related issue?
try the following:
1- check the proxy on his machine
2- since SSL is used to protect data and safety the data should not change in the way on the server. it could be changed by a virus on the machine (I have the same problem with one of my clients) make sure his system is clean
3- consider calling the API in other ways like (postman, browser, ...)
according to what you write clearly, there is something wrong with his machine. if you find the problem It would be nice to tell me too
I have written a web service (WebApi) which contains all of my service logic and is hosted up in the cloud. My colleague has written the front end part of this service using Angular.js.
The service contains security which means that if the client attempts to make calls to API's and isn't authenticated, or isn't authorised we throw a custom exception which then gets filtered by the WebApi using Exception filters (ExceptionFilterAttribute) and turned into an appropriate HttpResponseMessage.
new HttpResponseMessage(HttpStatusCode.Unauthorized);
or
new HttpResponseMessage(HttpStatusCode.Redirect)
{
RequestMessage = context.Request,
};
In the special case of Unauthorised, the service is stating that the caller has not been authenticated and my colleague place code in the filter which then redirected the caller to the login page of the Angular.js website which to me seems incorrect - not least as this tightly couples the service to knowledge of the js website rather than supporting other client platforms (such as native apps).
The question is this, what is the correct approach for redirecting agnostic clients from a webapi website to the appropriate authentication portal? Should the redirect logic be removed from the service and handled purely by the calling client? or am I wrong and this logic belongs in the service?
If you put the redirect logic in the service, it can only be used by this particular website.
The website should have its own logic on what to do when it receives a HttpResponseMessage with statuscode Unauthorized.
This will allow your service to be usable by other websites and apps.
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 been working on a RESTful webservice for an android native application to consume. I choose ASP .NET WEB API. WEB API makes it very easy to create those HTTP methods in controllers, and converting our response objects into json/xml... Its simply awesome!
Now comes user authentication and those session handling parts. First I thought it will be easier to implement sessions in my RESTful service. But really frustrated with the configurations for enabling sessions in WEB API, and making the android native to handle those session ids.
First, Android sends login request to WEB API
WEB API checks authentications, and responses with a sessionid in response header
Now Android native reads the response header->fetches ASPNET_sessionId ->keeps in its memory
Further requests from android will have to set this ASPNET_sessionId in request header
Do you think this is a proper way?
And now I have another client. A hybrid app in Mobile jquery. Now facing following problems:
Access-origin policy: So I set Access-Control-Allow-Origin to * in response header. And it solved.
Now I need to set session id in jquery ajax post request. And found its not possible to set headers for jquery ajax when calling a cross domain service.
How can I manage session for my hybrid app?
Also What are the things taken care of while creating a web service that has to be consumed from different client applications?
After a lot of research I have come with following points:
REST is stateless. So why do we need to play with session? there by giving it a stateful life?
No need for enabling session state. When a user logins into
application we creates a unique id for user in database. Further
requests from the user will send this unique id as a part of message
body. Server checks this unique id every time for identifying user.
Cross-domain issue in Hybrid app
When converting app to hybrid with cordova we found that cross domain
issue is not occuring. It is believed that cordova converts jquery
ajax requests to native requests calls from android. jsonp also found to be a good solution.
I am new to web services so I created a web service to replace my current in-app DB transactions. I wanted things to be safer so that is why I went this way.
When using a free packet sniffer, it instantly grabs my web service ASMX call. The problem with this is that using a program such as fiddler they can easily see the data going back and forth and even worse set up a auto responder.
Is there a way to hide the calls being sent to the web service to hide from packet sniffers? Or at least make it more difficult to see the calls?
Expose it over a secured channel (such as SSL) only for transport level security.
Alternatively, you may choose to implement WS-Security to validate the identity of the callers, sign the payload or encrypt the payload (partially or fully); or any combination of the above.
Here is an article that talks about this in the context of ASP.NET: http://msdn.microsoft.com/en-us/magazine/cc188947.aspx