...@linux.vnet.ibm.com]
Sent: Wednesday, July 24, 2013 8:46 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Extending policy checking to include
target entities
I think we should transfer this discussion to the etherpad for this blueprint:
https
I think we should transfer this discussion to the etherpad for this blueprint:
https://etherpad.openstack.org/api_policy_on_target
I have summarised the views of this thread there already, so let's make any
further comments there, rather than here.
Henry
On 24 Jul 2013, at 00:29, Simo Sorce
On 07/23/2013 03:56 PM, David Chadwick wrote:
On 23/07/2013 18:36, Adam Young wrote:
On 07/23/2013 01:17 PM, David Chadwick wrote:
Of course the tricky thing is knowing which object attributes to fetch
for which user API requests. In the general case you cannot assume
that Keystone knows the
Hi
As part of bp
https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target I have
uploaded some example WIP code showing a proposed approach for just a few API
calls (one easy, one more complex). I'd appreciate early feedback on this
before I take it any further.
On Tue, Jul 23, 2013 at 10:40 AM, Henry Nash hen...@linux.vnet.ibm.comwrote:
Hi
As part of bp
https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target I
have uploaded some example WIP code showing a proposed approach for just a
few API calls (one easy, one more complex). I'd
When writing a previous ISO standard the approach we took was as follows
Lie to people who are not authorised.
So applying this approach to your situation, you could reply Not Found
to people who are authorised to see the object if it had existed but
does not, and Not Found to those not
Hi Henry
using the XACML processing model, the functionality that you are
describing, which you say is currently partly missing from Keystone, is
that of the context handler. Its job is to marshall all the attributes
that are needed and put them into the request context for calling the
policy
On 07/23/2013 12:54 PM, David Chadwick wrote:
When writing a previous ISO standard the approach we took was as follows
Lie to people who are not authorised.
Is that your verbage? I am going to reuse that quote, and I would like
to get the attribution correct.
So applying this approach
On 07/23/2013 01:17 PM, David Chadwick wrote:
Of course the tricky thing is knowing which object attributes to fetch
for which user API requests. In the general case you cannot assume
that Keystone knows the format or structure of the policy rules, or
which attributes each will need, so you
One thing we could do is:
- Return Forbidden or NotFound if we can determine the correct answer
- When we can't (i.e. the object doesn't exist), then return NotFound unless a
new config value 'policy_harden' (?) is set to true (default false) in which
case we translate NotFound into Forbidden.
On 23/07/2013 18:36, Adam Young wrote:
On 07/23/2013 01:17 PM, David Chadwick wrote:
Of course the tricky thing is knowing which object attributes to fetch
for which user API requests. In the general case you cannot assume
that Keystone knows the format or structure of the policy rules, or
On 23/07/2013 18:31, Adam Young wrote:
On 07/23/2013 12:54 PM, David Chadwick wrote:
When writing a previous ISO standard the approach we took was as follows
Lie to people who are not authorised.
Is that your verbage? I am going to reuse that quote, and I would like
to get the attribution
On 23/07/2013 19:02, Henry Nash wrote:
One thing we could do is:
- Return Forbidden or NotFound if we can determine the correct answer
- When we can't (i.e. the object doesn't exist), then return NotFound
unless a new config value 'policy_harden' (?) is set to true (default
false) in which
policy checking to include
target entities
...the problem is that if the object does not exists we might not be able tell
whether the use is authorized or not (since authorization might depend on
attributes of the object itself)so how do we know wether to lie or not?
Henry
On 23 Jul 2013, at 21
On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote:
...the problem is that if the object does not exists we might not be able
tell whether the use is authorized or not (since authorization might depend
on attributes of the object itself)so how do we know wether to lie or not?
If the
15 matches
Mail list logo
