This really seems a good practice. However, isn't it going to produce
a (sort of) recursion? I mean, once the AA is in place and a request
is made for certain URI, the service is supposed to check for proper
authorization... Not to mention the fact that the policy service would
have to also authenticate itself first... Hmmm, complex...

Then again, it would still work if the service returns 404 for
non-existing resource before doing any authorization (and not
expecting any authentication info: token or user/pass)... But would it
really be that way? What would the developers say about this?

Cheers,
Luchesar


On Mon, Jun 28, 2010 at 14:28, Andreas Maunz <andreas at maunz.de> wrote:
> Dear all,
>
> I propose to make the A&A policy webservice more secure by checking
> availability of resource URIs at policy upload time.
> This is to tackle the issue of "pre-registration", i.e., to stop an attacker
> from registering arbitrary "promising" resource URIs (not under his
> control), by enforcing that every URI in a policy is actually reachable.
> Being "reachable" means that the webservice at the corresponding URI reacts
> by returning an arbitrary return code other than "404 (not found)".
> If nothing speaks against that I will add the functionality within the next
> few days. Please tell me, if you hold a different view on the issue.
>
> Best regards
> Andreas
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>