RE: [xacml-comment] 60-day Public Review for REST Profile of XACML 3.0 - Conformance issues

[DANGERVILLE Cyril <cyril.dangerville@thalesgroup.com>]

Hi Steven,
I appreciate your take on this. It goes in the positive way for us.
Just one comment though when you point out that the spec says "system" and not "web server" without being specific. I get the subtlety. Still the word "server" pops up again in the "Predicate" part of the assertion table (urn:oasis:names:tc:xacml:3.0:profile:rest:assertion:home:documentation), bringing back the confusion:  
"Normative Source" reads "A RESTful XACML system MUST have a single entry point at a known location..."  - so far so good
BUT
"Predicate" reads "The [documentation] lists a [...] single entry point URL at which the SERVER can be accessed"

So my RECOMMENDATION TO THE TC in order to remove this confusion:
Change the part "URL at which the server can be accessed" to something like "URL at which the XACML system can be accessed."

Kind regards,
Cyril

-----Original Message-----
From: Steven Legg [mailto:steven.legg@viewds.com] 
Sent: mardi 19 décembre 2017 01:35
To: DANGERVILLE Cyril; xacml-comment@lists.oasis-open.org
Subject: Re: [xacml-comment] 60-day Public Review for REST Profile of XACML 3.0 - Conformance issues


Hi Cyril,

On 19/12/2017 7:15 AM, DANGERVILLE Cyril wrote:
> Hello,
> 
> I would like some clarification from XACML TC on 2 issues I have with conformance clause *4.2.2 (Entry Point) of REST Profile*, to check whether our implementation could be considered compliant or not.

Here is my take on the entry point functionality:
https://lists.oasis-open.org/archives/xacml/201708/msg00012.html

The TC has decided to go with approach 1, which basically means you can do what you like. That is answer enough, but read on if you would like a pedantic answer to your questions.

> 
> Let’s say we provide a multi-tenant REST API where each tenant has a specific “single entry point” for its RESTful XACML system:
> 
> For tenant X, it would be:
> 
> https://az.example.com/domains/X
> 
> For tenant Y, it would be:
> 
> https://az.example.com/domains/Y
> 
> etc.
> 
> My *first issue* is with the assertion */urn:oasis:names:tc:xacml:3.0:profile:rest:assertion:home:documentation/* which seems to say there should be a single entry point for the XACML system across the whole web server, whereas here there is one per tenant (or domain).
> 
> Have I got that wrong? Or *is this kind of multi-tenant API still 
> compliant somehow?*

It says "system" not "web server", without being specific, so it is entirely up to you what constitutes a system. Just regard X and Y as separate systems.

> 
> Now regarding my next issue, when one makes a GET request on https://az.example.com/domains/X , one would get a status code 200 with the following response payload (some content omitted):
> 
> <domain xmlns:atom="http://www.w3.org/2005/Atom";>
> 
> …
> 
>    <atom:link rel="item" href="/properties" title="Domain 
> properties"/>
> 
>    <atom:link rel="item" href="/pap" title="Policy Administration 
> Point"/>
> 
> *<atom:link*
> 
> *   rel="http://docs.oasis-open.org/ns/xacml/relation/pdp"*
> 
> *   href="/pdp" title="Policy Decision Point"/>*
> 
> …
> 
> </domain>
> 
> My *issue* then is with the last sentence of *2.2.1 Entry Point* which says:
> 
> /The XACML entry point representation that is returned SHOULD NOT contain anything other than links to other resources specified in this profile/.
> 
> (Side note: I would be interested to know why there should not be any 
> other resource link btw.)

I don't know a reason. It seems unnecessary. In any case it is a SHOULD NOT, and with no obvious reason for abiding by it any sensible reason to ignore it is good enough.

Regards,
Steven

> 
> However, the assertion */urn:oasis:names:tc:xacml:3.0:profile:rest:assertion:home:pdp /*does not mention that requirement again but simply says:
> 
> /                The XACML entry point representation SHOULD contain 
> *a link *to the PDP./
> 
> //
> 
> In my case I have a link to some “/pap” resource besides the link to 
> the “/pdp” (and some other things); so all in all, *would this be 
> considered compliant in TC’s opinion?*
> 
> Thanks for any light on this.
> 
> Kind regards,
> 
> Cyril
> 
> ---
> 
> *Cyril Dangerville*
> 
> Security Engineer, CISSP
> 
> Thales Services