[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Observation on J2SE context proposal
I think that Anne's proposal is comprehensible and very interesting. So I would like to make an observation. First, I think that at least three important ideas are included in her proposal: [1] <ContextPrincipal> consists of a set of <SimplePrincipal> that represents a type of the principal with a set of attributes it holds. [2] The proposal aims to define a generic syntax and the semantics of the XACML Context instead of introducing application specific syntax and the semantics. [3] The <target> section of XACML rule includes simple expressions that specifies attribute types and values using XPath. Basically, I agree to all the ideas above. I think it solves many problems in applying XACML to J2SE use case. The following are my observations. [1] The structure of <ContextPrincipal> The first idea is particularly useful when XACML Context includes more than one principal that may have different set of attributes. I think using <SimplePrincipal> for grouping each principal is a good idea. I would prefer <Principal> for simplicity and symmetry instead of <SimplePrincipal> but it is a minor issue. (here I am assuming that <ContextResource> and <ContextAction> have a child element called <Resource> and <Action>, respectively.) [2] Generic syntax of the XACML Context The second idea makes XACML Context reference more generic. It would support the maximum interoperability of XACML policy specification. While her proposal seems to distinguish the name identifier (maybe holder's identity) and holder's attributes, I would suggest more aggressive generalization like we don't even distinguish the name identifier from other attributes. For example, a current context fragment of j2se:RequestingUser is: <xacml:SimplePrincipal PrincipalType="j2se:RequestingUser"> <xacml:NameIdentifier Format="itu:X500DistinguishedName"> "cn=Anne,ou=SunLabs,o=Sun,c=US" </xacml:NameIdentifier> </xacml:simplePrincipal> It is transformed to: <xacml:SimplePrincipal PrincipalType="j2se:RequestingUser"> <xacml:Attribute AttributeName="NameIdentifier" Format ="itu:X500DistinguishedName"> "Zoe@Sun.COM" </xacml:Attribute> </xacml:simplePrincipal> Now, the name identifier becomes a usual attribute. Similiary, the current context fragment of "CodeSource" is: <xacml:SimplePrincipal PrincipalType="j2se:CodeSource"> <xacml:NameIdentifier Format="ietf:URL"> "http://java.sun.com/jdk1.4/classes" </xacml:NameIdentifier> <xacml:Attribute AttributeName="SignedBy" AttributeFamily="j2se:Policy" Issuer="j2se:com.sun.labs.isrg.ClassLoader" IssueInstant="2002-05-28T00:00:00Z"> <xacml:AttributeValue> "cn=J2SESigner,ou=JavaSoft,o=Sun,c=US" </xacml:AttributeValue> <xacml:AttributeValue> "cn=SunSigner,o=Sun,c=US" </xacml:AttributeValue> </xacml:SimplePrincipal> It is transformed to: <xacml:SimplePrincipal PrincipalType="j2se:CodeSource"> <xacml:Attribute AttributeName="NameIdentifier" Format="ietf:URL"> "http://java.sun.com/jdk1.4/classes" </xacml:Attribute> <xacml:Attribute AttributeName="j2se:PolicySignedBy" Issuer="j2se:com.sun.labs.isrg.ClassLoader" IssueInstant="2002-05-28T00:00:00Z"> "cn=J2SESigner,ou=JavaSoft,o=Sun,c=US" </xacml:Attribute> <xacml:Attribute AttributeName="j2se:PolicySignedBy" Issuer="j2se:com.sun.labs.isrg.ClassLoader" IssueInstant="2002-05-28T00:00:00Z"> "cn=SunSigner,o=Sun,c=US" </xacml:Attribute> </xacml:simplePrincipal> As these examples show, the transformed context has more flatten structure (SimplePrincipal has only Attribute element(s)). The merit is that it makes both the context structure and the context reference simpler. The drawback is the repeated specification of the "Issuer" and "IssueInstant", while my guess is that the most policy will not have to use @Issuer and @IssueInstant attributes. (I am assuming that each <xacml:Attribute> has four attributes: mandatory @attributeName, optional @Format, optional @Issuer, and optional @IssueInstant.) Using this flatten structure, the context references become: SimplePrincipal[@PrincipalType ="j2se:RequestingUser"]/Attribute/@NameIdentifier SimplePrincipal[@PrincipalType="j2se:CodeSource"]/Attribute/@NameIdentifier SimplePrincipal[@PrincipalType ="j2se:CodeSource"]/Attribute/@j2se:PolicySignedBy I think these are simpler and more symmetric. [3] Simple expression specification in <target> I think J2SE policy example is basically trying to specify "AttributeSelector" based on the XPath expression in <target> in the <rule>, while there is other approach where those expressions are specified in <Conditions> section (as described in Simon's proposal). I would prefer writing simple expressions in <target> since it makes XACML policy simpler and more explicit. (I am not saying that every conditional expression should go into <target> section. From my viewpoint, it should be limited only to the equality to allow implementation to make index). What I am concerned is the repeated specification fragment like [@PrincipalType="..."] and /Attribute/. It might not be a problem since XACML Policy is dealt by the system, not by a human, but I am interested in a solution for this repeated specification. Michiharu Kudo IBM Tokyo Research Laboratory, Internet Technology Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC