Need to expose some user info to a 3rd party web service.
So created a ServicesController using DNN WebApi with the appropriate [HttpGet] method
and marked it with [AllowAnonymous].
It's all fine, but how do I make sure the needed web service is consuming it?
All the available attributes such as [RequireHost], [ValidateAntiForgeryToken], etc.., requires it to be a part of the DNN website.
Are you asking if you want to restrict the WebAPI housed in DNN to be accessible from anything but your own client? I don't think there is any attribute available in DNN to prevent that. You'd need to implement something on your own. You could pass a secret key as one of the parameter, but again it's not that secure, but it will provide some level of protection.
You could further restrict by certain IP, but this needs to be done within your WebAPI Get method itself.
Related
I'm trying to create a multi-tenanted blazor application using ABP Framework and i'm struggling to figure out how to implement as the documentation is very limited.
My application needs to resolve the tenant based on the url. A tenant can have multiple urls, so therefore need to create a custom tenant resolver which looks up a url table for the tenant and returns the correct id. I have tried this in the HttpApi.Host project and its working fine but the issue is that it doesnt know anything about the URL that the blazor application was loaded on.
I'm now thinking about adding an http header to the api requests with the url, so that the tenant resolver can pull it. Before i head down this path, i'm concerned there is much easier and better way to accomplish this problem i'm tackling?
the documentation is very limited.
The documentation is rich, and the code is open source.
https://docs.abp.io/en/abp/latest/Multi-Tenancy#tenant-resolvers
https://github.com/abpframework/abp/tree/dev/framework/src/Volo.Abp.AspNetCore.MultiTenancy/Volo/Abp/AspNetCore/MultiTenancy
I am designing a web app which has two UI - one a traditional web page(HTML views) and one a WPF app. I know that in order to have a Seperation of concern its best to design as shown below as in, a Web API that is consumed by a MVC app and a WPF app.
However I am a time crunch and I am wondering if I can get away with having just a traditional MVC design as below. Also I may have a lot more non-CRUD operations which if I were to go WebAPI ,will have to implement as RPC style, adding to complexity(more work,more time) of the webAPI.
My only question is - can a MVC action be consumed in a WPF app? And if yes, do I need to use any special API to do so as mentioned in this post or will the new HttpClient package suffice?
Yes a WPF application, just as any other application that is able to send HTTP requests and receive responses, is able to consume an ASP MVC controller action.
After all, ASP MVC framework just parses URLs, deduces routes information (area, controller, actions, parameters and so on), and finally invokes the associated action with parameters before sending you an HTTP response.
From MSDN :
In contrast, user interaction with ASP.NET MVC applications is
organized around controllers and action methods. The controller
defines action methods. Controllers can include as many action methods
as needed. Action methods typically have a one-to-one mapping with
user interactions. Examples of user interactions include entering a
URL into the browser, clicking a link, and submitting a form. Each of
these user interactions causes a request to be sent to the server. In
each case, the URL of the request includes information that the MVC
framework uses to invoke an action method.
So even a simple HttpClient would be enough to interact with an ASP MVC controller action.
But you can also use a framework or library of your choice that help you to build HTTP requests and/or to transform HTTP responses into something more suitable for your application.
It's not mandatory but it could make save some time!
That being said, beware of all scenarii requiring authentication, it could get things harder :
If you need forms authentication, then you can to retrieve your auth
cookie first, and then include it in future HTTP requests (see
this post for more information)
If you need windows authentication, then you have to provide your credentials (see this page from asp.net website)
I am going to be developing an application for work, and I am trying to decide whether to use Silverlight Business App or Asp.Net Web App. My manager is concerned about the performance and download time it would take if I created the entire application as a Silverlight app, with authentication. I have been playing around with some tutorials over the last week trying to get a perspective on my situation and have come up with a design question I need to ask those that are more experienced than me.
Is it possible to use a Asp.Net application and just embed a silverlight application in one of the pages that will be used inside a folder that is configured with the roles authorization? And if so, would it be possible to get user credentials from the client silverlight app without passing them through the initParams.
I understand that I can set the authentication to "useCookies", so I was thinking I would be able to get the cookie on the client and hopefully get a property verifying if the user is authenticated.
Also, would this be a risky practice? Thanks for any advice and direction.
There are a few approaches you could take. While I know you don't want to expose the credential in init params, you could generate a "ticket" (claims-based authentication) for the credential, and include the ticket (for example, a GUID) in the init params. When the Silverlight application launches, it would consume the ticket, possibly validating it via a secured web service call, and the ticket would no longer be valid so even if someone spoofed it or viewed the source, it couldn't be used.
Quite a bit depends on your architecture. For example, if you are using the roles-based authentication, and most of the business logic and/or decision making is based on web service calls, the web services can use HttpContext.Current.Identity to validate the user. Even if someone opens the Silverlight application, any service calls would fail unless they were appropriately authenticated. Otherwise, I would either go with passing a ticket so Silverlight trustst the user is valid (you can create a service that accepts the Guid and returns the role information) or have the user log in from Silverlight (you have a service facing in front of the authentication mechanism and then return a ticket and/or role information).
It gets even more interesting if you decide to use WCF RIA, check out these examples for baked-in authentication:
http://code.msdn.microsoft.com/RiaServices/Release/ProjectReleases.aspx?ReleaseId=2661
1.) It's absolutely possible to embed a Silverlight xap on an ASP.NET page.
2.) As far as credentials, using cookies could work, or you could pass in a token over initparams and validate that token via a web service to see if the user is valid
It's always a risk passing credentials around, especially when it's running on a clients computer. That said, Silverlight buys you a lot, so don't let the challenge of authentication hold you back.
I have googled a bit for how I should handle security in a web service application when the application is basically the data repository for a Silverlight application, but have gotten inconclusive results.
The Silverlight application is not supposed to have its own user authentication, since it will be reachable only through a web application that the user have already authenticated to get into.
As such, I was thinking I could simply add a parameter to the SL application that is a cookie-type value, with a certain lifetime, linked to the user in the database. The SL application would then have to pass this value alongside other parameters to the web services. Since the web service is hopefully going to be a generic web service endpoint, few methods, adding an extra parameter at this level will not be a problem.
But, am I supposed to roll this system on my own? It sounds to me as this isn't exactly new features that nobody has considered before, so what are my options?
First of all use SSL for the service. Otherwise users will be able to capture all the parameters passed to the service. It's still possible to see it in case of https but it will be a little bit more difficult.
Also, consider using Message Inspector for adding custom headers to the messages which you will validate on the server. This way you will not need to add extra parameters.
We have a Silverlight app which we wrote which calls a Silverlight-enabled data service. The Silverlight app cannot require a login, as it is required to present data to the unauthenticated public.
We have some schmoe who took the time to examine our Silverlight app, one way or another figure out what service it is calling, and then wrote his own client to slurp off the data so he can post it on his site and pretend like it is his. We need to prevent this.
How can i limit my data service somehow to ONLY accept requests from my silverlight app? I tried using the allow-from domain uri setting in the clientaccesspolicy.xml file to limit access to the service only from the domain in which the silverlight app sits (say mydomain.com). This did absolutely nothing though, and the service is still serving up requests to clients from outside the domain. (I tested this by putting my SL app on a different domain under our control).
What is the proper/best/most effective way to limit the data service so only our app can use it? Thanks!!!
I'm using SL 3 and .NET 3.5.
The clientaccesspolicy.xml tells the Silverlight application which Webservice it can consume. Not preventing people accessing the Webservice.
You can try using a authentication login even though its not required. This prevents 'schmoes' accessing your webservice.
Also use Dotfuscator to prevent 'schoes' to disassemble your Silverlight application and acquire the login.
Silverlight webservice security follows the same patterns you'd use for ASP.NET security, especially services exposed to AJAX. The best way to do make use of ASP.NET's authentication.
RIA Services is an even better way to handle this. It rides on top of the ASP.NET authorization, but validates on both the client and server-side automatically to combat service spoofing. It let you take care of both client and server-side authorization by adding attributes to your methods indicating that the method requires authorized access, and by which groups or users if you need to be specific.
In addition to wire-side security and obfuscation, remember that clients can attach a debugger to Silverlight applications running in their browser. See this example from MSDN Magazine's Security IQ Test, November 2008.