[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] BTG comment
Hi Rich there is one other objective that I would like to achieve, and that is to implement this feature in an application independent manner so that all applications can write BTG policies for their XACML PDPs and all PEPs can utilise them without having to implement additional state handling code themselves. All the PEP needs to do, upon recognising the new BTG obligation response, is ask the user who has just been denied access if he wants to break the glass to gain access, and if the user answers Yes, to send the standardised BreakTheGlass operation to the PDP. We have already done this and have a public demonstration of it available here https://authz.tas3.kent.ac.uk:8443/btg/m-index.html regards David On 22/03/2011 07:45, Rich.Levinson wrote: > Hi David, > > I agree w your recollections, and I agree that the PEP > does not need to know what is going on. The "minimum" > implementation I think is to simply send in this additional > attribute which indicates "break the glass" in order to attempt > to alter the flow of the policy logic and get a Permit, since > without the additional attribute the user is stuck with a Deny. > > I think the rest of the discussion is really about different > ways that a user can obtain this attribute, whether all users > or only selected users can obtain this attribute, whether > the policy should provide obligations or advice, to tell the > PEP that it might want to suggest to the user that the > attribute might be available, etc. > > Also, there seems to be a distinction between the more > global "the building is on fire" vs the emergency dealing > with a single situation within the organization, which might > mean there is more than one attribute that might be > needed to cover different types of emergencies. > > It appears to me based on the comments that several communities > have found the need for this capability and that there is not > yet common understanding as to how this capability is most > effectively realized with XACML. > > I have no preferred outcome as to action, I think the discussion > has been enlightening and I believe I understand effective ways > to implement this and that RSA 2008 is a good starting point. > However, there does also appear to be interest in coming up > with a common model which can facilitate some "best pratices" > that might be generally useful to anyone trying to use XACML. > > Thanks, > Rich > > > > > > > Staggs, David (SAIC) wrote: >> >> Rich >> >> As you said, the approach you cite was demonstrated in the health care >> use cases during the RSA2008 interop and incorporated into the XSPA >> profile of XACML for healthcare.As I recall, the PEP did not have to >> understand that a first request was denied because of a “break the >> glass” variable – rather, the request that was denied was re-issued by >> the application with an emergency “purpose of use” (POU) if the use >> case justified the need to go beyond the “normal healthcare” POU. This >> avoids the issue of retaining state information or an additional BTG >> variable. >> >> Cheers, >> >> David >> >> David Staggs, JD, CISSP (SAIC) >> Veterans Health Administration >> Chief Health Informatics Office >> Standards and Interoperability >> Office: 858 433 1473 >> >> ------------------------------------------------------------------------ >> >> *From:*Rich.Levinson [mailto:rich.levinson@oracle.com] >> *Sent:* Monday, March 21, 2011 11:47 AM >> *To:* Tyson, Paul H >> *Cc:* xacml@lists.oasis-open.org >> *Subject:* Re: [xacml] BTG comment >> >> Hi Paul, >> >> I agree there are some issues when you get into the details in the >> version of the >> BTG proposal you ref'd. When we discussed the proposal at the Feb 10 mtg, >> I suggested to David that a diagram would help clarify some things: >> http://lists.oasis-open.org/archives/xacml/201102/msg00020.html >> David sent the clarifying diagram: >> http://lists.oasis-open.org/archives/xacml/201102/msg00021.html >> >> In response to that diagram my general comment to the discussion: >> http://lists.oasis-open.org/archives/xacml/201102/msg00042.html >> concluded by saying: >> >> With respect to David's documents, I basically agree with the >> approach, except for statements like in the protocol descr step 8, >> where it says: "The PDP sets the relevant BTG-state variable >> to true ...". >> >> I think it is fine to return an Obligation as the Profile describes, >> and that this be used as the basis of the User obtaining a >> "BTG-State" Attribute, which can be submitted in the >> follow-up request. I think the presence of this attribute >> is sufficient "state" for the Policy to evaluate properly. >> >> A couple weeks later, David re-initiated the discussion: >> http://lists.oasis-open.org/archives/xacml/201103/msg00014.html >> >> where he stated: >> >> * The PDP is and remains stateless. >> * The request context carries the current state of the system to >> the PDP. >> * A component of the XACML system (might be a PIP, or it might be >> something new) picks up the current state of the system from the >> StateDB and inserts these attributes into the request context >> for passing to the PDP. >> * When certain authz decision requests are granted (or denied) >> this might cause a change in the state of the system. A new >> component is needed which updates the StateDB when this occurs. >> >> I don't think there are any issues w the 1st 3 bullets, where the 3rd >> bullet, imo, simply says there >> is a PIP that provides attrs for the request context from a thing >> called StateDB. >> >> The 4th bullet, imo, slightly "overstates" what I consider to be >> happening. I think the PDP thru >> Obligations can return information that MAY result in someone (such as >> the doctor executing BTG) >> updating of "changing" the state of the system by changing some >> attribute in StateDB. >> >> However, it does make the point that this is basically the purpose of >> this style of Policy, namely >> that features are available that enable overriding "normal state >> conditions", by enabling the changing >> of some state somewhere by an authorized party, and we are making a >> concrete abstraction of >> where this state exists (in StateDB), and how it is accessed (by PIPs >> that can retrieve attributes >> in standard XACML form). >> >> Whether the PEP itself, changes the state, or maybe an impatient >> doctor sets up a script that >> automatically responds to this situation when the qualified Deny is >> returned, that automatically >> goes ahead and breaks the glass and resubmits the request, starts to >> get into a fuzzy area >> where one could say that maybe the phrase "certain authz decision >> requests are granted >> (or denied) this might cause a change in the state of the system" is >> ambiguous enough to be >> accurate w/o giving the PEP authority to change state on its own. >> >> Additionally, there are a few places where David has made statements, >> like the following >> in the protocol flow document: >> >> "(6) The application can now ask the user if she wants to break the glass >> for access. If the user chooses to (giving a reason, if applicable) >> then the application >> sets the BTG state to true, and performs any necessary >> obligations/notifications etc. >> If the user chooses not to break the glass then the request terminates >> here." >> >> To me this pretty clearly puts the "state-changing" capability in the >> proper place, i.e. in >> the hands of an individual authorized to change the state. >> >> Does all this mean to me that the "profile" is ready to go? No. >> However, I think there >> is a substantive gathering of relevant information from which TC >> members could >> collaborate and come up with something that represents a consensus, >> which could >> be a "profile", a "set of guidelines on a wiki page or document". >> >> Thanks, >> Rich >> >> >> >> Tyson, Paul H wrote: >> >> Rich, >> >> David’s proposal attached to [1] talks about changing the effective >> request context as a result of the request/response (see sections >> 2.3.1, 2.3.2, and 2.3.3). It unfortunately also uses the word “state” >> which has caused a lot of confusion. Because the context handler is >> not well specified by XACML, it would be possible to interpret and >> implement this BTG profile in many different ways. But one way is >> clearly that the PDP will simple cache a XACML attribute that says >> BTG=true. Another way is that the PEP will cache BTG=true, and send it >> to the PDP in subsequent requests. But if the PDP doesn’t remember >> that it told the PEP it was OK to break the glass, why should it trust >> this assertion? Is the PDP also going to certify to the PEP that the >> glass is broken, so the certification token can be returned to it in >> subsequent requests? It all gets very muddled as a result of making >> the request/response protocol do more than it should. >> >> Regards, >> >> --Paul >> >> [1] http://lists.oasis-open.org/archives/xacml/201102/msg00017.html >> >> *From:*Rich.Levinson [mailto:rich.levinson@oracle.com] >> *Sent:* Friday, March 18, 2011 17:23 >> *To:* Tyson, Paul H >> *Cc:* Davis, John M.; Erik Rissanen; David Chadwick; >> xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> >> *Subject:* Re: [xacml] BTG comment >> >> Hi Paul, >> >> I am not sure I understand the objections you are raising. I have put >> comments >> inline below, trying to respond to the points you have made. >> >> As I have indicated in prev emails, I believe the proposal is using >> standard mechanisms >> and not introducing any "state" to the PDP, other than the implicit >> state of the request >> context which already exists, nor is it doing anything significantly >> different from techniques >> we have already used in the RSA 2008 Interop, where we had policies for >> emergency conditions based on an emergency-override attribute that a >> subject >> could obtain thru some external mechanism from a trusted authority >> that could >> then be submitted with the request. If you are interested the details >> of that Interop >> are in the XACML Repository: >> http://www.oasis-open.org/committees/document.php?document_id=28030&wg_abbrev=xacml >> <http://www.oasis-open.org/committees/document.php?document_id=28030&wg_abbrev=xacml> >> >> (In the doc description of the zip file at the above URL, it is item >> #2 that contains >> the specification with details of requests and responses and policies >> in section 2.2.4 >> that describes the "Emergency Access Use Case".) >> >> Thanks, >> Rich >> >> Tyson, Paul H wrote: >> >> Erik seems to appreciate my objection to David's BTG proposal, which has >> nothing to do with stateful or stateless PDPs, but with my desire to >> restrict (or at least not to sanction) the use of the request/response >> mechanism to directly change attribute values in the request context. >> >> >> In the proposed approach, there is only one request context, which is >> initially populated by >> the request from the PEP. It can subsequently have "additional" >> attributes set during Policy >> evaluation if a referenced attribute is not present and the PDP calls >> out to a PIP to supply >> the attribute. >> >> The response does not get created until policy evaluation has >> completed, and once created, >> the request context is no longer used for anything. >> >> i.e. I don't understand what you mean when you refer to your "desire >> not to sanction the use >> of the request/response mechanism to directly change attribute >> values". That is not what is >> happening here. The original attributes are left intact. Additional >> attributes may be "read" >> from a PIP. >> >> >> >> If one wants to analyze the request context one should only have to look >> at how the PIP is implemented (and of course the attribute instances >> conveyed by the original request). Introducing a distinguished >> action-id value or specialized attribute id that has the power to modify >> the request context makes it harder to analyze. The only virtue of this >> approach is convenience, and it seems a slim virtue at that. It should >> be possible to set up a 3rd-party service that can communicate with the >> PEP and PIP as necessary to set and retrieve BTG state. >> >> >> I think that is exactly what the proposal is. The "StateDB" would >> generally sit behind a PIP and >> the Policy can request the BTG state attribute, or the PEP can get it >> in advance and send it in. >> >> >> >> The patient's medical condition, whether or not the building is on fire, >> and the client's bank account history are all things that are outside >> the scope of XACML. Information about them should come into the XACML >> system in the normal ways: either from a trusted source via the PEP, or >> a PIP. >> >> >> I don't believe there is anything in this proposal at variance with >> this. All information is coming >> in normal ways thru trusted PEP or PIP. >> >> >> >> >> Regards, >> --Paul >> >> -----Original Message----- >> From: Davis, John M. [mailto:Mike.Davis@va.gov] >> Sent: Friday, March 18, 2011 13:34 >> To: Rich.Levinson; Erik Rissanen; David Chadwick >> Cc:xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> >> Subject: RE: [xacml] BTG comment >> >> I think we are agreed. The attributes of the StateDB can refer to both >> the policy set and the attribute used to evaluate the request, eg. >> "Normal Healthcare Rules", or "BTG Rules" plus"Normal Healthcare >> attributes" or "BTG Attributes". The implication is that the user >> request would include the requester purpose of use (setting the state), >> and associated attributes which combined with existing attributes about >> the (from various sources) relative to that POU allows for decision. >> User asserted information, and in particular purpose of use, is >> included in the XSPA profiles of XACML, SAML and WS-Trust as a mandatory >> attribute. >> >> Regards, Mike Davis, CISSP >> Department of Veterans Affairs >> Office of Health Information >> Security Architect >> 760-632-0294 >> >> >> -----Original Message----- >> From: Rich.Levinson [mailto:rich.levinson@oracle.com] >> Sent: Friday, March 18, 2011 10:13 AM >> To: Erik Rissanen; David Chadwick >> Cc:xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> >> Subject: Re: [xacml] BTG comment >> >> Hi Erik, Paul, Mike, Hal, and David, >> >> I believe David's position: >> http://lists.oasis-open.org/archives/xacml/201103/msg00017.html >> >> is consistent with the position I recommended: >> http://lists.oasis-open.org/archives/xacml/201102/msg00042.html >> and originally, when this discussion began last year: >> http://lists.oasis-open.org/archives/xacml/201011/msg00040.html >> >> so, I think David and I are pretty much in agreement on the concepts >> at this point. >> >> The bottom line is that any "state" that is evaluated by the PDP >> policies >> is contained in the request context in attributes. Who maintains those >> attributes and how they get into the request context is dependent on >> the system designers, and the Policy designers. But the PDP, itself, >> should not require any changes from XACML 2.0 or 3.0 to implement >> this. >> >> From my perspective, "StateDB" is nothing more than an attribute >> repository, whose attributes can be referenced in Policy statements. >> >> Also, from my perspective, a "profile" might be useful, but is not >> required >> for anyone to use this system design strategy with either XACML 2.0 or >> XACML 3.0. >> >> Thanks, >> Rich >> >> >> Erik Rissanen wrote: >> >> >> Paul, all, >> >> >> >> I am not sure if there is a motivation for it, but there would be a >> >> need for an XACML state component if the desired behavior is that >> >> "state is changed when an access decision says Permit" (Or deny). This >> >> >> >> >> >> >> is distinct from "state is changed when an access to a resources is >> >> performed". >> >> >> >> In the bank case, clearly it should be the latter case, that is, the >> >> PEP enforces the Permit, by which the banking application will change >> >> the amount in the account. >> >> >> >> I cannot think if a specific real world example of the case where the >> >> decision by the PDP itself would cause a state change. >> >> >> >> Also It might be useful from a purely practical implementation point >> >> of view though. Not sure. Anybody? >> >> >> >> Best regards, >> >> Erik >> >> >> >> On 2011-03-15 21:42, Tyson, Paul H wrote: >> >> >> >> The 3rd example differs from the previous 2 in that the XACML request >> >> >> >> is >> >> >> simultaneously *changing* the request context and requesting >> >> >> >> permission >> >> >> to perform an action. >> >> >> >> Nothing in the XACML spec prevents this (as far as I can see), but it >> >> overloads the request message unnecessarily. I would not want to >> >> sanction this behavior in an official profile. I believe it >> >> >> >> simplifies >> >> >> analysis to assume that the request/response sequence is idempotent >> >> >> >> with >> >> >> respect to the request context. >> >> >> >> Nothing prevents an implementation from using other communication >> >> channels to modify the environment to cause a change in the >> >> >> >> evaluation >> >> >> context. In the bank account examples, it would seem a very poor >> >> >> >> design >> >> >> to make the XACML system update account information--surely that >> >> >> >> happens >> >> >> outside of the XACML system. Each time a request is received, it >> >> evaluates with new values for withdrawal amount and frequency. Why >> >> shouldn't the same design principle apply to a BTG attribute? >> >> >> >> I raised this and other concerns in my note of 22 February 2011: >> >> http://lists.oasis-open.org/archives/xacml/201102/msg00037.html. >> >> >> >> Regards, >> >> --Paul >> >> >> >> -----Original Message----- >> >> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] >> >> Sent: Tuesday, March 15, 2011 15:10 >> >> To: Davis, John M. >> >> Cc:xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> >> >> Subject: Re: [xacml] BTG comment >> >> >> >> <<<first 2 examples omitted - pht>>> >> >> >> >> All you need is the >> >> >> >> value of the current attribute for retry count. No change of state. >> >> However, if you link this to a system change that says the user must >> >> >> >> now >> >> >> >> authenticate by providing "Mothers maiden name" and other personally >> >> known information, then the policy state has changed from "Normal >> >> authentication used" to "Alternate authentication used". In other >> >> >> >> words >> >> >> >> access policies may change under alternate (can only reset >> >> >> >> password). >> >> >> 3*. BTG*. Here we require the system to go from a "Normal" access to >> >> >> >> a >> >> >> new rule set "BTG" which would have new expectations of system >> >> >> >> Again we can have a fixed policy with the following condition >> >> >> >> attached >> >> >> to a rule >> >> >> >> If BTG = True then grant access >> >> >> >> We can have the following fixed rules as well >> >> >> >> If Action=BTG and .... then grant with obligation set BTG to True in >> >> StateDB. >> >> >> >> If Action=ResetBTG and .... then grant with obligation set BTG to >> >> >> >> False >> >> >> in StateDB >> >> >> >> regards >> >> >> >> david >> >> >> >> >> >> >> >> performance caused by changing the policy set referenced by the PAP. >> >> >> >> For >> >> >> >> example, the rule set for patient privacy might be much different >> >> >> >> for >> >> >> normal "treatment" than for "emergency" where imminent harm or death >> >> >> >> was >> >> >> >> involved. >> >> >> >> Regards, Mike Davis, CISSP >> >> Department of Veterans Affairs >> >> Office of Health Information >> >> Security Architect >> >> 760-632-0294 >> >> >> >> >> >> -----Original Message----- >> >> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] >> >> Sent: Monday, March 14, 2011 10:20 AM >> >> To:xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> >> >> Subject: Re: [xacml] BTG comment >> >> >> >> Hal, Erik >> >> >> >> is some sort of consensus arising that we need an entity in the >> >> >> >> XACML >> >> >> model (call it a StateDB for now) that holds the state of the system >> >> >> >> in >> >> >> >> the form of one or more attributes, whose values can be changed. >> >> >> >> When >> >> >> an >> >> >> >> attribute value changes this represents a state change of the >> >> >> >> system. >> >> >> The PDP is and remains stateless. >> >> >> >> The request context carries the current state of the system to the >> >> >> >> PDP. >> >> >> >> A component of the XACML system (might be a PIP, or it might be >> >> something new) picks up the current state of the system from the >> >> >> >> StateDB >> >> >> >> and inserts these attributes into the request context for passing to >> >> >> >> the >> >> >> >> PDP. >> >> >> >> When certain authz decision requests are granted (or denied) this >> >> >> >> might >> >> >> >> cause a change in the state of the system. A new component is needed >> >> which updates the StateDB when this occurs. >> >> >> >> This type of state based system is more generic than BTG, and can >> >> incorporate BTG as one of its use cases. You can for example use >> >> >> >> this >> >> >> type of state based system to >> >> - support withdrawals from a credit card machine up to a daily >> >> >> >> limit, >> >> >> - block a user's account after 3 concurrent denies, >> >> - implement BTG by setting the glass to broken when a user is >> >> >> >> granted >> >> >> permission to break the glass >> >> >> >> Does this also answer Mike's suggestion that BTG is an example of >> >> something more generic? >> >> >> >> regards >> >> >> >> David >> >> >> >> >> >> On 24/02/2011 17:48, Erik Rissanen wrote: >> >> >> >> Hal, >> >> >> >> Yes, I agree that a special entity with the explicit purpose of >> >> maintaining authorization state would be something good to add. >> >> >> >> It's >> >> >> not unusual for real world access control needs to depend on >> >> >> >> state, >> >> >> which may be itself affected by an access decision. XACML should >> >> support this, but not in the PDP itself. >> >> >> >> Erik >> >> >> >> >> >> On 02/24/2011 06:04 PM, Hal Lockhart wrote: >> >> >> >> When we say that the PDP is stateless, what is meant is that no >> >> >> >> state >> >> >> >> is carried by the server from one decision to the next. Policy >> >> decisions are purely a function of policies in force and the >> >> >> >> content >> >> >> >> of the request context. >> >> I agree with the general view that this is a valuable property >> >> >> >> which >> >> >> >> not should be lightly changed across the board. However, I am >> >> >> >> keeping >> >> >> >> an open mind on the desirability of explicitly defining entities >> >> within the access control architecture which do maintain state. >> >> For example, the RBAC profile as it currently exists implies some >> >> kind of stateful mechanism to keep track which dynamic roles have >> >> been enabled. The exact mechanism was deliberately not specified >> >> >> >> as >> >> >> it was recognized that many designs were possible. >> >> Hal >> >> >> >> -----Original Message----- >> >> *From:* Rich.Levinson >> >> *Sent:* Wednesday, February 23, 2011 11:57 AM >> >> *To:* Davis, John M. >> >> *Cc:*erik@axiomatics.com <mailto:erik@axiomatics.com>;xacml@lists.oasis-open.org <mailto:xacml@lists.oasis-open.org> >> >> *Subject:* Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda >> >> 10 February 2011 TC Meeting] >> >> >> >> Hi Mike, Erik, Paul, and David, >> >> >> >> Here's my two cents on what I've taken from the emails on this >> >> thread, David's BTG profile and protocol description. >> >> >> >> I agree w Erik's statement that the XACML model does not have >> >> state built in, and that there is not yet a compelling reason to >> >> add it. >> >> >> >> However, my interpretation of "state" is wrt the Policy >> >> >> >> definitions. >> >> >> >> i.e. the Policy defns themselves are "static". >> >> >> >> However, for "Policy evaluation", the "state" is the >> >> >> >> RequestContext, >> >> >> >> namely whatever values are in the Attributes in the RequestContext >> >> at Policy evaluation time may be regarded as the "state". >> >> >> >> So, for "BTG", what I see as the essential ingredient is the defn >> >> >> >> of >> >> >> >> a BTG-State Attribute, that can be supplied by the PEP, or some >> >> PIP that supplies it to an attribute finder during policy >> >> >> >> evaluation. >> >> >> >> Testing the attribute would be triggered by its presence in a >> >> >> >> Policy >> >> >> >> with it MustBePresent xml attribute set to true, and the Policy >> >> should be defined, so that the BTG-State Attribute is not tested >> >> unless the request is not permitted without it. >> >> >> >> This is equivalent to what we did in the RSA-2008 Interop, where >> >> the "BTG-State" attribute was "hl7:pea-001", which would allow an >> >> external user access, where they would otherwise be denied. >> >> i.e. the presence of hl7:pea-001 effectively changed the "state" >> >> of Policy evaluation, which enabled BTG logic to be applied. >> >> >> >> With respect to David's documents, I basically agree with the >> >> approach, except for statements like in the protocol descr step 8, >> >> where it says: "The PDP sets the relevant BTG-state variable >> >> to true ...". >> >> >> >> I think it is fine to return an Obligation as the Profile >> >> >> >> describes, >> >> >> >> and that this be used as the basis of the User obtaining a >> >> "BTG-State" Attribute, which can be submitted in the >> >> follow-up request. I think the presence of this attribute >> >> is sufficient "state" for the Policy to evaluate properly. >> >> >> >> Thanks, >> >> Rich >> >> >> >> >> >> Davis, John M. wrote: >> >> >> >> I still think BTG is a subset of a more general use case. >> >> >> >> Following along with the obligation, my impression was that this >> >> >> >> must be followed with an ageement to abide by the obligation >> >> constraints, e.g. a "promise". The promise could act to tell the PDP >> >> >> >> to >> >> >> >> change the policy set (in this case to BTG). With the "state" change >> >> >> >> the >> >> >> >> decision is now correct. >> >> >> >> Mike Davis >> >> >> >> ----- Original Message ----- >> >> From: Erik Rissanen<erik@axiomatics.com> <mailto:erik@axiomatics.com> >> >> To:xacml@lists.oasis-open.org <mailto:To:xacml@lists.oasis-open.org><xacml@lists.oasis-open.org> <mailto:xacml@lists.oasis-open.org> >> >> Sent: Wed Feb 23 04:42:41 2011 >> >> Subject: Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda >> >> 10 February 2011 TC Meeting] >> >> >> >> Hi Paul and Mike, >> >> >> >> I agree, but isn't this exactly what David is proposing? That is >> >> >> >> how I >> >> >> >> understand it, at least for the "PEP state" mode. The other >> >> >> >> alternative >> >> >> >> with the PDP maintaining state is something I don't think is a >> >> >> >> good >> >> >> >> idea. >> >> >> >> To make David's proposal better, it needs: >> >> >> >> - Drop the PDP state approach since this goes against the >> >> >> >> capability of >> >> >> >> the XACML model which does not have a state built in. >> >> >> >> - Define identifiers for at least the BTG obligation/advice >> >> >> >> (advice is >> >> >> >> better, but for XACML 2.0 an obligation needs to be used), the >> >> >> >> action-id >> >> >> >> for breaking glass (as well as giving some kind of direction of >> >> >> >> what the >> >> >> >> BTG request should look like in relation to resources being >> >> >> >> accessed). >> >> >> >> - It would be nice with a full, worked through example. >> >> >> >> Best regards, >> >> Erik >> >> >> >> On 2011-02-23 05:06,Davis, John M. wrote: >> >> >> >> >> >> Concur with Paul's analysis. We also see BTG as a state change. >> >> >> >> Regards, Mike Davis, CISSP >> >> Department of Veterans Affairs >> >> Office of Health Information >> >> Security Architect >> >> 760-632-0294 >> >> >> >> -----Original Message----- >> >> From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] >> >> Sent: Tuesday, February 22, 2011 7:48 AM >> >> To: DavidChadwick;xacml@lists.oasis-open.org <mailto:Chadwick;xacml@lists.oasis-open.org> >> >> Subject: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10 >> >> >> >> February >> >> >> >> 2011 TC Meeting] >> >> >> >> I have some reservations about David's BTG proposal, primarily >> >> >> >> because >> >> >> >> the semantics are not well specified, and because it muddies the >> >> distinction between what should happen within the XACML system, >> >> >> >> and >> >> >> >> what >> >> >> >> should happen outside of XACML. >> >> >> >> Obligations, as currently defined, require the PEP to take some >> >> >> >> action >> >> >> >> prior to executing or acting on the PDP's decision for a >> >> >> >> particular >> >> >> >> request. The proposed BTG obligation is entirely different: it >> >> >> >> says >> >> >> >> "you can't have access, but you can break the glass if you >> >> >> >> choose". We >> >> >> >> added Advice in XACML 3 to accommodate this sort of >> >> message-passing--messages which may or may not have anything to >> >> >> >> do with >> >> >> >> the original request or the decision. I don't think the TC >> >> >> >> should >> >> >> encourage the use of Obligations for anything other than what >> >> >> >> they are: >> >> >> >> an obligation to discharge certain actions regarding the PDP's >> >> >> >> decision. >> >> >> >> This is the only way to assure predictable system behavior--or >> >> >> >> to >> >> >> detect >> >> >> >> a faulty system. >> >> >> >> As we discussed on the last call, the scope and definition of >> >> >> >> "glass" >> >> >> >> should be specified. If not, we are just standardizing some >> >> >> >> features of >> >> >> >> the request/response protocol without knowing what effect these >> >> >> >> features >> >> >> >> have, either on the PDP or the PEP. Does the glass cover a >> >> >> >> specific >> >> >> >> request, a specific class of subjects, a class of resources, or >> >> >> >> what? >> >> >> >> Or is glass-condition just another attribute in the request >> >> >> >> context, >> >> >> >> whose effective meaning is given by the policy rules? >> >> >> >> However you define glass-condition, it will have to be >> >> >> >> implemented as a >> >> >> >> XACML attribute in the request context, or as some extra-xacml >> >> functionality. Either way, you are now using the XACML request >> >> mechanism to change the policy evaluation state directly. While >> >> >> >> this >> >> >> >> isn't prohibited by the standard, it makes it harder to reason >> >> >> >> about the >> >> >> >> behavior of the system. >> >> >> >> David's "BreakTheGlass" action-id is egregious in that it is not >> >> >> >> just a >> >> >> >> request for permission to do something (outside the XACML >> >> >> >> system)--it is >> >> >> >> a directive to change the state of the policy evaluation with >> >> >> >> regard to >> >> >> >> a particular (non-XACML) resource, subject, or action. Now, if >> >> >> >> state is >> >> >> >> maintained in PEP, you could say this is a normal request, but >> >> nevertheless it has muddied the distinction between requests for >> >> permission to do something (outside of XACML) and directives to >> >> >> >> do >> >> >> >> something "inside" of XACML. >> >> >> >> I would favor one of two alternative approaches (or some >> >> >> >> combination): >> >> >> >> 1. Simply return an Obligation (along with a Permit decision) if >> >> >> >> the >> >> >> >> requestor is authorized to "break the glass". The PEP would be >> >> >> >> obliged >> >> >> >> to display the list of consequences associated with accessing >> >> >> >> the >> >> >> resource, and the user could choose to accept the consequences >> >> >> >> and see >> >> >> >> the resource, or cancel the request. The consequences could >> >> >> >> include >> >> >> >> changing the state of the system to allow access to other >> >> >> >> resources, or >> >> >> >> allow other people to see the same resource, or whatever the >> >> >> >> business >> >> >> >> meaning of "break the glass" carries in a specific application. >> >> >> >> The >> >> >> >> obligations would be discharged outside the XACML system. (I'm >> >> >> >> not sure >> >> >> >> that this approach really warrants a standard profile, unless we >> >> >> >> just >> >> >> >> want to provide a distinguished obligation id value for BTG.) >> >> >> >> 2. Write policies specifically to allow "break-the-glass" >> >> >> >> actions >> >> >> to >> >> >> >> certain subjects in certain conditions. The PEP would request >> >> permission to break the glass, and if allowed would use some >> >> >> >> non-XACML >> >> >> >> mechanism to change the policy evaluation state. Obligations >> >> >> >> could be >> >> >> >> returned with the decision to advise user of the consequences. >> >> >> >> Then the >> >> >> >> application would request access to the desired resource. (Again >> >> >> >> I >> >> >> >> question whether this is worthy of standardization, unless we >> >> >> >> want to >> >> >> >> name a distinguished "break-the-glass" action id.) >> >> >> >> Either of these approaches would meet the BTG use case without >> >> >> >> altering >> >> >> >> the semantics or conventional usage of XACML. >> >> >> >> Regards, >> >> --Paul >> >> >> >> >> >> >> >> -----Original Message----- >> >> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] >> >> Sent: Thursday, February 10, 2011 05:22 >> >> To:xacml@lists.oasis-open.org <mailto:To:xacml@lists.oasis-open.org> >> >> Subject: Re: [xacml] Proposed Agenda 10 February 2011 TC >> >> Meeting >> >> >> >> Dear All, >> >> >> >> in preparation for this evening's call, I attach a revised >> >> >> >> version of >> >> >> >> the BTG profile for you consideration >> >> >> >> regards >> >> >> >> David >> >> >> >> >> >> >> >> <snip> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> 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 >> >> >> >> >> >> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> >> >> 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.p >> >> >> >> hp >> >> >> >> >> >> >> >> -- >> >> >> >> ***************************************************************** >> >> David W. Chadwick, BSc PhD >> >> Professor ofInformation Systems Security School of Computing, >> >> University ofKent,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.Chadwick@kent.ac.uk <mailto:D.W.Chadwick@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 >> >> >> >> >> --------------------------------------------------------------------- >> >> 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 >> >> >> --------------------------------------------------------------------- >> 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.Chadwick@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 *****************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]