• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Security on applet calling web service (different servers)

 
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

The web service is currently securely accessed by web applications from other servers, using SSL/client-cert.

I need to make an applet (served on a server different from the web service), to access the web service.

Is it possible to make the applet-to-web-service communication as secure as the SSL/client-cert I mentioned above? In addition, how is authentication done on this case?
 
Jesus Angeles
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Anyone have ideas?

I googled and saw some posts on 'signing' the applet. Would this satisfy the requirement?
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, the applet needs to be signed in order to access a server other than the one its served from. See HowCanAnAppletReadFilesOnTheLocalFileSystem for more information on that.

For applets to send client certs those would need to be installed on the client. That's probably too much to ask of random users of the applet, but may be feasible if you're talking about a few, specific users. But the applet can make the WS call using HTTPS, so at least it's encrypted.
 
Jesus Angeles
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Ulf, for the reply.

Does that mean, other than signing the applet, there rest will be exactly the same code? (i.e. via applet, versus, the current one we use which is e.g. servlet calling the web service over ssl/client-cert)

...and that would give the same amount of security? (will appreciate your comment)
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"same amount of security" is a relative term. The applet is out in the open, thereby making its code susceptible to decompilation. That may lead to discoveries that allow an attacker to misuse the service. But then, it may not.

You also need to think about the security of the user who runs the applet. If she trusts it, then there is no applet sandbox, thus making her machine wide open to the applet. This may not be a particular concern in your situation (maybe it's an intranet).
 
Jesus Angeles
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
By the way, yes, this access is going to be for a selected few (business to business, and very few), not for the public. By that, additional legal agreements can cover the 'hole' on having no sandbox if they use my applet.

Just like the current web service exposure is already doing over ssl/client-cert, authentication and authorization can and must be added.

 
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can I ask why you are using an applet? That is such "last century" technology. And it opens up a bunch of security issues that I'd rather just avoid completely.

Why not a simple webapplication, perhaps with AJAX?
 
Jesus Angeles
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am researching if, instead of giving the web services details to the (few) clients, the web services can be entirely hidden from the client.

The ideal is to just give them an applet jar (and certificate), and notes on public methods that their javascript can call. That is, to keep the integration simpler, and for them (clients) to know less of my working details.

I have been thinking about what Ulf said on possible decompilation. For authentication, the user details must be hardcoded inside the applet, or add another complexity (which is what I am trying to avoid in the first place) of putting the user credentials somewhere at a fixed location on the client's server or client.
 
Jesus Angeles
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If using applet or other alternatives, actually comes out more work for the client, and more complex than a straight web service/ssl/client-cert call, then definitely I will go with this straight method.
 
Pat Farrell
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesus Angeles wrote:I have been thinking about what Ulf said on possible decompilation. For authentication, the user details must be hardcoded inside the applet, or add another complexity (which is what I am trying to avoid in the first place) of putting the user credentials somewhere at a fixed location on the client's server or client.


Decompilation is always possible. It may take some work, but you can never trust software running on the client's machine, unless you completely trust the client.

[I never completely trust the client, even if I trust the human, I don't trust that there are no virus/malware/trojans/etc. on the client's machine]

So as soon as you stop trusting the client, then you see that you can't trust any hardcoded value in the software nor can you trust any values from the client's hard disk.

You may be able to trust something like a security dongle or a RSA SecureID, but they have their own sets of issues.

 
Jesus Angeles
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In addition to what you mentioned, I believe the web services technology has this 'make it simple and secure' focus anyway.

At the moment, the direct call to the web service could possibly be the simplest, and cleanest. This isolates the issues to the web service technology (instead of adding javascript and applet to the issue).
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just my two cents... you should take a look at "message level" security in place of "using SSL/client-cert". Message level security is the better practice when designing security solutions for Web service communications. SSL is a cave-man approach when applied to Web service calls.

Check out:

WS-Security and SOAP Message Handlers

XML Encryption http://www.w3.org/TR/xmlenc-core/#sec-Introduction process for encrypting data.

XML Signature Syntax and Processing http://www.w3.org/TR/xmldsig-core/
 
Pat Farrell
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

James Clark wrote: SSL is a cave-man approach when applied to Web service calls.


For sure. You can even edit it to just "SSL is a cave-man approach" but its easy to set up and sufficient for a lot of uses.
 
Jesus Angeles
Ranch Hand
Posts: 2108
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

James Clark wrote:Just my two cents... you should take a look at "message level" security in place of "using SSL/client-cert". Message level security is the better practice when designing security solutions for Web service communications. SSL is a cave-man approach when applied to Web service calls.



What I know about using SSL versus method or content-level security in web services, is that the SSL way does the work on the 'entire' load, not just the part that needs security.

Do you see any security hole if I keep it as is - SSL/client-cert? Or is it secured enough at this point? Or are you more concerned on scaleability/maintainability of the web service because it is securing the 'entire' load? Or other things?
 
Pat Farrell
Rancher
Posts: 4803
7
Mac OS X VI Editor Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jesus Angeles wrote:[ the SSL way does the work on the 'entire' load, not just the part that needs security.



Using encryption all the time helps keep the bad guy from knowing what you consider secret and what is not. This can improve security.

I personally don't trust client-certs at all.

Only you can decide if the security is good enough, its impossible for someone to make that judgement long distance.

When you use security, you have to design/engineer for issues such as scaling, load on the servers, etc. Its part of the job
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic