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: 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]