You could also use client certificates to achieve this if you wanted to
be more secure.

I pulled this directly from apache's ssl documentation. With this you
could require a client certificate only for specific locations so only
people with client certificates can access it. You can even filter
client certificates by some criteria such as a component of the subject
or serial number. I admit it is quite a bit more complicated than
allowing from a particular IP address and maybe overkill for an internal
process, but it would be a lot of fun!

http://httpd.apache.org/docs/2.2/ssl/ssl_howto.html

SSLVerifyClient none
SSLCACertificateFile conf/ssl.crt/ca.crt

<Location /secure/area>
SSLVerifyClient require
SSLVerifyDepth 1
</Location>

Joshua Dayberry, CISSP
Senior Web Developer / Information Services
UnitedHealthOne
Golden Rule Insurance Company
7440 Woodland Drive
Indianapolis, IN 46278

Phone: 317.715.7541
E-mail: jdayberry@xxxxxxxxxxxxxx

"Everything should be made as simple as possible, but not simpler."
Albert Einstein


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx]
On Behalf Of Dean Eshleman
Sent: Wednesday, March 30, 2011 2:04 PM
To: 'web400@xxxxxxxxxxxx'
Subject: [WEB400] Post to the Web400 mailing list

Hi,

I have a question about securing web services. The web services we have
created are for internal use only. They are written in Java and running
in Websphere 5.1 Express on the system i. I know this is an unsupported
version. Upgrading isn't an option right now. The reason we need to
secure them is we will be implementing some that create and update
records. We don't want developers to call these services in production.
Up until now, they have just returned data so it hasn't been an issue.

The web services that update records will be in different EAR files and
therefore are different applications in Websphere from the ones that
just read data. There are only certain machines that should be able to
call the production services. Our web site is written in .NET, so we
want the machine running the .NET code to be able to call the web
services. From my understanding, digital certificates would be one way
to solve the problem. Since I haven't worked with digital certificates,
I was wondering if there was another approach that would work. I
noticed in the Apache configuration, there is the Allow directive. This
would allow you specify specific IP addresses to control access. I
added an "Allow from xx.x.x.xxx" directive to the end of the httpd.conf
file, but that didn't work. It basically didn't allow anyone to
connect. After reading the Apache documentation some more, it appears
that the "Allow from" directive should be specified within a <Directory>
or <Loc!
ation> or <Files> section. Since there aren't any files in the Apache
http server related to the web services, it seems like this method won't
work.

Does anyone have an idea if the "Allow from" directive should work? If
so, how? If not, what are my options? TIA

Dean Eshleman,
Software Development Architect

Everence Financial
1110 North Main Street
PO Box 483
Goshen, IN 46527
Phone: (574) 533-9515 x3528
www.everence.com




________________________________
Please note my e-mail address has changed

Confidentiality Notice: This information is intended only for the
individual or entity named. If you are not the intended recipient, do
not use or disclose this information. If you received this e-mail in
error, please delete or otherwise destroy it and contact us at (800)
348-7468 so we can take steps to avoid such transmission errors in the
future. Thank you.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2021 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.