[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Open issue 66
I should add that pausing the PDP makes it stateful, which is a bad thing. So perhaps Rich's proposal to submit a whole new XACML request after the missing attribute is better. Regards, Erik Erik Rissanen wrote: > Hi Rich, > > Thanks, I think I am starting to understand what you want here. And I > agree with you on much of what "fine grained" authorization is about. > > However, what you want to do is not done well with the Request/Response > schema. What you are talking really is the context handler. The context > handler and the PIP are abstractions, and there is nothing in the > standard or architecture which prevents the application metadata > repository to act as a PIP. > > So what you really are looking for is a standard callback mechanism with > which the context handler can request additional attributes. > > I would propose that if we pursue that work, then we define or find > existing schema for two things: > > 1. Attribute request/response. I think SAML already defines these. > > 2. Add the attribute request/response in the XACML SAML profile > authzquery protocol units. > > So, what about this sequence?: > > 1. The PEP generates a request with the "most used" attributes. > > 2. The PEP wraps the XACML request in a XACML SAML profile authz query. > > 3. The PDP receives the request and starts processing the policies on it. > > 4. The PDP reaches a part of the policy where it encounters an attribute > which is not present in the request. > > 5. The context handler discovers this and generates an attribute request. > > 6. The PDP pauses evaluation and returns a XACML SAML profile response > which asks for more attributes (this is not defined in the current > specification). > > 7. The PEP gets the attribute from the metadata repository (or where ever) > > 8. The PEP sends an attribute query resopnse to the PDP > > 9. The PDP resumes. > > There are problems with this. Most attributes which are "missing" are > genuinely missing, so there would be a lot of interupting and > restarting, and this would not be useful unless there is a configuration > somewhere in the context handler on which attributes are meaningful to > ask for. > > Also, I am not sure if it is right to make the attribute > request/response on the same path as the XACML request/response, but > there is one benefit of doing so, namely that we don't need to define > how to reference attribute callback endpoints. > > I need to go now, but I will think more about this. > > Regards, > Erik > > > Rich.Levinson wrote: > >> Hi Erik, >> >> Answers inline: >> >> Erik Rissanen wrote: >> >>> Hi Rich, >>> >>> Yes, to respond to this specific "part 1" only, it is true that in >>> this particular example it works very well. The policy is simple >>> enough that there is a single attribute which can be returned by the >>> PDP. If the PEP would provide the missing attribute, then the >>> response would be a Permit. >>> >>> (BTW, if you prefer to discuss resource attributes, that is good with >>> me. I agree that they are perhaps more interesting since they might >>> be more difficult to handle in practice.) >>> >>> If I continue beyond "Part 1" into the discussion which you follow up >>> with. >>> >>> 1. For the sake of argument, let's assume that the PDP can return one >>> or more attributes as "missing". >>> >>> 2. Then let's assume that, as you say, the policy author puts an >>> attribute in the policy, and the PEP has not provided the attribute >>> to the PDP. Let's say that the attribute has id >>> "http://www.tts-esss.com/pieka/UUUU/3";. >>> >>> 3. The PEP will get a response saying that attribute >>> http://www.tts-esss.com/pieka/UUUU/3 is missing. >>> >>> So your question is what should the PEP do? (If I understand you >>> correctly) >>> >> That's not really my question. As was already discussed above and in >> my prev email, it appears we agree that 7.15.3 says what a PEP can do: >> either ignore it and just reject the request, >> or if it can get the attr, get it, and resubmit the request. >> PEP does not "have to do" either of these in particular, but >> also "can do" either it chooses. Possibly there is some 3rd >> or other choice, but I don't think we need to go there. >> >>> It is quite clear to me that if the PEP does not know about this >>> attribute in some form, either directly by itself, or it can look it >>> up in some kind of discovery service, then there is nothing it can >>> do. One cannot expect systems integration to happen by itself. One >>> cannot expect that a policy author can fill in any attribute in a >>> policy and then it would work all by itself. >>> >> Right, if PEP does not know what to do, then it should just >> reject the request. >> >>> So my question then is, what do you think should happen in this >>> stage? Are you looking for a form of general purpose attribute >>> discovery service? That might be an interesting thing to work on. >>> >> Yes, I am looking for at least "a form of" somewhat general purpose >> attribute >> gathering or collecting, but not "discovery" in the sense of blindly >> going and trying >> to find things somewhere. >> The "form" which I mentioned in the last sentence of the original issue >> "mechanisms such as vocabularies should be recommended usage here >> with the PEP being responsible for mapping the vocabulary item to the >> particular resource physical access path such as the xpath." >> was a suggestion for xml type resources, such as the xml patient record >> shown in the core spec. >> Let me preface this by saying that this whole "fine grain >> authorization" appears >> to me to be a general attempt to abstract security logic out of >> applications >> and into common policy stores and engines. I mean that is the sort of >> thing >> I "hear" a lot and I assume that is a significant part of what this >> whole effort >> is all about. >> That being said, the actual act of extracting authorization logic out >> of appls >> means that some of the tests that they currently do on internal >> variables to >> come to decisions needs to be removed from the code and made available >> to be placed in policies that do similar types of tests to come to >> decisions, >> but these tests are conducted under the control of the IT Security >> organization >> in some central location with an admin console, etc. >> So, and I think this is obvious, but maybe, in general people aren't >> thinking >> about it enough for it to be obvious, the logic that appl executed and >> the >> attribute values it used in that eval now must be in the policy >> engine. It is >> easy to see how the logic can be put there with all the xacml constructs >> we have available, but the question remains how do the attribute "values" >> get into the policy evaluation. >> Again, the answer to this appears fairly obvious to me. In the process of >> removing the authorization code from the appl, the devs will notice which >> values from the internal resource representation are used by that logic. >> Therefore, they must know that when the logic is put somewhere else, >> it will need these values to do the evaluation. Therefore, one fairly >> simple >> solution is that the dev identify those object properties, if you >> will, in a >> global sense that can be extracted to a meta-data file, a fairly common >> type thing done these days. Maybe it is done w annotations. >> Now when the dev replaces the az logic with a simple call for az, >> this is where the details need to emerge. (I think the OASIS SCA-* >> activities involve quite a bit of abstraction of previously internal >> application-based logic into general container framework services >> and suspect that this activity I am describing fits fairly naturally >> in that sense, except in this case the container service we are >> looking at would be the pep-pdp service path.) >> First, I would expect that security admins responsible for creating >> policies >> and such would have the list of attrs that are available for such use >> from >> the metadata and doc provided by the appl vendors in the case of >> appls that are sold for use by many customers. The vendors should >> have a good sense of what attrs might be needed for policies. For >> example in the health record case in the core spec, at least all the >> attrs currently used in the policies and maybe more depending on >> on the nature of the records. >> Generally, it would not make sense to send all the possible attrs on >> every call, so, when a call is made and a policy evaluated, the list >> of missing attrs can be returned, and then the appl az api would >> somehow or other get the attrs from the object that it has locally >> in context. The example I gave was an xml doc, where to get >> the attrs the api might need xpaths and an attr-id. Then the appl >> devs could change the formats of the xml docs on their next >> release and their metadata would have new xpaths but the >> variable id would remain the same. >> >>> Maybe I don't understand the use case really. But as far as I see it >>> right now, it's not going to work because: >>> >>> 1. In general it is not possible to tell which attribute is missing. >>> >>> 2. Even if it is possible to tell which attribute is missing, one >>> cannot expect a PEP find the missing attribute by itself if it >>> doesn't already know about it. >>> >>> There just is no way around the fact that if an attribute appears in >>> a policy, then either the PEP or the context handler has to be aware >>> of the attribute in some form, or it won't work. The expected >>> requests from the PEP and the context handler configuration form a >>> contract which defines the vocabulary available to policy authors. >>> >> Previous text should answer these points. >> >>> But maybe you are talking about lazy fetching of attributes? I do >>> think that there is much value in lazy fetching of attributes. Let's >>> say that the http://www.tts-esss.com/pieka/UUUU/3 attribute is >>> available in some external source and the PEP or context handler is >>> aware of it, but the attribute is not needed every time and it is >>> expensive to retrieve. In this case it may be desirable to set up the >>> system so that the attribute is retrieved only when it is needed by >>> the policies. >>> >> No, again, see above. >> The point about the context handler, though, is that in the core spec the >> context handler is kind of a pdp-local entity which access attrs from a >> pip. What I am describing above is getting attrs from an instantiated >> business object in an application context. While such data could be >> created and made available in an auxiliary pip, this seems like in >> general >> an unnecessary exercise when the info is already right there in the appl >> from which the original request was made. >> >>> This use case is supported by the context handler abstraction. The >>> context handler is something which can be used by the PDP to retrieve >>> attributes when they are needed on a particular evaluation path, so >>> that early fetching is avoided. But "missing attributes" to the PEP >>> is not going to work. >>> >>> Anyway, I have a feeling that I don't understand what you are looking >>> for, so I welcome more discussion. :-) >>> >> Ok, I provided "more discussion" above. I am interested in your reaction >> and what, if any, alternative approaches might be better. My sense is >> that >> the approach I described is fairly "obvious" and I think if we look at >> activities in the WS-SecurityPolicy arena there is all kinds of >> information >> being solicited for use in authentication and authorization. WS-Fed is >> incorporating provisions for "claims", which afaict are simply attrs w >> the >> rubber stamp of an STS on them, or at least on the wire not a lot more >> complicated than that. >> >> Thanks, >> Rich >> >>> Best regards, >>> Erik >>> >>> Rich.Levinson wrote: >>> >>>> Hi Erik, >>>> >>>> I don't think your comments are addressing the specifics that were >>>> raised in the issue, which I am copying below for quick reference. >>>> >>>> To summarize the issue: >>>> >>>> Part 1. is basically saying that we need some context about the >>>> example >>>> in order to look at the details in a consistent manner. >>>> Basically, my reading >>>> of the example is that when rule 1 is evaluated, the Target >>>> determines that >>>> the Rule is applicable, and presumably the Rule is evaluated and >>>> it should >>>> produce an Indeterminate result because there is no Subject >>>> "patient-number" >>>> as required on line 1134 when the Condition is evaluated. >>>> >>>> Based on this Rule I expect that the Indeterminate result causes >>>> us to >>>> look at the prescribed processing in section 7.15.3, which says >>>> that >>>> a missing-attribute status code could/should be returned. >>>> >>>> To me, this provides an excellent example of how a PEP is informed >>>> of what attribute needs to be supplied. >>>> >>>> Before I go further into the details, I'd like to get your response >>>> to that. >>>> >>>> Also, I'd like to note that while I realize that this issue has been >>>> floating >>>> there for a long time, one reason is that no one has really wanted to >>>> discuss it in detail. Prior responses were more of the nature of there >>>> will be some other mechanism for getting the attribute. In general, >>>> when >>>> we are considering attributes that need to come from users or from >>>> resource attributes, I believe there is a non-trivial issue about how >>>> those attributes get brought into the picture. The first problem is >>>> knowing that they are needed. The fact that they are needed is >>>> driven by the existence of an applicable policy that needs it, which >>>> clearly is a state that can come and go as an administrator adds or >>>> removes a particular attribute from the policy. >>>> >>>> So, the basic use case here is: an admin creates or changes a policy >>>> and decides to add an attr as part of the policy eval. Given this >>>> change, how does this attr become part of the request. >>>> >>>> (Note: I'd actually prefer to focus on resource attrs rather than >>>> subject attrs, but since this particular situation w Rule 1 >>>> appeared obvious to me as a typical example, it happened >>>> that the missing attr was subject-based (there is also an >>>> assoc resource attr, but the req mysteriously already had >>>> supplied that one) >>>> >>>> My reading of the spec is that 7.15.3 provides a general purpose >>>> mechanism for accomplishing this by returning an identifier specifying >>>> what attr is needed, based on which the PEP and appl can do >>>> whatever they want to get the attr then resubmit the request with >>>> the attribute included. >>>> >>>> This seems to me to be pretty essential functionality. Let me know >>>> if you think I am missing some important point here. I will be happy >>>> to help "fix" the spec w the detail I think is needed, but before we >>>> get to that point there needs to be some agreement that changes >>>> are even appropriate. >>>> >>>> Thanks, >>>> Rich >>>> >>>> >>>> >>>> >>>> >>>> 66. Missing attributes may be underspecified >>>> >>>> I did a somewhat detailed analysis of "Example two" in the core spec >>>> from the point of view of understanding how fine grained >>>> authorization (fga) (applying resource attrs to az decision) was >>>> implemented and came across a number of items that I think need to >>>> be addressed especially in potential interoperability situations. I >>>> will put all in one issue initially, we can decide if it needs to be >>>> broken out later. >>>> >>>> 1. line 1090-91 describing ResourceContent </xacml/ResourceContent>. >>>> In both the core spec and the sample messages, the ResourceContent >>>> </xacml/ResourceContent> contains the following: >>>> >>>> * >>>> >>>> <ResourceContent </xacml/ResourceContent>> >>>> >>>> o >>>> >>>> <md:record xmlns:md="urn:med:example:schemas:record" >>>> >>>> + xsi:schemaLocation="urn:med:example:schemas:record >>>> >>>> http:www.med.example.com/schemas/record.xsd"> >>>> <http:www.med.example.com/schemas/record.xsd%22%3E> >>>> >>>> + >>>> >>>> <md:patient> >>>> >>>> # >>>> >>>> <md:patientDoB>1992-03-21</md:patientDoB> >>>> <md:patient-number>555555</md:patient-number> >>>> >>>> </md:patient> >>>> >>>> </md:record> >>>> >>>> </ResourceContent </xacml/IssuesList/ResourceContent>> >>>> <Attribute AttributeId >>>> >>>> </xacml/AttributeId>="urn:oasis:names:tc:xacml:1.0:resource:resource-id" >>>> >>>> DataType </xacml/DataType>="xs:string"> >>>> >>>> o >>>> >>>> <AttributeValue </xacml/AttributeValue>> >>>> >>>> + //med.example.com/records/bart-simpson.xml# >>>> >>>> xmlns(md=http:www.med.example.com/schemas/record.xsd) >>>> xpointer(/md:record/md:patient/md:patientDoB) >>>> >>>> </AttributeValue </xacml/IssuesList/AttributeValue>> >>>> >>>> </Attribute> >>>> >>>> While I recognize that the example itself is not intended to be >>>> perfect, it provides a convenient context for raising the following >>>> questions/issues, especially wrt fga. >>>> >>>> 1. If this is a first request from a PEP, why is the PEP supplying >>>> patient-number on line 1056? This looks like a required attr to >>>> evaluate Rule 1 (line 1141), if the requestor is the patient, >>>> but this example the requestor is the physician. >>>> * The physician-id is supplied in the request (line 1044), >>>> but the only rule it appears in is rule 3 (line 1522). >>>> This rule only allows "write" access (line 1507), so I >>>> expect this request would probably fail as it is currently >>>> set up. i.e. we would need to add a "read" action to rule >>>> 3 or add a physician-id test to rule 1. >>>> b. Assuming the above request fails, let's consider what might >>>> be done. There was a "read" request issued (line 1072), so that >>>> would mean that rule 1 (line 1182), rule 2 (line 1347), or rule >>>> 4 (line 1668) could be applied. >>>> >>>> Rule 1 requires a Subject attribute patient-number (line 1134) to >>>> match the patient-number in the requested resource record (line >>>> 1141). Presumably a <MissingAttributeDetail >>>> </xacml/MissingAttributeDetail>> could be returned, somehow >>>> identifying these 2 attributes to the PEP. >>>> >>>> Rule 2 requires a patientDoB resource attr (line 1297), a >>>> parent-guardian-id subject attr (line 1363), and a parentGuardianId >>>> resource attr (line 1371). Similarly a <MissingAttributeDetail >>>> </xacml/MissingAttributeDetail>> could be returned requesting these. >>>> >>>> * Assuming this to be the case, one question I have is how does the >>>> >>>> <MissingAttributesDetail </xacml/MissingAttributesDetail>> tell >>>> the PEP whether the attributes that are missing should be >>>> resubmitted as part of the Subject or as part of the Resource? >>>> This info is provided in the Request from the xml structure, >>>> however, the <MissingAttributeDetail >>>> </xacml/MissingAttributeDetail>> does not have equivalent >>>> structure to make such distinctions. >>>> >>>> The above is intended just to give an example of questions that >>>> occur for this particular example, but it is my opinion that it is >>>> symptomatic of a general problem of how PEPs are supposed to know >>>> how to construct the proper RequestContext </xacml/RequestContext> >>>> necessary, in general, for complex scenarios that require >>>> substantive fga attrs. >>>> >>>> In these more complex fga scenarios it is likely that >>>> <MissingAttributeDetail </xacml/MissingAttributeDetail>> will be >>>> typically needed to collect all the required attributes. Therefore, >>>> I believe some more robust mechanisms, possibly using >>>> MissingAttributeDetail </xacml/MissingAttributeDetail> as a good >>>> starting point will be needed to adequately define operation in this >>>> area. >>>> >>>> In this context as well, it is likely that xpaths are probably not >>>> the way to go since they are only applicable to certain types of >>>> resources (xml-based) and those resource structures are likely to >>>> change in time, and these changes should not percolate into the >>>> enterprise Policy arena. Therefore, mechanisms such as vocabularies >>>> should be recommended usage here with the PEP being responsible for >>>> mapping the vocabulary item to the particular resource physical >>>> access path such as the xpath. >>>> >>>> Status: *OPEN* >>>> >>>> CHAMPION: *Rich* >>>> >>>> >>>> >>>> Erik Rissanen wrote: >>>> >>>>> All, >>>>> >>>>> I propose that issue 66, "Missing attributes may be >>>>> underspecified", to be closed without action. The issue has been up >>>>> there a long time with no proposals for a solution. In addition to >>>>> that, I believe it is technically impossible to provide a solution. >>>>> The reason someone gets a not-applicable from the PEP is because >>>>> "there is no policy which applies". In general there is no way to >>>>> describe in the form of "missing attributes" what the PEP needs to >>>>> provide for the policy to apply. Policies can be much too complex >>>>> for this. In particular, a policy could be NotApplicable because an >>>>> attribute is present, for example. Or it might require that three >>>>> particular integer attributes form a pythagorean tripple. How do >>>>> you express that as "missing attributes"?! >>>>> >>>>> And we demonstrated in the RSA interop that obligations can be used >>>>> to handle simple use cases where some attributes can be expected to >>>>> be missing. An obligation can be used to mark the part of the >>>>> policy which required an attribute, and the obligation can then be >>>>> returned by the PDP if the attribute is missing. >>>>> >>>>> Best regards, >>>>> Erik >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]