You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Rahul Thakur <ra...@gmail.com> on 2007/04/27 10:13:06 UTC
XML RPC security
Hey guys,
Some quick notes on the security for XML RPC interface. This is what I
am thinking...
Have an AuthenticatedXmlRpcService component that services the xml rpc
requests. The first request from a client to the service is a request
for authentication. A successful authentication returns an
authentication Token, which is passed along with subsequent requests by
the client. A Token can go stale (configurable time period?) if there
were not requests detected for it. Also, we could have a service that
answers any polling requests and keeps a Token 'alive'.
Thoughts?
Rahul
Re: XML RPC security
Posted by Trygve Laugstøl <tr...@apache.org>.
Rahul Thakur wrote:
>
> Sounds good! Pointers would be great, if you have it handy :-)
If you're using the servlet way (which I'd recommend) you should be able
to use Redback as a filter for that URL. Way easier that my hack.
--
Trygve
>
> TIA,
> Rahul
>
> ----- Original Message ----- From: "Trygve Laugstøl" <tr...@apache.org>
> To: <co...@maven.apache.org>
> Sent: Saturday, April 28, 2007 12:14 AM
> Subject: Re: XML RPC security
>
>
>> Rahul Thakur wrote:
>>> Hey guys,
>>>
>>> Some quick notes on the security for XML RPC interface. This is what
>>> I am thinking...
>>>
>>> Have an AuthenticatedXmlRpcService component that services the xml
>>> rpc requests. The first request from a client to the service is a
>>> request for authentication. A successful authentication returns an
>>> authentication Token, which is passed along with subsequent requests
>>> by the client. A Token can go stale (configurable time period?) if
>>> there were not requests detected for it. Also, we could have a
>>> service that answers any polling requests and keeps a Token 'alive'.
>>
>> How about using HTTP and Redback for security? We can make the XML-RPC
>> server listen on localhost:8000 only and then make a servlet that is
>> proxying to localhost:8000/xml-rpc.
>>
>> The proxying servlet should come after a Redback security filter. I
>> made a servlet like that once acting as a facade for a Subversion
>> repository which I think I added to Plexus (aka the kitchen sink), if
>> not I can dig it up for you.
>>
>> --
>> Trygve
>
Re: XML RPC security
Posted by Rahul Thakur <ra...@gmail.com>.
Sounds good! Pointers would be great, if you have it handy :-)
TIA,
Rahul
----- Original Message -----
From: "Trygve Laugstøl" <tr...@apache.org>
To: <co...@maven.apache.org>
Sent: Saturday, April 28, 2007 12:14 AM
Subject: Re: XML RPC security
> Rahul Thakur wrote:
>> Hey guys,
>>
>> Some quick notes on the security for XML RPC interface. This is what
>> I am thinking...
>>
>> Have an AuthenticatedXmlRpcService component that services the xml
>> rpc requests. The first request from a client to the service is a
>> request for authentication. A successful authentication returns an
>> authentication Token, which is passed along with subsequent requests
>> by the client. A Token can go stale (configurable time period?) if
>> there were not requests detected for it. Also, we could have a
>> service that answers any polling requests and keeps a Token 'alive'.
>
> How about using HTTP and Redback for security? We can make the XML-RPC
> server listen on localhost:8000 only and then make a servlet that is
> proxying to localhost:8000/xml-rpc.
>
> The proxying servlet should come after a Redback security filter. I
> made a servlet like that once acting as a facade for a Subversion
> repository which I think I added to Plexus (aka the kitchen sink), if
> not I can dig it up for you.
>
> --
> Trygve
Re: XML RPC security
Posted by Emmanuel Venisse <em...@venisse.net>.
Instead of use the actaul embedded xmlrpc server that run on a different port, we can use The xmlrpc servlet (http://ws.apache.org/xmlrpc/server.html)
Emmanuel
Trygve Laugstøl a écrit :
> Rahul Thakur wrote:
>> Hey guys,
>>
>> Some quick notes on the security for XML RPC interface. This is what I
>> am thinking...
>>
>> Have an AuthenticatedXmlRpcService component that services the xml rpc
>> requests. The first request from a client to the service is a request
>> for authentication. A successful authentication returns an
>> authentication Token, which is passed along with subsequent requests
>> by the client. A Token can go stale (configurable time period?) if
>> there were not requests detected for it. Also, we could have a service
>> that answers any polling requests and keeps a Token 'alive'.
>
> How about using HTTP and Redback for security? We can make the XML-RPC
> server listen on localhost:8000 only and then make a servlet that is
> proxying to localhost:8000/xml-rpc.
>
> The proxying servlet should come after a Redback security filter. I made
> a servlet like that once acting as a facade for a Subversion repository
> which I think I added to Plexus (aka the kitchen sink), if not I can dig
> it up for you.
>
> --
> Trygve
>
>
>
Re: XML RPC security
Posted by Trygve Laugstøl <tr...@apache.org>.
Rahul Thakur wrote:
> Hey guys,
>
> Some quick notes on the security for XML RPC interface. This is what I
> am thinking...
>
> Have an AuthenticatedXmlRpcService component that services the xml rpc
> requests. The first request from a client to the service is a request
> for authentication. A successful authentication returns an
> authentication Token, which is passed along with subsequent requests by
> the client. A Token can go stale (configurable time period?) if there
> were not requests detected for it. Also, we could have a service that
> answers any polling requests and keeps a Token 'alive'.
How about using HTTP and Redback for security? We can make the XML-RPC
server listen on localhost:8000 only and then make a servlet that is
proxying to localhost:8000/xml-rpc.
The proxying servlet should come after a Redback security filter. I made
a servlet like that once acting as a facade for a Subversion repository
which I think I added to Plexus (aka the kitchen sink), if not I can dig
it up for you.
--
Trygve