9 messages in org.oasis-open.lists.xacmlRE: [xacml] Groups - REST Profile of ...| From | Sent On | Attachments |
|---|---|---|
| Remon Sinnema | Apr 24, 2012 4:01 am | |
| David Brossard | Apr 24, 2012 6:32 am | |
| remo...@emc.com | Apr 24, 2012 8:24 am | |
| remo...@emc.com | Apr 24, 2012 11:14 pm | |
| David Brossard | Apr 25, 2012 4:21 am | |
| Danny Thorpe | May 3, 2012 10:17 am | |
| remo...@emc.com | May 3, 2012 12:31 pm | |
| Danny Thorpe | May 3, 2012 3:38 pm | |
| remo...@emc.com | May 3, 2012 11:27 pm |
| Subject: | RE: [xacml] Groups - REST Profile of XACML v3.0 Version 1.0, working draft 02 uploaded | |
|---|---|---|
| From: | Danny Thorpe (Dann...@quest.com) | |
| Date: | May 3, 2012 3:38:57 pm | |
| List: | org.oasis-open.lists.xacml | |
inline
-----Original Message-----
From: remo...@emc.com [mailto:remo...@emc.com]
Sent: Thursday, May 03, 2012 12:32 PM
To: Danny Thorpe
Cc: xac...@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