OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

[xacml] Observation on J2SE context proposal

  • 1.  [xacml] Observation on J2SE context proposal

    Posted 06-03-2002 04:43
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [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