OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 02 uploaded


inline

-----Original Message-----
From: remon.sinnema@emc.com [mailto:remon.sinnema@emc.com] 
Sent: Thursday, May 03, 2012 12:32 PM
To: Danny Thorpe
Cc: xacml@lists.oasis-open.org
Subject: RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 02 uploaded

[...]

>> For example, what is the REST entry point referred to in 2.3.1?  For 
>> a PDP at http://pdp.example.com/v1/, is the REST entry point 
>> described in 2.3.1 http:/pdp.example.com/, which will list the v1 url 
>> as one of the interfaces provided by that server and only that 
>> server?  Or is the REST entry point an entirely separate service 
>> entity (http://discover.example.com) which lists available PDP (and 
>> other) interfaces on all servers? <<

I'm not sure I understand the implications of having multiple servers. Do you envision those servers to be identical, or could each have their own capabilities?

[DT] Different PDP servers running different policy sets. Could be separated by administrative or organizational domains (divisions within a company) or by operational or geographic domains (export regulations in the Singapore office vs card access to the San Francisco office building. Completely unrelated domains, why should they be on the same PDP?). Another multi-PDP case is phased deployment: one server in production, one for staging and testing new policy revisions.  The two PDPs could be on the same network and visible to clients, but the test PDP should be locked down to only accept requests from authorized testers.


> Section 2.3.1 REST Entry Point uses HTTP GET to obtain information about what services / interfaces are available.  Isn't that the job of the HTTP OPTIONS method?

The response to an OPTIONS call lists which HTTP verbs are allowed on the REST resource (using the Allow header). What I'm talking about here is which REST resources are available on the server. I don't think you can do that in a standard way with OPTIONS.

Also, OPTIONS is not cacheable, while GET is. And since this information is not likely to change much, we should take advantage of caching.

[DT] Ok, good points. :>

> Should section 2.3.1 mention anything about best-practices such as filtering results to only return links to services that the client credentials are authorized to use? 

Yes, definitely.


>> If an organization has multiple PDPs running, and some of them are 
>> domain specific and only accessible to certain clients, it could be 
>> considered a breach of disclosure if the REST Entry Point returned 
>> all the PDP services links, including links to services that the 
>> client can't access. <<

I guess the current draft assumes a single server or farm of identical servers. I haven't really thought about multiple servers with different capabilities.

[DT] It would probably be best to limit the scope of the REST Entry Point to the server receiving the request. For replicated identical servers behind a load balancer, each individual server speaks for the collective - the returned links would not be bound to that specific server machine.  

Discovery of services across multiple different servers is probably out of scope for this discussion.

Thanks!
-Danny


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]