atom feed43 messages in org.oasis-open.lists.xacmlRe: [xacml] Draft BTG Profile
FromSent OnAttachments
David ChadwickNov 23, 2010 9:06 am.doc
Rich.LevinsonNov 23, 2010 11:01 am 
Davis, John M.Nov 23, 2010 11:48 am.doc
Rich.LevinsonNov 23, 2010 11:53 am 
Smith, MartinNov 23, 2010 1:55 pm 
Mary McRaeNov 23, 2010 2:04 pm 
Ludwig SeitzNov 24, 2010 12:48 am 
David ChadwickNov 25, 2010 6:13 am 
David ChadwickNov 25, 2010 6:26 am 
David ChadwickNov 25, 2010 6:36 am 
Ludwig SeitzNov 25, 2010 7:05 am 
Doron GrinsteinNov 25, 2010 7:28 am 
David ChadwickNov 25, 2010 9:05 am 
David ChadwickNov 25, 2010 9:56 am 
Ludwig SeitzNov 26, 2010 12:31 am 
Ludwig SeitzNov 26, 2010 12:53 am 
Erik RissanenNov 26, 2010 2:25 am 
David ChadwickNov 26, 2010 8:51 am 
Bill ParducciNov 26, 2010 9:06 am 
David ChadwickNov 26, 2010 9:08 am 
Rich.LevinsonNov 28, 2010 12:41 pm 
David ChadwickNov 29, 2010 3:45 am 
David ChadwickNov 29, 2010 4:20 am 
Erik RissanenNov 29, 2010 5:38 am 
Davis, John M.Nov 29, 2010 8:45 am 
Smith, MartinNov 29, 2010 9:59 am 
Davis, John M.Nov 29, 2010 10:41 am 
David ChadwickNov 29, 2010 11:58 pm 
David ChadwickNov 30, 2010 12:33 am 
David ChadwickNov 30, 2010 12:47 am 
Smith, MartinNov 30, 2010 7:37 am 
David ChadwickDec 1, 2010 12:34 am 
David ChadwickDec 1, 2010 12:37 am 
David ChadwickDec 1, 2010 1:05 am 
David ChadwickDec 1, 2010 1:28 am 
Davis, John M.Dec 2, 2010 7:37 am.gif
David ChadwickDec 3, 2010 1:44 am 
Smith, MartinDec 3, 2010 5:58 am 
David ChadwickDec 3, 2010 7:17 am 
Davis, John M.Dec 6, 2010 10:05 am 
Davis, John M.Dec 8, 2010 10:14 pm.gif, .gif
Hal LockhartDec 16, 2010 9:02 am.gif, .gif
David ChadwickDec 16, 2010 11:24 am 
Subject:Re: [xacml] Draft BTG Profile
From:David Chadwick (d.w.@kent.ac.uk)
Date:Nov 29, 2010 11:58:37 pm
List:org.oasis-open.lists.xacml

Hi Erik

Having read Rich's post again, one way of interpreting it is that nothing needs to be done to the XACML standard since it does not need to understand BTG or do anything special for it. It only requires the policy writer to create some application specific obligations that indicate BTG related actions. I agree that this is one way of tackling BTG, and this is what we have already done in our existing implementation (since we had no alternative!).

However, this does not make things easy for applications since they need to do all the BTG processing themselves. Our objectives in standardising BTG are two fold:

i) to make it very easy for applications to support BTG ii) to make BTG supporting PDPs portable by defining a standard way of supporting BTG.

Using a standardised obligation to signal a BTG response would be (part of) the solution for ii) so this could work. Defining a standard BTG action as well would complete ii). We already have the machinery to do i) by using an XACML PDP wrapper

regards

David

On 29/11/2010 13:38, Erik Rissanen wrote:

Hi David,

There is also the approach suggested by Rich, which might solve it for you: use obligations. It would mean that the PEPs must understand the obligation since they cannot ignore it, but it would work in either 2.0 or 3.0. Would this work for you?

There is no standard negotiation protocol about XACML v2 vs v3 between PEP and PDP.

Best regards, Erik

On 2010-11-29 12:46, David Chadwick wrote:

Hi Erik

On 29/11/2010 08:58, Erik Rissanen wrote:

Ni David,

Yes, it is true that XACML 2.0 does not have advice.

However, the problem with the BTG-status code is that your proposal does not define in any manner what happens within the PDP to maintain the state of BTG or to perform the calculations to emit the BTG status code.

This is correct. This is because, when Seth was involved in the discussions last year, it was not agreed which component should be responsible for maintaining the BTG state, and flexibility should be maintained here. It could be the PEP, the context handler or PIP (ie. some intermediate component between the PEP and PDP), or the PDP. Consequently the draft profile was written allowing for all three possibilities.

In your proposal the PDP is a black box,

again correct, because we make no assumptions about the policy language that is supported by the PDP - the XACML request context is a good standard for interfacing to any PDP that supports any policy language.

and although we would define

the status code, there would be no way to write an XACML policy, in either 2.0 or 3.0 to actually emit the code.

This is also correct. Until an XACML PDP is state based I think this will continue to be the case. (In our particular implementation we maintain the state in the context handler/PIP component, and use the existing XACML request context to talk to an XACML PDP, but we need the enhanced XACML request context to talk to the PEP).

Would it be problematic for you to use the 3.0 schema and advice?

Theoretically no, we could use this for the request/response context, but practically it would mean that our PEPs would need to be enhanced to support XACMLv3. The lack of backwards compatibility between V3 and V2 request contexts is a problem. Do you have a version negotiation mechanism specified for PEPs talking to remote PDPs? Or are they supposed to know beforehand which protocol to talk?

regards

David

That

way your (non XACML I presume) PDP can emit the advice in a proprietary manner, and the 3.0 policy schema can be used to emit the advice by an XACML 3.0 PDP.

Best regards, Erik

On 2010-11-26 17:41, David Chadwick wrote:

Hi Erik

Unfortunately this has not answered the fundamental difference - Advice does not apply to XACMLv2.

On 26/11/2010 10:26, Erik Rissanen wrote:

Hi David,

There are a couple differences. Advice has an explicit expression syntax in the XACML policy schema, so the behavior of it can be controlled in the policy. The status code facility is much more limited in the spec.

But it is sufficient for our needs. So that is OK. You cannot argue that a single bit is limited if all you need to represent is a boolean.

Only a couple of error codes are defined and there are no standard expressions to control how the status detail is constructed.

we dont require status detail either.

Plus using a status code provides backwards compatibility for PEPs that dont understand the new status value.

So it seems like a perfect vehicle for passing back the new response type.

regards

David

The status

code mechanism was defined before I joined the TC, so I don't know the original motivation behind it, but I have always viewed it as a way for an implementation to signal errors in the processing. It's not intended to be used as part of normal policy decisioning. That is what advice is for.

Best regards, Erik

On 2010-11-25 18:57, David Chadwick wrote:

I dont see the difference between standardising a status code in a profile and standardising an Advice in a profile, except for one thing

Advice is not available to XACMLv2 implementations

regards

david

On 25/11/2010 15:29, Doron Grinstein wrote:

I agree with Ludwig. An Advice with a standard ID defined in a profile allows for interoperability. The PEP can enforce that the caller presents the necessary and expected attributes in order to perform the BTG. In addition the PEP should LOG the BTG operation so that an alert can be initiated, auditors will be advised, etc.

Doron Grinstein CEO BiTKOO

On Nov 25, 2010, at 7:06 AM, "Ludwig Seitz"<lud@axiomatics.com> wrote:

On Thu, 2010-11-25 at 14:36 +0000, David Chadwick wrote:

Hi Ludwig

answers below

...

Hi David,

I have some questions related to the proposed approach:

1.) You propose to introduce a new status code. Why not simply use Advice instead? It seems a bit superfluous to add new elements to the standard when there are suitable elements in the standard already.

the whole purpose of standardising the status code is so that different implementations can interwork without having to find out what the status code or Advice element is that is being set by a particular PDP.

Yes but you can achieve the same effect by just standardizing Advice-ids in a profile, without adding new elements to the XACML-schema and without requiring new behavior.

2.) You propose to introduce a new element called<Consequences>. Why not use either Advice or Obligation with AttributeAssignments instead?

We have used the syntax of Obligations, because this is what they are. But with one difference. They are future obligations that will come into effect if some future event happens. We did not want to call them obligations, since the semantic of these is quote "An operation specified in a policy or policy set that should be performed by the PEP in conjunction with the enforcement of an authorization decision"

Ok I guess then your approach with the "future obligations" is the one I don't see as necessary.

Why not use this procedure:

1. Return an Advice "user can BTG" with the Deny decision 2. Offer the user to perform the BTG action. If the user chooses to do so, a new attribute for that user is created. 3. Resubmit the original request with the new attribute 4. Other policies matching the BTG attribute now permit access (possibly with Obligations requiring special auditing).

General question: From the document you provided I cannot see the necessity for introducing new elements into the standard. Could you try to explain which functionality are you want to achieve that cannot be realized with the existing features of the standard?

1. A standard way of specifying this response type. By its very nature it needs to be in the standard.

2. A standard way of indicating future obligations.

I still don't see the necessity for changing the standard to implement this use-case. In fact Swedish healthcare implements BTG policies using XACML and the approach sketched above. So I'll try to clarify my question:

Given the fact that standardizing BTG in a profile is useful, why can it not be done without introducing new elements/functionality/behavior in the standard?

/Ludwig

-- Ludwig Seitz, PhD | Axiomatics AB Training& Development | Skeppsbron 40 Phone: +46 (0)760 44 22 91 | SE-111 30 Stockholm Mail: lud@axiomatics.com | Sweden

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--

***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security School of Computing, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5

*****************************************************************

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php