I am developping a web application project in Visual Studio 2005 on .NET 2.0 the web application project has obviously secured web pages and web services. I want to secure the web services as well. Currently the authentication mode in the web.config is set to forms and I have created my own membership provider for this purpose.
The target application server is IIS 5.0 which is configured to work over https with a valid certificate so technically speaking all I want is the web services to validate some hard coded string to ensure that the system that call them are known since they manipulate sensitive data. Since its over a secured channel I do not expect to use any fancy encryption for this web service authentication. As a side note, the expected system to use the web services are in Java and not in .NET
What I am really looking for is the best way for me to achieve this within the same solution in visual studio. I do not want the web services to be a separated project. (requirement)
Is the only solution to use flow credentials in the SOAP header ?
Thanks,
Carl T.
You can add a location element to your web.config with an authorization element that allows anonymous users to access the web service, effectively bypassing the forms security for the service. Then you can make your hardcoded string be accepted as just another argument to your methods. See location Element (ASP.NET Settings Schema) for more information.
You mentioned hard-coded strings, so I assumed you were looking to pass it to methods and run sessionless. Give this article a look .NET Web Services Security. The part you'll be most interested in is on page 3.
Ideally, you should look to update to .NET 3.5 or higher with WCF, but barring that these are your best bets.
Related
I am trying to resolve the following problem using best practices.
We have an API server, which uses Authorization with JWT token to call our api endpoints. Now we need to develop Multi platform application (Android, iOS, Web) to consume this api.
We are planning to use .net MAUI for Mobile and Blazor for Web application. All these applications will have a common user base.
Also we would like to share api to third parties, and we would like also to put their users in our common user base.
What would be the proper approach to do it ? Should we add Identity server to our Web API project ? Should we create separate Identity Server project which will share userbase ?
I would recommend to use IdentityServer and also do host it in a separate service is a best practice.
Because otherwise it will be harder to debug and troubleshoot when you mix IdentityServer with other services.
There is a requirement to have a common web api application to service 3 different MVC web applications. These client web applications have their own databases and own authentication implementations. How do we configure the web api application to provide access to a set of APIs to web app 1 alone and deny to all other web apps, similarly for web app 2 and so on? In other words, is there a way to 'register' each web app with the web api service and also build in a mechanism through which the web app is only allowed access to a set of endpoints? Thanks for all the help..
There are a handful of ways of solving this
Host multiple WebAPI servers in a single process to effectively meet your requirement while making your project easier to organize
Use Authentication and Authorization filters to customize how requests are accepted, denied, and routed
Using a router and/or switch at the hardware level, create a blacklist/whitelist combined with a reverse proxy (beware of MAC spoofing, etc, with this solution)
Use dependency injection to add abstraction to the process and to remove the ability to specify a custom endpoint in an unintended manner programmatically; this solution will only work if you control the client code, however
From the sound of it, the issue you're describing doesn't seem like one regarding the visibility of the endpoints, but of the access control to leverage them. If I'm wrong, please let me know in a comment and I'll update my answer.
I have been scratching my head how to solve the issue described below.
So, the company where I work uses Visual Studio Team Services (was Visual Studio Online), and it is integrated/connected to our AD, meaning that If I log in to my workstation I can log in to Team Services without authenticating myself, like SSO.
I'm going to create an application which communicates to Team Services via Team Services SOAP and WebApi clients and here is the problem. I need a user to be able to communicate with Team Services and doing stuff (reading data, creating work items, creating test suits, etc.). I see little chance to convince IT to create a user only for this. They going to reject my request due to security risks.
The application architecture looks this:
browser: angularjs application, spa, calling only the WebApi service
server: WebApi service, which is responsible to communicate with Team Services and transforming data back and forth between the client and Team Services.
database: persisting data for later analysis
There is an idea in my mind, where I can get somehow the windows credentials from the OS and push it down to the server which uses it to communicate with Team Services. In Team Services, we will see that the particular user did things.
The question, how is possible that? The articles I have found searching for something similar, always mention .Net MVC app where I need to modify the web.config in order to get the credentials. But, in my architecture there is no .Net MVC app running on local machines. There is only a SPA running in browsers.
Or my architecture is not fit for this purpose? Shall I rework it and using MVC app to be able to get the credentials and working with them? But, the question still stands, how can I pass the credentials through the calls calling Team Services?
Do you know blog entries dealing with cases like above?
Thanks for any help in advance!
I think you have a bit of confusion over your terms. The SPA (Single Page App) has javascript code delivered by the server to the browser that calls the .NET WebApi code. In order to get the browser to use Kerberos/Windows Authentication you need to add
<system.web>
<authentication mode="Windows" />
</system.web>
to your web.config on the server where the .NET app is running (under IIS).
From here...
http://www.asp.net/web-api/overview/security/integrated-windows-authentication
"On the client side, Integrated Windows authentication works with any browser that supports the Negotiate authentication scheme, which includes most major browsers. For .NET client applications, the HttpClient class supports Windows authentication:"
Then the browser will do the rest for you and the HttpContext.CurrentUser in the .NET code on the server will be set to the windows user of the clients browser.
We are starting a project which will consist in:
Web project (ASP.NET MVC)
IOS app
and both will consume data from a .NET WEB API service.
The WEB API service will expose a POST Method with the url "user/create". But i don't know how can i avoid another apps for making post to this url? I know i need a security protocol, but i wanted to know which one you recommend me, and if you have, an article where is it explained.
Thanks
web api 2 provides oauth authentication. You will need to get a token from the token end point of web api and pass that token in subsequent requests.
You should find lot of online resources if you search for web api 2 oauth.
We did something similar recently using OWIN OAuth 2.0 Authorization Server
Reference this ASP.NET page for details. Sample code is included as well for several different implementations.
For our purposes, we used the Client Credentials Grant section about half-way down the page. Our implementation involved server-server OAuth (Web API to MVC), but I bet it's pretty similar to have iOS connect. The only thing I would caution is to somehow encrypt the login credentials on the iOS side, and I'm sure there is a way to do that.
So you want the WebAPI to only be used by the MVC page? The best architectural method is to separate the two rather than leave both in one project. Why? Because the MVC app is a experience layer for humans. The WebAPI is an experience layer for the MVC app. Move it back where it can't be accessed.
You can add on tokens, etc, but the MVC app sits on the server, but is accessed on the client computer. The wider the scope of the application (ie, intranet or internet or something in between?), the more difficult the problem and the harder it is for your users to access the application. Moving the WebAPI internal and leaving the MVC app exposed guarantees external users cannot use the API.
The main reason WebAPI and MVC exist together in a single project (still a mistake in most instances, IMO) is you are exposing both to the same audience. If that is not your intent, don't do it.
I've got a stand alone WCF service providing REST services. As time goes on, I'm feeling like MS is going to reduce support for WCF and REST services, and I've already had to code in a bunch of hacks to get somethings working like CORS. Additionally, implementing https is another hack since it requires using OS functionality. (i.e. you have to install the certificate using an external application, which doesnt' make the service very self contained)
In anycase, I'm considering either a move to ASP.NET REST API and OWIN, or Java/Spring. I wanted to first see what it would take to move to ASP.NET REST, since I figured that should take the smallest amount of work, but I haven't found any good examples.
There's a pretty straightforward example on the asp.net site.
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
setup a self-contained project i.e console app or windows service
initialise and setup you routes
create your Controller / API stubs
deploy
Regarding SSL, whether it's IIS or Apache you will have to configure it on the web server regardless.