[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: The architecture of my experimental delegation implementation
During the face to face there was a discussion on how to describe the architecture of the PDP with respect to delegation processing. One action item for me was to explain the architecture of the implementation I made last year, so it could inspire the discussion on how to do it for the delegation profile. I will explain my implementation in this email. Keep in mind that when I did this I was constrained by that I was using the sunxacml 1.2 code. To make things easier for me I only used XACML 1.1, which is implemented by the sunxacml code and I stayed within the public extension points of XACML 1.1. This way I didn't need to do a major rewrite of the sunxacml code. However, this also makes my solution somewhat inelegant. Also, I have not implemented many of the features that are intended to be part of the new delegation pofile, such as reduction of deny. Since the XACML 1.1 processing model does not have any concept of repeated requests or an issuer element in policies, I used obligations to implement them. The issuer of a policy is put in an obligation, which is generated from a digital signature when the policy is downloaded from the network and installed in the PDP. I have custom combining algorithm which collects the obligations of permitting policies and includes them in the result. Also, if the combining algorithm finds a permitting policy that does not contain an issuer obligation, any other issuer obligations are simply dropped from the result.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]