In Tomcat 4, you can also set up a "Remote Access Filter Valve" in the 
web.xml file. Here is an explanation of it: 
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/valve.html

I have not used this for the SOAP administrator, but I have used it in 
other cases and it works.

Mark




At 05:06 PM 15/10/2002 -0400, you wrote:
>First, did you also follow these instructions from the docs?
>
> >>>
>
>Controlling Access to the ServiceManager
>Although the SOAP interface for deploying/undeploying services can be
>very useful during development, it is not always desirable to expose
>such capabilities in a runtime environment. Apache SOAP provides the
>ability to enable/disable the SOAP interface to the ServiceManager by
>setting a boolean flag in the configuration file. If the flag is set to
>true, or if it is not present, then the SOAP interface is enabled. If it
>is set to false, then the ServiceManagerClient, as well as any other
>client which uses that interface, will not be able to communicate with
>the ServiceManager. However, anything which communicates with the
>ServiceManager directly, such as the admin JSP pages, will still be able
>to alter the state of the ServiceManager.
>
>
>------------------------------------------------------------------------
>--------
>
><<<
>
>Frankly, I don't understand how you could use catalina.policy to control
>access to the admin pages.  I thought the policy controlled what the
>code in the JSP/class/jar could do, not who could access it.
>
>One way to control access is by defining a security constraint in the
>web.xml file.  I've used this to force a login for the admin pages:
>
>   <!-- Define a Security Constraint on the Admin pages -->
>   <security-constraint>
>     <web-resource-collection>
>       <web-resource-name>Apache SOAP Administrator</web-resource-name>
>       <url-pattern>/admin/*</url-pattern>
>     </web-resource-collection>
>     <auth-constraint>
>        <!-- NOTE:  This role is not present in the default users
>file -->
>        <role-name>manager</role-name>
>     </auth-constraint>
>   </security-constraint>
>
>   <!-- Define the Login Configuration for this Application -->
>   <login-config>
>     <auth-method>BASIC</auth-method>
>     <realm-name>Apache SOAP</realm-name>
>   </login-config>
>
>Scott Nichol
>
>----- Original Message -----
>From: "Ladwig, Mike" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Tuesday, October 15, 2002 3:24 PM
>Subject: Restricting access to the SOAP administration client
>
>
> > Hi!
> >
> > I've gotten a soap service working nicely, and now I want to try it
>out in
> > the real world.  Unfortunately, by default soap installs a gaping
>security
> > hole as the administrative client.  I badly want to make it impossible
>to
> > access this from anywhere other than the localhost.
> >
> > I found this in the FAQ:
> > >Modify your servlet container's security settings so that only
>certain IP
> > addresses can access the admin page. If you >are running Tomcat with
>its
> > security manager, you can add an entry for the soap webapp in the
>.policy
> > file located in >the conf directory, and then you can control which IP
> > addresses the webapp will accept connections from.
> >
> > This would be great advice, and would work pretty well for me.
> > Unfortunately, I am unable to find any details on how to accomplish
>this in
> > the /etc/tomcat4/catalina.policy file.  I am running tomcat 4.04 with
>the
> > soap.war file dumped in the webapps directory, and as far as I can
>tell, by
> > the time this .policy file gets included, there isn't a way to
>restrict the
> > IP addresses soap will talk to.
> >
> > Has anyone ever been able to actually get the FAQ advice to work?  If
>so,
> > could you point me in the right direction?
> >
> > Thanks,
> > mike.
> >
> > --
> > To unsubscribe, e-mail:
><mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
><mailto:[EMAIL PROTECTED]>
> >
> >
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to