OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Open issue 66


Hi Erik,

Quick responses inline:

Erik Rissanen wrote:
> The next questions I then have are:
>
> 1. What specifically do you mean with "missing attributes may be 
> underspecified"? Do you mean that the spec currently does not specify 
> exactly under what conditions the missing attributes must be part of 
> the response to the PEP? Note that typically a PDP will have lots of 
> rules and policies about all kinds of resources and users, and most of 
> them will not apply to any particular request. In many cases the PDP 
> would tell that something does not apply by the fact that attributes 
> in those rules/polices are not present in the request, and therefore 
> they rules/policies do not match. So there is no easy way to tell that 
> an attribute really is "missing" compared to that the request simply 
> does not apply.
Yes, precisely need guidelines as to what is "appropriate". Ex. would not
require for determining applicability, but if applicable, then if needed,
should provide all for at least the current Policy being evaluated.

Also, as indicated in issue need to break out Subject vs Resource which
currently is lost.
>
> 2. When do you think this is useful? It appears to me that 
> re-submitting requests may be expensive. So whether this is meaningful 
> would depend on the relative expenses of submitting a request to the 
> PDP vs retrieving attributes before the request is submitted to the PDP.
It is especially useful when attr change in a Policy, where what used
to be good enough no longer is. I would hope that caching would reduce
overhead, such that if subsequent requests are made from same context
then the list of attrs to provide would be ratcheted up each time a new
MissingAttr is identified. That way this might only occur once for any
particular resource type.
>
> 3. Why should this be part of the PEP/PDP communication, rather than 
> the context handler configuration of the PDP?
It is "in addition to", not "instead of". I assume that the current callback
to CH will occur, and if still unsuccessful, then do MissingAttributes.

    Thanks,
    Rich
>
> I still think that all this will be very hard to achieve 
> "automatically" in the XACML Request/Response eschange. It would 
> require some kind of configuration. The only "automatic" approach I 
> can think of is the MustBePresent XML attribute. Is that all you are 
> looking for?
>
> Best regards,
> Erik
>
> Rich.Levinson wrote:
>>
>>
>> Hi Erik,
>>
>> I agree: stateful is probably a bad idea. One thing I like about the 
>> existing
>> mechanism is that it is not stateful and makes no assumption that a new
>> request will be submitted. Basically, the PEP gets a fresh start and
>> depending on what attrs are missing and what attrs are "configured"
>> to be readily available, it should be able to easily decide whether
>> it can easily gather the missing attrs and re-submit. Also, I think this
>> should be envisioned as happening within the context of the api, which
>> would include the appl context, which it will need to get the data.
>> Presumably there will be a container service az api client that appls
>> can use. This az api client would act as PEP and gather any appl
>> attrs and submit 2nd request transparent to appl.
>>
>> This is kind of what we modeled in the Interop w Duane's module
>> gathering attrs beneath the surface from the appl perspective. Although
>> in the Interop we didn't do missing attrs, we just had the api go get
>> what it knew would be needed.
>>
>>    Thanks,
>>    Rich
>>
>>
>> -------- Original Message --------
>> Subject:     Re: [xacml] Open issue 66
>> Date:     Thu, 11 Sep 2008 06:49:32 +0200
>> From:     Erik Rissanen <erik@axiomatics.com>
>> To:     Rich.Levinson <rich.levinson@oracle.com>
>> CC:     XACML TC <xacml@lists.oasis-open.org>
>> References:     <48C76772.3060402@axiomatics.com> 
>> <48C7F34B.2040605@oracle.com> <48C80A23.6050900@axiomatics.com> 
>> <48C83DC8.1070706@oracle.com> <48C8A147.8050303@axiomatics.com>
>>
>>
>>
>> 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]