We are altering our webservices to require an application using them to provide information on the real user who is requesting the data. For REST services we are implementing this using an X-On-Behalf-Of HTTP header. Should we do the same for SOAP services? Or better put it in a custom SOAP request header? What are best practices in this area?
Though answer depends on internals of your application architecture and other design principals you might have followed.
Its ideal to keep Rest/SOAP services implemented the almost same security Model, hence if you're planing to use `X-On-Behalf-Of' HTTP, it make sense to use same in case of SOAP services as well.
But, in case of SOAP it you're using WS-Security or some Kind of Custom SOAP Header to do Authentication/Authorization in every SOAP Call, it makes more sense to Modify SOAP header itself to get the additional On-Behalf-Of' detail as well rather then Custom HTTP Header forX-on-behalf-of`
Refer Message 2 - WS-Trust Token Exchange Request section for more details.
Related
Most of our bespoke applications in AWS are containerized .NET Core apps and so far we haven't needed to build any SOAP APIs - virtually all of the APIs that we've delivered (whether exposed publicly via AWS API Gateway or internal only) are JSON RPC following a RESTful architecture/design principles.
We also have a third party COTS product deployed into our AWS account that produces SOAP webhooks and we need to receive and process these SOAP webhooks produced by the third party COTS product.
Ideally we don't want to build a bespoke SOAP API / translation layer - even if WCF is now supported in .NET Core / 5+, I'd much rather we just stick with HTTP/REST and .NET Core WebAPIs which is well understood by our delivery teams. Ideally there is a way e.g. a native AWS service, that would allow us to translate the SOAP request to a HTTP/REST request. Does anyone know if there's a native AWS service with these capabilities?
Cheers.
The translation would be something like the following
HTTP method GET/POST + SOAP operation verb endpoint
POST /soap/cancelOrder <message>{id}</message>
<=>
HTTP method GET/POST/PUT/PATCH/DELETE + REST resource noun endpoint
DELETE /rest/orders/{id}
Without a naming convention it is hard to translate. Another issue here, that real REST services return hypermedia with a flexible structure, while SOAP services return SOAP message with a ridig structure defined in WSDL. Yet another issue that SOAP is stateful, while REST is stateless.
Maybe in edge cases it is possible to automatically translate for example by services which do only basic CRUD without any real business logic.
I have a public facing API that returns some data, internally using the Google Maps API Service. This API is mostly for interal purposes right now, invoked through the webapplication.
However, I wish to restrict the usage of this API i.e. it should only be invoked from my Web Application ( or mobile app) when a user (non-registered) browses it. An http request directly to this API should not be authorized.
I cannot use API keys since the webapp flow should work for non-registered users as well.
If you're not using HTTPS, any security mechanism is flawed, because it can be replicated. IMHO, you could add a HTTP header (e.g. "Request-source: YourApp") and check for its existance in your API.
Of course, once it's documented somehow, anyone can mimic this header. But if you use HTTPS and create a header that's unknown for other people, you prevent this from happening.
I am starting a new project (a web application) and would like it to retrieve and submit the most of its data through REST web services with AJAX. But I hardly have a good idea of how to ensure a web service to know who is accessing it and only give the data to those who are eligible.
REST web services are stateless, so the authentication should also be stateless.
The most commonly used method for this authentication is to use HTTP authentication headers (details here --> http://www.ietf.org/rfc/rfc2617.txt). Here the pre-requisite is that your should be using SSL\HTTPS otherwise these HTTP authentication headers will become vulnerable to Man in Middle Attack.
If your website doesn't use and SSL then you should probably look to other methods of authentication, this (http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/) article discusses in detail about all those methods. It basically describes mechanisms which are used by Amazon Web Services to authenticate non SSL reqeuets.
Hope this will help.
We currently have a SOAP based web service that our in house applications use to authenticate users. Basically, they send a SOAP request with the username and password. The web service authenticates their credentials against our data store and returns user information if the authentication is successful. The web service is secured using BASIC authentication and SSL.
We need to make modifications to this web service and I was considering re-writing it as a REST service. The REST services I have created in the past have been fairly simple and had no need for security. I have never created a REST service that used sensitive information, so I have a couple of questions / concerns:
First, is there a best practice for sending sensitive query parameters (user credentials) to a REST service securely? I can still use the BASIC authentication and SSL.
Second, if I send a query to a REST service using POST, is it still considered RESTful, or is GET required for REST queries?
You can use SSL and Basic authentication with REST web services as well.
HTTP GET is usually used for data retrieval (queries) but you can use HTTP POST as well. GET is especially useful if you can use any type of HTTP caching. POST is usefull if you need to transfer a lot of data to define your query or if your web service operation expects some complex data format instead of simple arguments.
Instead of doing the authentication via REST, you might also consider a networked authentication protocol to use in conjunction with web services. Technologies like Kerberos and OAuth were designed for these sorts of use cases.
To answer your questions, however:
REST encourages you to leverage HTTP and related protocols, so using SSL and BASIC authentication is quite appropriate.
REST encourages the use of not just GET and POST, but even other HTTP "verbs" such as PUT and DELETE. Use GET only for idempotent operations with no side-effects.
Going from SOAP to REST is taking a step backward as far as security goes.
As far as best practices:
Don't roll your own security. Use a framework or existing library that has been peer-reviewed and tested.
Don't pass unencrypted static keys. If you're using HTTP Basic and sending it across the wire, encrypt it.
Ideally, use hash-based message authentication code (HMAC) because it's the most secure.
Why REST security doesn't exist
We have SOAP web services in production that are relying on SOAP Headers (containing plain client credentials) for the authentication. The WS are used in heterogeneous environments with .NET/Java/PHP/Python/C++ clients both web app or desktop app.
We are considering a v2 for those WS and I am wondering what are considered as the best practices for WS SOAP authentication? (reasonably secure, yet easy to handle on a wide variety of platforms).
The easiest way to handle it across a variety of platforms is to use HTTP basic authentication and HTTPS for the transport layer. WS-Security would be good if your needs go beyond simple username/password but the support is going to vary quite a bit between platforms. HTTP authentication is supported by every decent SOAP implementation.
If you have to roll it all yourself and can't use HTTPS, I'd suggest the hash-based UsernameToken portion of WS-Security. It's pretty secure and fairly easy to implement as long as your libraries have the hashing functions.
If you're doing web services, I wouldn't rely on HTTP for authentication.
WS-Security as a whole is way too big.
The way I have tackled this in the past is to use the standard WS-* features.
Instead of using the authentication feature we set the message header integrity feature on. This requires both sides of the dialog have access to public/private key pair and detects any tampering of the username field in the header. So you can be sure whoever sent the message and set the user id has access to the private key.
This provides a reasonable level of integrity if the keys are managed properly.