Re: Post to the Web400 mailing list

[TAllen@xxxxxxxxxxxx]

I don't have the Apache manual handy but you can certainly limit access to
the web service URL by IP address.  This can be done with any URL.  Of
course IP addresses can be spoofed but if this is only internal then that
should suffice.

Thanks,
Todd Allen
EDPS
Electronic Data Processing Services
tallen@xxxxxxxxxxxx




                                                                           
             Dean Eshleman                                                 
             <Dean.Eshleman@ev                                             
             erence.com>                                                To 
             Sent by:                  "'web400@xxxxxxxxxxxx'"             
             web400-bounces@mi         <web400@xxxxxxxxxxxx>               
             drange.com                                                 cc 
                                                                           
                                                                   Subject 
             2011-03-30 14:10          [WEB400] Post to the Web400 mailing 
                                       list                                
                                                                           
             Please respond to                                             
             Web Enabling the                                              
              AS400 / iSeries                                              
             <web400@midrange.                                             
                   com>                                                    
                                                                           
                                                                           




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



 
This communication and any transmitted documents are intended to be confidential. If there is a problem with this transmission, please contact the sender. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.