I've got 2 backends that need to share information between them using SOAP services across the Internet. Theses services are designed to be only used between these 2 backends so I need to secure them.
I've been reading about securing SOAP APIs but in this instance wouldn't a 'password' param in each method of the API be enough? The password would be hardcoded in each backend and verified at each call against the hardcoded one.
There are 3 methods total so implementation would be easy enough. Also, both points are server sided (client calls one point of the backend, not the SOAP API) so I guess hardcoding the password isn't that terrible.
Does this implementation pose any security risks? Would it be worth it to do it any other way?
Server backend is Spring + CXF.
Thanks!
A way to implement this is using Public key cryptography. This allows you to share a public key with the other side to encrypt the messages send. The message can then be decrypted with the private key. more in the wiki entry above.
java doc
Tutorial
All these links on the subject where done with a quick google search so you should be easly be able to find more examples on this subject by googling:
java public key encryption tutorial
Related
I'm working on a small piece of middleware based on RESTlet that's providing a REST API to several back-end systems.
There for, my JAX-RS Application requires credentials for some of its methods to authenticate calls to back-end systems using (clear text) user name and password.
So far, I found a lot of documentation on Authorization/Authentication, but all of it only goes as far as validating access to methods and providing user groups. None of it seems to give me the possibility to pass the users' credentials to the actual methods. Is there a nice way to inject them without being REST framework dependent?
A common (and not very secure unless you're on HTTPS) strategy is to put them in the HTTP Request Header if you just want plain authentication. On the server side you can use those values and do whatever you want with them, including evaluating access to the requested service. If you use JAX-RS is relatively simple to create a utility method that does that.
If you also want to ensure integrity you may want to include an hash obtained hashing the concatenation of all param string representation with a simmetric key (known both by client and server). On the server side you recompute the hash to check if the request has been tampered or not. In this way even if an eavesdropper get your credentials sniffing the netwkork traffic he would have difficult times in sending fake requests or tampering a correct one.
I am currently in the early stages of creating a web application (HTML5, JS, etc.) that uses a REST API on the backend (Java, specifically Jersey v1.18). The nature of the data that will be stored is highly sensitive, so security is something that I’ve started looking at, even though the application is only in the early stages. The eventual goal will be to have native mobile applications as well, and to potentially provide access to the data for external clients via the same API.
In my research thus far, I have identified a variety of authentication methods, including HTTP Basic, token-based, session cookie, OAuth, HMAC, etc. The key component here is that the REST API will be primarily accessed by users, rather than other applications or backends. Thus, having a “login/logout” equivalent is important, and this boils down to user level authentication.
So far, HMAC authentication looks to be the most promising, as we have no plans to integrate with any OAuth provider at this moment.
I have already read through dozens of SO posts, as well as articles such as:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
http://www.errant.me.uk/blog/2013/04/authenticating-restful-web-applications/ (note: this is clearly bad, as salting with the username is not recommended)
Ideally, HMAC seems like the way to go, but I have yet to see a recommended approach to handling the shared secret. The idea of using a resource to validate credentials, which then provides a token/nonce to be used with the HMAC scheme, seems to be an option, but I’m questioning the advantages over just using this token/nonce strictly as a token.
I know that HMAC authentication for a REST API has been discussed at length, but when used in conjunction with the authentication details that users have come to expect (username, email, password, etc.), is there any recommended approach that doesn’t require a pre-shared secret key?
This is primarily an opinion-based question, but I'll offer my two cents: just go for a session cookie.
If your primary audience is humans, and you don't need to integrate with third parties, don't bother with OAuth. Just make sure your API is only available over HTTPS, and issue a session token that the server can revoke after login. Strictly speaking it doesn't need to be a cookie; I've seen APIs that stash the token in HTML5 session storage and provide it in the Authorization header or as a query param.
If you have SSL set up properly, your users will get the expected padlock in the browser, and you'll be safe from anyone in between you and the client. If the client is compromised, you're screwed anyways. And since the client can't keep a secret, there aren't a lot of advantages to more complex HMAC schemes.
i am stumped on this.
I wish to ask how do i really know that an authentic client is connecting to my web service.
I have successfully set up an HTTPs protocol on my web service and also my apache tomcat server.
However , how do i really authenticate a client dynamically without him giving me a username and password. Example, google authenticates its clients by giving them an api key , with that key they are allowed to use its web services.
I wish to do something similar to that, how do i do it?
Hope you guys can help me out on this.
Thanks in advance!
Probably you should look into The Apache Santuario project which is aimed at providing implementation of the primary security standards for XML.
-> This library includes a mature Digital Signature and Encryption implementation. It also includes the standard JSR 105 (Java XML Digital Signature) API. Applications can use the standard JSR 105 API or the Apache Santuario API to create and validate XML Signatures.
You can find more info at the following url
http://santuario.apache.org/index.html
You can also find an example here :
https://svn.apache.org/repos/asf/santuario/xml-security-java/trunk/samples/org/apache/xml/security/samples/signature/
specifically look into the KeyResolver feature
The Apache Santuario project is recommended project by Apache Axis.
http://axis.apache.org/axis/java/security.html#Authenticating_the_caller
What we tried in this situation is to go really Service Oriented .
i.e. We have an Authentication Service which takes input as User Credentials and return a session id . For all other Service calls the session id is added in the soapheader block.
soapHeader.addAttribute()
Using this approach
We avoided user credentials details to be used every time in service calls.
Also the signature of the service is devoid of any authentication data.
In this approach the client application has to authenticate first and use the output , session id for other service calls.
Request : We still haven't completely analyzed the security threat for this approach. Any suggestions / criticisms would be highly appreciated
I am trying to secure my REST API developed using Spring MVC.
On google search I came across this link.
Is this the best approach ? Does it uses Digital Certificates ? Or Digital Certificates used only for SOAP based Web services?
Please also point me if there are better alternatives for REST authentication.
Is this the best approach?
What is "best" depends on your requiremements. The benefits of this approach are
Fairly easy to implement
No obvious vulnerabilities as long as the Secret Access Key stays secret.
Not so nice:
Both sides have to know the Secret Access Key, so you as a user must trust the provider of the REST service keeping your Secret Access Key secret. In most cases this is probably not a big limitation, but still ...
Does it uses Digital Certificates?
Nope. No certificates involved. With the exception of the SSL connection that is probably used to give the Secret Access Key to you.
Or Digital Certificates used only for SOAP based Web services?
Not true. You can use https (SSL) for REST, which typically involves the presentation of a certificate by the server to authenticate itself. You can also configure it so that the client has to authenticate itself with a certificate using SSL. This would be a nice solution, but is rather tricky to implement on the client side. It's not rocket science, but reading and understanding the handling of Certificates and private and public keys can be tricky. You'd also need some trusted Root CA, which is either a lot of work to setup or rather expensive to use if you use one of the established ones. I'd consider this approach when I'm working on internal services of a large company. They often already have this kind of infrastructure.
Please also point me if there are better alternatives for REST authentication.
As said above: This is a pretty good approach for most services. Using a PKI with client certificates would be an alternative, better in some settings.
You can simulate public/private key authentication like this
You need two basic things!
UserId / Application Id ( To check this application is allowed to access this application) (Private Key)
A random key for the API ( to check this method is allowed for the then authenticated application)
The Rest service (Server Side) will have a record of all the allowed application through "Application ID"
Now you can use these two keys in ur own algorithm . For example, you can create a simple HASH out of it.
The scenario would be, you are encrypting your API with a public key ( You API random key).
The client who is calling the method, is decrypting with his private key (Application ID)
When the client sends, his Application Id, you can , generate the HASH out of his Application Id and the API random key and make sure that, this application is allowed to call this method.
The Advantages here are:
1. The Server side can change the encryption algorithm, which client need not to be worried about
The server can change the method encryption (The public key), which the client need not worry about
The Client CANNOT change the private key(Application ID). If he changes, the server will reject it. In other way, a non-registered application cannot access the Rest Service
I am building a public facing REST application for clients to access. In trying to develop security for it, I looked at how AWS handles their REST authentication using an access key and secret key to sign the message before sending to the AWS server. So I coded an example with Jersey, JSP, and javascript (jsonp) to test, and it seems to work ok.
1.) On page load the JSP takes the client's access key and date/time (converted to EPOCH) and writes out to the page. It also takes those two pieces of information and combines them with the client's unique secret key via HMAC-SHA1.
2.) When I execute the JQuery ajax request, I pass in all three pieces of information.
user access key
date/time (EPOCH)
signed message
3.) On the Jersey side I take the access key and date/time and check a database for the users secret key. Then I perform my own HMAC-SHA1 signature and compare that to the signed message from the user submitted signed message. If they match, then allow them to use our web service. I also check the date/time and only accept messages signed within the last 15 minutes.
My question is, is this secure enough?
This isn't a complete answer, but I don't have the points to just comment quite yet. I would add to your security a salt on the server side. Please see this article for a good discussion on hashing using Master Keys and salts.