[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Re: Problem with the Example Response in the JSON Profile
Hi Rich, On 17/05/2013 5:37 AM, rich levinson wrote:
Hi David, I agree w you that the naming is incredibly confusing, however, I do not think that elevating "Category" does much to solve anything. I have been trying to promote the idea in previous emails that the XACML 3.0 spec should be updated and that the "Attributes" element be renamed to something more appropriate, such as "Entity". I believe that the Attributes collections in the XACML Request are consistent w the notion of "Business Entity" or "Business Object", and that, in general, the Business Objects in the application and platform spaces can generally be decomposed into Attributes. In fact, this is generally already done in the Object to Relational mapping that is often done to relate business objects to rows in relational databases. Therefore, conceptually, what I am proposing is that we look at the analogous relation between business objects in the application and platform arenas and rather than mapping them to rows in relational databases, that we map them into some kind of attributes for serialization over the network. Such activities are already done w technologies, such as Java RMI. However, Java RMI, is a platform-specific representation, and what I think is needed is an abstract representation. Also, I am not looking to solve the general business object to serial representation, but only looking to solve the problem as far as necessary to address the XACML authorization space, which, in fact, when one analyzes this space, is a very large and encompassing space that can reach almost anywhere to find an Attribute that might be useful in a Policy. Returning to the original point, if we view the XACML Request Attributes collections as collections representing some "real world entity", then the use of the term "entity" is quite natural to replace "Attributes" and also provides a conceptual bridge to associate the entity in the request to one or more business objects in the application and platform spaces.
This fits with my thinking on extending the request context into a graph of objects (my proposal in response to the "Attributes of Relations" thread). The domain of interest for authorization decisions includes not only the particular objects/entities that are the access subject and resource, but also entities that are related to those two in some way, for example, the parent, guardian, spouse, manager, doctor or employing organization of the access subject. Parent, guardian, spouse, manager and doctor are examples of the same kind of entity, a person, but "kind" doesn't equate to "Category" in my proposal because I'm fitting it into XACML version 3.0, where multiple <Attributes> elements with the same "Category" signify a request for multiple decisions. Rather, I interpret "Category" to be a tag for starting points in the graph of objects. For instance, the access-subject category tags the entity that is requesting access (typically, but not necessarily, a person entity) and the resource category tags the entity that is being accessed. The request context for an individual request may grow to include many entities of the same kind as the one singled out as the access subject, but there will only be one entity that is the access subject for an individual request. I support changing the name of "Attributes" to either "Object" or "Entity". I'm not fussed which, they are both equally good. I was thinking of calling my yet-to-be-started profile the "Related and Nested Objects Profile", but "Related and Nested Entities Profile" works too. I was planning to get on to it after I finish the first draft of the Obligation Authority profile. Regards, Steven
While I have not kept up w all the details of the JSON spec, I view it as simply an alternative representation of the same info that is in the XACML XML representation of an authorization Request, and by the same reasoning, I also view the XML as just one possible representation of the abstract notion of a collection of collections of attributes, where the middle layer of this abstraction corresponds to naturally to the level of business and platform object. The "Category" in this sense says what "kind" of "entity" is being represented where the "entity" is now the real world object from the perspective of the Policy authors. Thanks, Rich On 5/16/2013 5:19 AM, David Brossard wrote:I'm removing the Response / Result nesting. It's unnecessary. Also, as you suggest, we can do away w/ Request and Response and make them the root "unnamed" element in JSON - this makes it lighter. Any objection from anyone? On Tue, May 14, 2013 at 2:40 AM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote: Hi David, On 11/05/2013 8:32 AM, David Brossard wrote: So the right example would be: { "Response": { “Result” : [{ "Decision": "Permit" "Status":{ "StatusCode":{ "Value" : "http://foo.bar" } } }] } } I am thinking that there is one depth level too many. We could simply rewrite: { "Response": [{ "Decision": "Permit" "Status":{ "StatusCode":{ "Value" : "http://foo.bar" } } }] } whereby the response is an array of Result objects. I believe this works. What do you think? It would work. The <Response> element in the XML doesn't add anything to the result array. The only reason for keeping the extra level is for consistency with the XML Schema. You have a choice between the name "Response" or "Result" for the array. It depends on which element you think you are suppressing. I'm inclined to use "Result" for the array name since we have an unbounded list of them, but there is only supposed to be one "Response". If you do away with "Response", then you could equally well do away with "Request" on the request side and have the members of the "Request" object be members of the outermost JSON object. Regards, Steven On Mon, Mar 4, 2013 at 1:04 AM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com> <mailto:steven.legg@viewds.com <mailto:steven.legg@viewds.com>>> wrote: Hi David, The example Response object in section 5.2.4.1 should contain a Result object that contains the Decision and Status. The Result object is missing. Regards, Steven -- David Brossard, M.Eng, SCEA, CSTP Product Manager +46(0)760 25 85 75 <tel:%2B46%280%29760%2025%2085%2075> Axiomatics AB Skeppsbron 40 S-111 30 Stockholm, Sweden http://www.linkedin.com/companies/536082 http://www.axiomatics.com http://twitter.com/axiomatics -- David Brossard, M.Eng, SCEA, CSTP Product Manager +46(0)760 25 85 75 Axiomatics AB Skeppsbron 40 S-111 30 Stockholm, Sweden http://www.linkedin.com/companies/536082 http://www.axiomatics.com http://twitter.com/axiomatics-- Thanks, Rich Oracle <http://www.oracle.com> Rich Levinson | Internet Standards Security Architect Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity Management 45 Network Drive | Burlington, Massachusetts 01803 Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]