[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Bindings and frameworks for PEP to PDP access
This is an issue that was discussed at the f2f and was also featured as case 2.1.1 of the interop. Its been some time since we discussed this issue, so I will first point to the relevant text from the f2f. http://lists.oasis-open.org/archives/xacml/200703/msg00071.html [quote] C: closely coupled PEP/PDP ... D: PEP/PDP issues: how do you know what inputs the policies refer to? ... [\quote] The starting point of the analysis here is to understand three distinct roles that are involved: (a) application developer (b) deployment manager (c) policy manager. The application developer inserts call-outs to the XACML engine and processes results as returned from the PDP. This follows the model in Section 2.1.1. of the interop document. At the F2F it was suggested that JSR #115 satisfies these requirements but a quick analysis of JSR #115 shows that while it allows for a policy engine to be connected to a java container but it doesn't expose key XACML functionality. Some of the gaps include: (i) ability to pass arbitrary environment, resource and action attributes (ii) ability to process returned values from the PDP - especially obligations. One additional constraint that should be noted here is that application developers may not be aware of all the information required for the authorization call-out. The reason for this that policy's are created by policy managers, and this information may not be available when the application is being developed. The deployment manager interacts with the PDP and PEP (in this case the application) to create the appropriate linkages. At this stage adequate information may be available to complete the linkage between the two. Specifically, the deployment manager requires: (i) what requests are being made from PEP and what attributes are currently being transferred (ii) Which policies at the PDP are relevant to the PEP requests, and what attributes should be included in the requests originating from the PEP So some form of reconciliation is needed at this point, especially one that does NOT involve re-coding/re-building the PEP but rather extending it so that all required attributes become available. There may also need to be a certain amount of coordination between the deployment manager and the policy administrator. SUMMARIZING: I have described a use-case that we have found quite significant and which was one of the two scenarios demonstrated at the interop. I would be interested in feedback on the use-cases and any comments on standards and frameworks available to solve these cases.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]