I have REST web services exposed by APIs controllers in my ASP.NET Application. These services are useful for me to synchronize my business layer with my view layer.
Now I want to make them more secure, because I feel like all my data is exposed and that anyone can have access to them, if only he types the http url of the web service. Is there any username/password security mecanism for my web services? Or is this done via a certain configuration to IIS?
If you would like to create your own security mechanism then it would not be to hard to authenticate using tokens in the http header. For example, you could use a public/private key scheme and hash a few items that change frequently such as DateTime and input parameters and the resource url itself.
.Net provides ways to place your security checks prior to reaching your service methods so you don't even have to check the token in the http header in each of your methods. They will only be invoked if the request is authenticated.
Related
We currently have a node web server that does authentication of users including oauth2 to google and facebook. We would like for it to handle the serving of web pages while a stateless .NET web api handles the serving of the actual data (which is all requested asynchronously). My question is how to handle authentication to the web api?
I mean should the client even authenticate to the api (and if so how do we do the pass through authentication so that it is authenticated to both once authenticating against the web server) or should the web server authenticate the user and then just forward all api requests to the api along with a user id? What is the standard scheme used for this?
Thanks in advance.
This answer is late, but I'll post my thoughts for the heck of it. I would place a dummy api in your node app, just a simple pass-through for everything that is in your data api (the .net one). Then I'd lock down the data api so only your node server can talk to it. The short answer is that any api that you expose to the internet has to be locked down. If you do the above, you don't have to expose your data api to the internet. You get the added benefit of not having to deal with CORS - you can have a simple /api folder hanging off of your domain. You can also use this pass-through api to aggregate calls to multiple business apis if your solution ever grows. It's a very scalable architecture.
If you don't want to do the above, then you'll need to either place the data api on the same domain as the other site, or setup CORS so javascript/AJAX from one can call into the other. Once your data api can see cookies written by the other site, you'll need to authenticate them, probably very manually, in your .net api, since .net didn't write the auth cookie - node did.
I want to implement token based authentication for an ASP.NET Web API project.
I have come across 2 implementations the Katana/OWIN middleware, and another one called Identity Server 3
Would you recommend one over the other? My Web APi is only going to be accessed via the SPA. But I would like to have users login from a database store or using a 3rd party provider.
What are the benefits of Identity Server 3 ? Also it seems that IS3 acts a separate service/server. Does that mean there will be more roundtrips for authenticating?
It sounds as if you want to accept identities from external providers as well as maintaining an internal database.
For external providers, you will need to validate the tokens that arrive. OWIN provides support for obtain the artifacts you need to validate a token by retrieving metadata from the IdentityProvider.
Your Web API should be able to obtain an access token and present it to your application by using 'OAuth Bearer'. This should be independent of using a Database.
I have an ASP.Net Web App which is secured using claims based authentication, currently the IP is Azure ACS, which in turn calls my domain's ADFS (but in theory it could be many different types, e,g, Google, Facebook etc.).
The Web App exposes an endpoint Service.asmx which is also secured using the claims authentication.
I found this blog post which shows me how to call an IP and return a Request Security Token Response containing my claims.
Once I have acquired this token, how can I use this Request Security Token Response in subsequent web-service calls to the service?
Can this be done using the proxy classes generated by adding a web-reference in VS / wsdl.exe?
No, ASMX does not have this ability. It is a legacy technology and should not be used for new development.
My scenario is a 3-Tier app where the data tier is a SQL Server database, the middle tier is a WCF application hosted in a Windows Service and finally the presentation is an Asp.Net MVC application.
As usual, the middle tier is the one that performs all of the business logic. Access database, define business rules.. etc.
Okay, so far so good! BUT now here's question: How do you handle security in such a scenario? I mean, the user has to log in on the ASP.NET application, but I want to authenticate it not only in ASP but in the WCF middle tier as well, since a WCF service is supposed to be accessed by more apps.
I want the user to log in on the Asp.Net application and let WCF know the credentials as well. Is there some kind of session in WCF in which to specify a logged in user?
How do pros handle security in this case? I know you can secure the WCF services with message security, but how do Asp.Net and WCF sync on a single logged user? I want to secure WCF operations depending on the user for authorization means.
I would suggest looking into using an approach like HMAC (Hash Message Authentication Code) for your security, or a similar token-based approach. The idea would be to sign your requests to your WCF layer which can be used to authenticate the request and identify the user making the request.
The essential elements would be a token and a shared secret of some sort used for signing each request. The token would allow you to identify the user on the WCF end, and lookup the shared secret to verify the request. You can also added timestamps / nonces to prevent replay attacks and such.
I've used this approach for some REST services built on WCF - with the added benefit that clients do not need to store usernames and passwords, just the security tokens used for communication. In your case you'll need to sort out how to exchange the tokens between the ASP.NET layer and the WCF layer, but it would provide you a unified authentication method for any consumer of your WCF services.
Have look here for UserName Password authentication.
ASP.NET Web Site + Windows Forms App + WCF Service: Client Credentials //for insights
i'd like to recieve comments on the way i'm trying to build an asp.net web application which uses a WCF service that is hosted in another asp.net application. Both applications will live on the same machine, but the app with the WCF service will not be accessible from the outside. there will be two web servers sharing the load behind a load balancer.
The app pool of both applications will use the same local user account (web server is not part of a domain) and so i was thinking to use WsHttpBinding with windows security for communication between client and internal wcf service.
The fron-end asp.net app uses forms authentication through a custom membership/role provider to athenticate and authorize users. The user database is in a sql server database.
i need to somehow pass to the wcf service the user details (username + roles) so that in the wcf it will be possible to validate and authorize according to the roles of who is logged in the front-end. I read i need to use "support tokens", but i haven't figured out how to use this.
I read also something about claims and WIF, which seems interesting but have no idea how i could use these in my scenario.
is there anyone who can give me recommendations about the architecture and maybe also show me how to pass the username to the wcf service and also show me if possible to use claims based authorization?
First of all, if both servers are behind the corporate firewall on a corporate LAN, I would strongly suggest using netTcpBinding instead of any http based binding. NetTcpBinding is much faster due to encoding the message in a binary format.
As for username / password: your ASP.NET front-end server could set the client credentials for the user calling for the WCF service - after all, the ASP.NET servers do have access to the ASP.NET membership database, don't they?
Or if you cannot pass on the user's credentials, you could pass on some headers to your WCF service that would describe the user - actually, you probably only ever need the user's unique ID - since the WCF service could fish out the rest of the info from the ASP.NET user database again, if really needed.
As for claims - I don't think they'd be a good idea here - you don't really have to deal with a multitude of different authorization schemes, and you're not using any federation (e.g. allowing users from a different company or domain to use your services) - so those obvious benefits probably won't really be applicable to your case.