[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Break the Glass policies
Hi David. You raise some interesting points, but respectfully I have to disagree with you. > Firstly the PEP must operate by never sending this BTG attribute in its > first request context I have built *many* systems where the user knows that they are supplying an attribute in the initial request to "break the glass." This can happen for many reasons, through the usual use-cases have to do with emergency medical access or other "first-responder" systems. I don't think this is required, but it's definitely a common scenario that I've come across in practice in many systems. > [...] > i) does a clever PEP anticipate that the attribute is needed and > therefore provide it, so that two calls are not needed? This is entirely application-specific, as is everything else that you raise. It is *impossible* to know if a give application will want to query the user to ask if it's ok to "break the glass" with each request, if it wants to implement SSO, or if it wants to implement this silently. This is a fact. It has nothing to do with the given system. No matter what is supported directly in XACML, each system will have its own requirements, and I can say this confidently based on many years of working with teams who are trying to support exactly these kinds of use-cases. It doesn't matter if there's some special BTG return or an Indeterminate, it's the same scenario. In both cases, the PDP says that it can't make a decision and provides detail about what it's missing to make that decision. The PEP is left to interpret this and decide what to do. It can be the current Indeterminate response or some new kind of response, but that will have *no* effect on the PEP, which will still be application-specific and have to decide how it responds to the PDP's decision. In other words, any issues of how "smart" or "dumb" or "stateful" a PEP is doesn't come into play here. There is simply no difference between returning a special return type and retuning Indeterminate for a known attribute, except that the later is already part of the standard and can be modeled in the current XACML policy format. The only issue here is whether there is some *standard* behavior for a resposnse from the PDP which specifies that we're in a BTG scenario and more detail is required. This has nothing to do with the response format itself, but could be defined by a profile that defines well-known attributes and well-known behavior based on those attributes. seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]