OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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