OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Re: Call for Obligations

    Posted 04-16-2007 04:05
    Sampo,
      I think by now I have given up on the idea of obligations being 
    optional. :) This is mainly due to added education from the others on 
    the TC.
    
    Are we looking at at least standardizing some of the obligations like 
    logging?
    Looking at http://wiki.oasis-open.org/xacml/DiscussionOnObligations, I 
    am guessing Yes!
    
    Regards,
    Anil
    
    sampo@symlabs.com wrote:
    > Anil Saldhana writes:
    >> My use cases in mind are the following(please correct me wherever my 
    >> understanding is wrong):
    >> a) Legitimate authorization request arrives at the PEP. PEP invokes 
    >> the PDP. PDP comes back with 'PERMIT' and a set of obligations. PEP 
    >> is unable to fulfill 1 or more obligations. PEP issues an error. What 
    >> happened to the legitimate request?
    >
    > I understand you mean the authorization request was legit from global
    > perspective, assuming all information was available, but might seem
    > illegit when viwed locally, perhaps with some of the context or 
    > information
    > inaccessible.
    > The conflict between PDP imposing Obligations that PEP can not
    > satisfy vs. PDP having "intelligently" chosen the alternate
    > Obligations that it "knows" PEP can satisfy is the key. At local
    > level any request that does not come with enough context or information
    > to satisfy Obligations MUST be considered illegit. If such request,
    > from global perspective should have been considered legit, then
    > we need to see if there was architectural or layering reason why
    > the PEP and PDP did not have available to them all the necessary
    > information.
    >> b) PDP issues a 'PERMIT' with a logging obligation. PEP does not want 
    >> to log because performance considerations have been put forward and 
    >> logging is low priority for the PEP. PEP issues an error.
    >
    > If PEP does not adher to rules set by PDP, then it does not play. If PDP
    > looses a lot of business because it makes onerous Obligations, then
    > it will either go out of business or change the Obligations.
    > I still do not see the case for making an Obligation optional. Either
    > it is sine-qua-non or it is not (and if it is not, why even bother
    > to state it). However, I do see that there may be alternate Obligations
    > or alternate ways of satisfying a higher level Obligation.
    > Cheers,
    > --Sampo
    > __________________________________________________________________
    > Sym  | Sampo Kellomaki  ______| Identity Architect, Federated SSO
    > ____ | +351-918.731.007 ______| Liberty ID-WSF DirectoryScript
    > labs | skype: sampo.kellomaki | LDAP SOAP PlainDoc Crypto C Perl
    >
    
    -- 
    Anil Saldhana
    JBoss Security & Identity Management
    http://labs.jboss.com/portal/jbosssecurity/
    
    
    


  • 2.  Re: [xacml] Re: Call for Obligations

    Posted 04-16-2007 13:02
    1. Don't give up yet. I am trying to cook up a way to deal with the  
    concept still ;)
    
    2. Yes. My desire is to create a number of Obligations templates.  
    Whether or not they turn out to be normative is another matter...
    
    b
    
    On Apr 15, 2007, at 9:04 PM, Anil Saldhana wrote:
    
    > Sampo,
    >  I think by now I have given up on the idea of obligations being  
    > optional. :) This is mainly due to added education from the others  
    > on the TC.
    >
    > Are we looking at at least standardizing some of the obligations  
    > like logging?
    > Looking at http://wiki.oasis-open.org/xacml/ 
    > DiscussionOnObligations, I am guessing Yes!
    >
    > Regards,
    > Anil
    >
    > sampo@symlabs.com wrote:
    >> Anil Saldhana writes:
    >>> My use cases in mind are the following(please correct me wherever  
    >>> my understanding is wrong):
    >>> a) Legitimate authorization request arrives at the PEP. PEP  
    >>> invokes the PDP. PDP comes back with 'PERMIT' and a set of  
    >>> obligations. PEP is unable to fulfill 1 or more obligations. PEP  
    >>> issues an error. What happened to the legitimate request?
    >>
    >> I understand you mean the authorization request was legit from global
    >> perspective, assuming all information was available, but might seem
    >> illegit when viwed locally, perhaps with some of the context or  
    >> information
    >> inaccessible.
    >> The conflict between PDP imposing Obligations that PEP can not
    >> satisfy vs. PDP having "intelligently" chosen the alternate
    >> Obligations that it "knows" PEP can satisfy is the key. At local
    >> level any request that does not come with enough context or  
    >> information
    >> to satisfy Obligations MUST be considered illegit. If such request,
    >> from global perspective should have been considered legit, then
    >> we need to see if there was architectural or layering reason why
    >> the PEP and PDP did not have available to them all the necessary
    >> information.
    >>> b) PDP issues a 'PERMIT' with a logging obligation. PEP does not  
    >>> want to log because performance considerations have been put  
    >>> forward and logging is low priority for the PEP. PEP issues an  
    >>> error.
    >>
    >> If PEP does not adher to rules set by PDP, then it does not play.  
    >> If PDP
    >> looses a lot of business because it makes onerous Obligations, then
    >> it will either go out of business or change the Obligations.
    >> I still do not see the case for making an Obligation optional. Either
    >> it is sine-qua-non or it is not (and if it is not, why even bother
    >> to state it). However, I do see that there may be alternate  
    >> Obligations
    >> or alternate ways of satisfying a higher level Obligation.
    >> Cheers,
    >> --Sampo
    >> __________________________________________________________________
    >> Sym  | Sampo Kellomaki  ______| Identity Architect, Federated SSO
    >> ____ | +351-918.731.007 ______| Liberty ID-WSF DirectoryScript
    >> labs | skype: sampo.kellomaki | LDAP SOAP PlainDoc Crypto C Perl
    >>
    >
    > -- 
    > Anil Saldhana
    > JBoss Security & Identity Management
    > http://labs.jboss.com/portal/jbosssecurity/
    >
    >