Break the Glass - was: [xacml] Minutes for 27 April 2017 TC Meeting

[Steven Legg <steven.legg@viewds.com>]

On 28/04/2017 6:56 AM, rich levinson wrote:
>   Break the Glass (for ref):
>     Bill:
>      A draft document was posted by David Chadwick on the XACML email list:
>       https://lists.oasis-open.org/archives/xacml/201102/doc00000.doc
>
>      martin: seems like could be supported w core xacml
>      rich: basically agrees,
>       but there are other perspectives that need to be considered.

In one of the implementation options the document offers there are requirements
placed on the context handler that are outside core XACML. However I think the
proposal is more complicated than it needs to be. Rather than deny access and
provide an obligation (really it's advice) that tells the PEP that the user is
allowed to break the glass and try again, I would provide a Permit result and an
obligation that says that access is permitted only if (because it's an obligation)
the user elects to break the glass. If the PEP doesn't understand then the result
becomes Deny. If the PEP understands but is unable or unwilling to proceed with the
glass breaking the result still becomes Deny. If the PEP follows through with
obtaining user consent and the user agrees then access is permitted without any
follow up requests to the PDP. If the user isn't permitted to break the
glass to get access then the result wouldn't be Permit in the first place. The
preceding doesn't require any special support from the context handler, PDP or PAP.

If the obligation identifies which "pane" of glass needs to be broken then any
subsequent authorization requests requiring the same pane to be broken can
proceed without delay because the PEP and user already broke that pane. It is
left to the PEP to decide when to "fix" the pane, as appropriate to the context,
without bothering the PDP with a ResetBreakTheGlass action or the need to keep
state.

Whether going with a deny solution or permit solution, the most challenging part
is designing the policies such that, respectively, the Deny obligation isn't
returned when the user isn't allowed to break the glass, or the Permit obligation
isn't returned when the user has access anyway without breaking the glass.

Regards,
Steven