[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Bindings and frameworks for PEP to PDP access
Hal, the use case is the construction of policies, requestctx and responsectx objects. - Every implementation is going to have its own API (irrespective of programming language) in the construction of these three objects. For example: I would like to programmatically construct a Policy/PolicySet instance and pass it to the PDP. Similarly, PEP implementors will need to use some proprietary API in constructing the R/R context objects. I do not think that this topic is critical at the spec level but good to have. Regards, Anil Hal Lockhart wrote: > This was discussed on the last call and after some discussion of Java, > Anil suggested that perhaps we could specify a language independent API. > > I have been thinking about this, but my conclusion is that the XACML > Request and Response Contexts do in fact specify a language independent > API. Since the spec says that it is not required that they be > instantiated as XML documents, that means implementations are free to > map them (and some invocation mechanism) to the mechanisms and data > types of Java, C++ of whatever language needs to be supported. > > I believe Prateek's motives are to provide better performance while > retaining the interoperability of the SAML decision request protocol. > IMO this will only be obtained by specifying language specific > datatypes, etc. in detail. > > Anil, did you have something else in mind? > > As an additional requirement, I believe that applications per se should > not be making calls to the PDP. I think that in ordinary cases the > container should act as the PEP and collect the inputs and call the PDP. > This applies whether the container is J2EE, Servlet or .Net. > > Hal > > >> -----Original Message----- >> From: Prateek Mishra [mailto:prateek.mishra@oracle.com] >> Sent: Thursday, September 27, 2007 9:17 AM >> To: xacml@lists.oasis-open.org >> Subject: [xacml] 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. >> > > -- Anil Saldhana Project/Technical Lead, JBoss Security & Identity Management JBoss, A division of Red Hat Inc. http://labs.jboss.com/portal/jbosssecurity/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]