[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Updated Change Requests
Attached is the list of Change Requests as of 3pm Wed. afternoon (EDT). I have included the substance of all the comments for the "active" issues, so this is a "one stop shop" document for our meeting tomorrow (except for the ton of mail that will come in right after I post this :-). Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
Title: Change Requests Set 2
Author: Anne Anderson
Version: 1.8, 02/10/02 (yy/mm/dd)
Original Source: /net/labeast.east/files2/east/info/projects/isrg/xacml/docs/SCCS/s.ChangeRequests2.txt
This version contains all Change Requests not reflected in v17.0
of the specification (i.e. received after the TC meeting on 26
Sept 2002. For earlier Change Requests (all disposed of by 26
Sept 2002) see the following e-mail in the archive:
http://lists.oasis-open.org/archives/xacml/200209/msg00185.html
or reference the mail titled "[xacml] Updated Change Request
list", from Anne Anderson, 26 Sep 2002.
Contains all e-mail up to and including archive msg msg00203.html
ACTION ITEMS
============
None
LEGEND
======
NQ=no quorum; official vote required
Q=quorum
SUMMARY
=======
0064. [Michiharu] <AttributeSelector> Text change request
STATUS: APPROVED (Q 9/26) New text APPROVED (NQ 9/30)
0065. [Anne] x500Name-equal and X500Name-match errors in Functions v13
STATUS: APPROVED (NQ 9/30) with addition of footnote text.
0066. [Simon] change request: namespaces in xpath expressions
STATUS: APPROVED (NQ 9/30). Both proposals 1. and 2. approved.
0067. [Simon] change request: resource content
STATUS: APPROVED (NQ 9/30). Proposal 1 only.
0068. [Simon] change request: subject-attribute-designator and subjectcategory
STATUS: Discussed 9/30. No resolution. Anne in favor.
0069. [Simon] change request: xacml context attributes and data types
STATUS: Discussed 9/30. See [9/30] below. Feedback requested.
0070. [Michiharu] resource:scope attribute missing
STATUS: APPROVED (NQ 9/30)
0071. [Simon] Appendix B needs text describing syntax of x500Name,rfc822Name
STATUS: APPROVED (NQ 9/30)
0072. [Simon] subject attribute designators
STATUS: e-mail dated Tue,01 Oct 2002
0073. [John Howard] Comparing KeyInfos
STATUS: e-mail dated 02 Oct 2002, forwarded by Anne
DETAILS
=======
0064. [Michiharu] <AttributeSelector> Text change request
http://lists.oasis-open.org/archives/xacml/200209/msg00179.html
STATUS: APPROVED (Q 9/26) New text APPROVED (NQ 9/30)
AttributeSelector, Page 49
<AttributeSelector> [required]
MAY be used to identify one or more values in the <Subject>
element of <xacml-context:Request> element. It MUST contain
a legal xpath expression over the <Subject> element of the
<xacml-context:Request> element.
==>
<AttributeSelector> [optional]
Attribute selector using XPath expression. It MUST contain a
legal xpath expression over the <xacml-context:Request>
element. This operator returns a bag of string data or a
single primitive value. In case of XPath 1.0, an evaluation
value of the XPath expression is either a node set, string
value, numeric value, and boolean value. When node set is
returned, each node may consist of children nodes (structured
node). Then each node is converted into a string data by
applying a string function defined in XPath 1.0
specification. Then this operator returns a bag of string
values. When either string, numeric or boolean value is
returned, this operator returns a single primitive value of
xs:string, xs:decimal, and xs:boolean type,
respectively. When this element is specified, the policy MUST
define the version of the XPath specification using
<XPathVersion> element. When an xpath expression has one or
more namespace prefix, they are resolved using XPath
namespace and prefix information specified in the
<XPathNamespace> element below this operator. If no such
element is specified, then an <XPathNamespace> element in
<PolicyDefaults> element in the parent <Policy> (or
<PolicySet>) element is used.
[Polar] <AttributeSelector>
AttributeSelector using an XPATH expression.
The AttributeSelector's "RequestContextPath" XML attribute
shall contain a legal XPATH expression over the
<xacml-context:Request> element. The selector element
evaluates to a bag of a single primitive value that is
implied by the type system, i.e. the function application in
which the selector appears.
In case of using XPATH 1.0, the value of the XPATH expression
is either a node-set, string value, numeric value, or boolean
value. If the XPATH 1.0 expression evaluates to a node-set,
each node may consist of a string, numeric, boolean value, or
a child node (ie. structured node). In this case, each node
is logically converted to string data by applying the
"string" function defined in XPATH 1.0 specification
resulting a sequence of string data. In the single string,
numeric, or boolean value case, the value is converted to
string data by applying the string function defined in XPATH
1.0 specification resulting in a sequence of one string data
element. In XPATH 2.0, the result of the XPATH expression is
always a sequence of nodes. In this case, each node is
logically converted to a string using the aforementioned
string function resulting in a sequence of string data. The
resulting sequence of string data is converted to a bag of
primitive values that is implied by the type system.
[Polar, quoting Michiharu]
> The sentence you provide is basically fine.
>
> [1]
> in XPATH 1.0 specification resulting in a sequence of one
> string data element.
> ==>
> in XPATH 1.0 specification resulting in a bag of one string
> data element.
Actually, I used "sequence" to unify both the XPATH 1.0 and
2.0 descriptions. Then logically convert the "sequence of
string data" to a bag of primitive values.
>
> [2]
> Since XPath 2.0 returns either a sequence or the error
> value, we should say that "the result of the XPATH
> expression is a sequence of items (item is an atomic value
> or a node) or the error value. When the error value is
> returned, the PDP SHOULD return Indeterminate."
OKay.
[Michiharu] OK.
In case of XPath 2.0, "xf:string accessor" is better than
"aforementioned string function".
[New Text approved 9/30/02]
<AttributeSelector>
AttributeSelector using an XPATH expression.
The AttributeSelector's "RequestContextPath" XML attribute
shall contain a legal XPATH expression over the
<xacml-context:Request> element. The selector element
evaluates to a bag of a single primitive value that is
implied by the type system, i.e. the function application in
which the selector appears.
In the case of using XPATH 1.0, the value of the XPATH
expression is either a node-set, string value, numeric value,
or boolean value. If the XPATH 1.0 expression evaluates to a
node-set, each node may consist of a string, numeric, boolean
value, or a child node (ie. structured node). In this case,
each node is logically converted to string data by applying
the "string" function defined in the XPATH 1.0 specification,
resulting a sequence of string data. In the single string,
numeric, or boolean value case, the value is converted to
string data by applying the "string" function defined in the
XPATH 1.0 specification, resulting in a sequence of one
string data element.
In XPATH 2.0, the result of the XPATH expression is a
sequence of items (where an item is an atomic value or a
node) or the error value. When the error value is returned,
the PDP SHOULD return "Indeterminate". Otherwise, each node
is logically converted to a string using the xf:string
accessor function, resulting in a sequence of string data.
The resulting sequence of string data is converted to a bag
of primitive values that is implied by the type system.
0065. [Anne] x500Name-equal and X500Name-match errors in Functions v13
http://lists.oasis-open.org/archives/xacml/200209/msg00186.html
STATUS: APPROVED (NQ 9/30) with addition of footnote text.
The descriptions for the functions x500Name-equal and
x500Name-match in XACML_Functions.doc v13 are mixed up. In
particular, the "x500Name-match" description is actually the
"x500Name-equal" description.
Here are the correct descriptions:
o x500Name-equal
This function shall take two arguments of "xacml:x500Name" and
shall return an "xs:boolean". It shall return true if and only
if each Relative Distinguished Name (RDN) in the two arguments
matches. Two RDNs match if and only if the result of the
following operations is true.[*]
First, normalize the two arguments according to IETF RFC 2253
"Lightweight Directory Access Protocol (v3): UTF-8 String
Representation of Distinguished Names".
Second, if any RDN contains multiple attributeTypeAndValue
pairs, re-order the Attribute ValuePairs in that RDN in
ascending order when compared as octet strings (described in
ITU-T Rec. X.690 (1997 E) Section 11.6 "Set-of components").
Finally, compare RDNs using the rules in IETF RFC 3280
"Internet X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) PRofile", Section 4.2.1.4
"Issuer".
[*] ITU-T Rec. X.520 contains rules for matching X500 names,
but these are very complex and require knowledge of the
syntax of various AttributeTypes. IETF RFC 3280 contains
simplified matching rules that the XACML x500Name-equal
function uses.
o x500Name-match
This function shall take two arguments of "xacml:x500Name" and
shall return an "xs:boolean". It shall return true if and only
the first argument matches some terminal sequence of RDNs from
the second argument when compared using x500Name-equal.
0066. [Simon] change request: namespaces in xpath expressions
http://lists.oasis-open.org/archives/xacml/200209/msg00190.html
STATUS: APPROVED (NQ 9/30). Both proposals 1. and 2. approved.
There are several instances in the policy schema where we
pass xpath expressions as arguments.
1. In the case of <xacml:AttributeSelector> element
RequestContextPath attribute contains xpath expression
that selects xacml attribute value from the context.
2. When xpath functions are used in the target, the value to
match again is xpath expression.
3. When xpath functions are used in conditions they take
xpath expressions as arguments.
All examples are from section 4.2
For the attribute-selector we use XPathNamespace element that
maps namespace uri to namespace prefix (essentially
duplicating standard xml namespace declaration)
AttributeSelector:
<AttributeSelector RequestContextPath=
"//ctx:RequestContext/md:record/md:patient/md:policyNumber">
<XPathNamespace NamespaceURI="urn:names:tc:xacml:1.0:context" Prefix="ctx"/>
<XPathNamespace NamespaceURI="http://www.medico.com/schemas/record.xsd"; Prefix="md"/>
</AttributeSelector>
For other uses of xpath functions we do not have special
provisions for namespace mapping. Here is how xpath
expression is used in the target to match request:
<ResourceMatch matchId="function:xpath-match">
<ResourceAttributeDesignator AttributeId=
"urn:oasis:names:tc:xacml:1.0:resource:xpath"/>
<AttributeValue>/md:record</AttributeValue>
</ResourceMatch>
In this case we rely on standard xml namespace declaration
for the md prefix.
To summarise: we use two methods to deal with the same
problem: one is standard and one is not.
Proposal:
1. Use standard xml namespace declarations mechanism in both
cases and drop <XPathNamespace> element.
2. Change RequestContextType attribute of AttributeSelector
to xs:string (it is currently xs:anyURI).
[Michiharu] I understand your intention but I am not sure
whether or not using standard XML namespace (your first
proposal) is really good for our case.
My opinion is that standard XML namespace (you mean xmlns:md
="http://www.... record.xsd", right?) should primarily mean
the namespace for element name of the policy itself. In other
words, XACML policy may include other namespace (currently
seems not but actually we had when SAML schema fragment was
used in our policy). I think xmlns should be used for that
case. Since we need to determine the namespace for the value
of the policy (not element name nor attribute name), it seems
reasonable to use application-specific namespace designator
(XPathNamespace) currently we have. How do you think?
[Simon] You are correct, xmlns decl is used for elements and
we have data. Our first problem is that we do not cover all
cases with XPathNamespace element. Also, declaring
XPathNamespace in the PolicyDefaults is equivalent in my
opinion to declare namespace prefix on the Policy itself. So
I'd like to use xmlns decl, although it's usage is applied to
data.
0067. [Simon] change request: resource content
http://lists.oasis-open.org/archives/xacml/200209/msg00191.html
STATUS: APPROVED (NQ 9/30). Proposal 1 only.
<xacml-context:Resource> element has
<xacml-context:ResourceContent> child. If resource content
is relevant in access decision it is placed as a child of
<ResourceContent> element.
Currently, the only way to access <ResourceContent> and it's
children elements is with <xacml:AttributeSelector>, support
for which is optional.
There is no way to access this data with
<xacml:ResourceAttributeDesignator>.
Proposal 1: Introduce resource attribute identifier:
"urn:oasis:names:tc:xacml:1.0:resource:resource-content" that
will address <ResourceContent> element. In this case, both
<ResourceContent> and identifier refer to the same entity. No
schema change required.
Proposal 2: Drop <ResourceContent> element and introduce
resource identifier as above. The xpath expressions in the
<xacml:AttributeSelector> will be taken over this resource
attribute:
<AttributeSelector RequestContextPath=
"//ctx:Request/ctx:Resource/
ctx:Attribute[@AttributeId='urn:oasis:names:tc:xacml:1.0:resource:resource-content']/*"/>
In both cases (1) and (2) we can access content with
resource-attribute-designator: <ResourceAttributeDesignator
AttributeId="urn:oasis:names:xacml:1.0:resource:resource-content"/>
[Michiharu] I am ok with your first proposal but I am not
clear on the second one. The intention of having a
ResourceContent element in XACML Request Context is that it
must allow any arbitrary XML fragment below ResourceContent
element. That's why the schema allows any structure. If you
remove the ResourceContent and place the arbitrary XML
fragment below Attribute element instead, you will need
another changes on schema, for example to allow any elements
below Attribute element or to introduce a new elements like
ResourceContent.
[Simon] Ok, than we can declare an attribute identifier that
will point to the content (alt 1).
0068. [Simon] change request: subject-attribute-designator and subjectcategory
http://lists.oasis-open.org/archives/xacml/200209/msg00192.html
STATUS: Discussed 9/30. No resolution. Anne in favor.
xacml request context supports multiple
<xacml-context:Subject> elements. Each
<xacml-context:Subject> element is tagged with the
subject-category, such as: access-subject, codesource,
etc. Subject category name is unique, ie there is no two
<xacml-context:Subject> elements in the request context with
the same value of subject-category attribute.
<xacml:Subject> element in the policy allows us to specify
multiple subject matches at the same time: sm1 'and' sm2
'and' sm3 etc. Syntactically, context subject attribute is
selected with <xacml:SubjectAttributeDesignator> element that
names attribute-id and issuer.
Very often all subject attributes must be selected from the
same subject block.
Proposal: Extend <xacml:SubjectAttributeDesignator> with
optional SubjectCategory attribute:
<xs:complexType name="SubjectAttributeDesignatorType">
<xs:attribute name="AttributeId" type="xs:anyURI" use="required"/>
<xs:attribute name="Issuer" type="xs:anyURI" use="optional"/>
<xs:attribute name="SubjectCategory" type="xs:string" use="optional"/> <-- new attribute
</xs:complexType>
[Polar] I thought the purpose of the
SubjectAttributeDesignatorWhere was to get all matches from
the same subject, of which subject-category was one of the
attributes you match on.
I think we worked this out quite well, and cuts down on the
machinery needed to just select mere attributes from a
subject.
[9/30 discussion] Polar's objection does not apply to Simon's
case, since SubjectAttributeDesignatorWhere can not be used
in a Target. Anne is in favor of Simon's proposal, but the
group feels more input is needed.
0069. [Simon] change request: xacml context attributes and data types
http://lists.oasis-open.org/archives/xacml/200209/msg00193.html
STATUS: Discussed 9/30. See [9/30] below. Feedback requested.
Currently <xacml-context:Attribute> element allows DataType
attribute.
Rationale for keeping DataType attribute in the
<xacml-context:Attribute> element was that it can sometimes
be helpful, such as specifiying subject-id format, like
subject-id="cn=simon", data-type="x500-name"
But this information is redundant, because subject-id
attribute will be passed to the specific function that
expects arguments of certain type. For example, if subject-id
is passed to the x500Name-equal function it expects it's
arguments to be in x500 name format.
So data type does not add value here.
Another problem is that we can not access DataType attribute
with AttributeDesignator.
Proposal: remove DataType attribute from the
<xacml-context:Attribute>.
[Anne] But, as discussed on yesterday's call, a <Subject> may
have more than one subject-id attribute. For example, one
may give the rfc822Name under which the subject
authenticated, and another may give the x500Name.
The datatype is required to allow the AttributeDesignator to
select the instance of the attribute that has the correct
datatype for the function in which the designator occurs.
[Polar] I agree with removing the dataType attribute from the
xacml-context:Attribute.
However, the implications are this:
If you have an Attribute of "subject-id" and its value is:
<AttributeValue>CN=Simon Godik, O=OverXeer, OU=Research</AttributeValue>
What does the designator:
<SubjectMatch MatchId="function:rfc822Name-equal">
<SubjectAttributeDesignator AttributeId="subject-id"/>
<AttributeValue>simon@godik.com</AttributeValue>
</SubjectMatch>
evaluate to?
Does it evaluate to "indeterminate" because the formal type
of rfc822Name-equal is
xacml:rfc822Name -> xacml:rfc822Name -> Bool
and the attribute value is an invalid representation of an
rfc822Name.
Or does it evaluate to "false"?
The question in the context of its application, the
<SubjectAttributeDesignator Attribute="subject-id">
shall return a bag of "rfc822Name", which means that every
"subject-id" attribute must have a parseable rfc822Name
representation as a value.
So, does the designator return "indeterminate" because not
*all* values under "subject-id" are valid string
representations of rfc822Name?
Or does it return a bag of rfc822Names of *only* the values
under "subject-id" that do have valid string representations
of rfc822Names? In the example above for the latter case,
this designator would return an empty bag.
[Polar, responding to Anne] Right, if the dataType attribute
exists, if you are looking for attributes of a particular
datatype, of which our XACML strong type system will infer,
you can pick them out of the context by the dataType
attribute.
It can be optional, however, as I pointed out in my last
email, you have to decide on what to do with the designator
if the AttributeValue isn't a valid parseable representation
of the data type named in the dataType attribute.
[Bill] i suggest that this has to evaluate to FALSE.
INDETERMINATE implies that the value is out of scope of the
data set. while it may be argued that this is true at the
philosophical level, i don't think it is consistent with how
we are handling similar issues--what happens if a PEP
requests to 'toad the wet sprocket' (resource unknown, action
unknown)?
this is consistent with my current assumptions that these
values will be evaluated as [right-to-left] string
comparisons. if that isn't the case, then i would like to
hear the reasoning for requiring the logic necessary to
differentiate between the two at evaluation time (explicit
vs. implicit run-time type validation)
[Simon, responding to Anne] If this is the case we should
extend attribute designator to specify data type of the
attribute to be selected.
[9/30] In the meeting on 9/30, the following issues were
outlined:
1. Need to be able to select attributes based on datatype.
Example: Policy writer wants to indicate "This policy
applies to all requests containing a <Subject> that has an
x500Name of "cn=Anne, o=Sun, c=US".
The policy Target using the 16i schema would contain:
<Subjects>
<Subject>
<SubjectMatch MatchId="function:x500Name-equal">
<SubjectAttributeDesignator
AttributeId="subject:subject-category"/>
<AttributeValue>cn=Anne, o=Sun, c=US</AttributeValue>
</SubjectMatch>
</Subject>
</Subjects>
But, assume a given <Subject> has authenticated with both
an rfc822Name and an x500Name. Then the Request will look
as follows:
<Subject>
<Attribute AttributeId="subject:subject-category"
DataType="x500Name">
<AttributeValue>cn=Anne, o=Sun, c=US</AttributeValue>
</Attribute>
<Attribute AttributeId="subject:subject-category"
DataType="rfc822Name">
<AttributeValue>anne@Sun.COM</AttributeValue>
</Attribute>
</Subject>
The policy should be applicable to this Request (I think),
but the SubjectAttributeDesignator will match both
Attributes in the Request, and one of them will be of type
"rfc822Name". Not only will the result be a bag (which
can't be passed to x500Name-equal), but there will be a
conversion error in attempting to convert the rfc822Name
to an x500Name.
2. Where are values converted to internal representations
that are typed? Does this occur when the
- Context AttributeValue is parsed?
- AttributeDesignator is parsed?
- SubjectMatch MatchId function is evaluated?
We need feedback from people who are doing actual
implementations on this.
3. We agreed that, if a function is passed a value that is
the wrong type, that the result is "Indeterminate", NOT
"False". So we need a way for the policy writer to select
only the values that are (at least are intended to be) of
the right type.
4. We all agreed that the PDP can not rely on the PEP or the
PAP to specify correct datatypes for values. But a
datatype specification could be used to indicate intent.
[Polar] So we are back to putting the x500Name data type back
in the attribute designator? Geez, I thought the vodka was
making my head spin!
[Seth Proctor] I am (somewhat) concerned about the choice to
remove type information from the AttributeValue type in the
Policy schema. I understand that the Function listed in the
AttributeValue tells us what types are allowed, but there are
two problems I see here. First, It is significantly more work
for a programmer to support this method for finding the
attribute's type, and it requires an API that is more complex
(for extending the engine to support custom functions). This
is a small issue, but it's one to consider when making a
language change. The second problem I see is more
serious. While the function gives us the type the attribute
is expected to be, it doesn't tell us what the attribute's
type actually is. If someone builds a policy, and puts in an
integer value (for instance) as an input for a function that
expects a string, the attribute will parse fine, but will not
be used in the way that was intended for the attribute
value. Obviously this is a simple example where it might not
be such a problem, but with custom datatypes this could be
more serious. There is no way to check that the attribute
type being used is the correct one. Including the attribute
type in the AttributeValue object may be redundant from a
language point of view, but it provides (in my opinion) a
valuable reality-check to make sure that the policy isn't
being evaluated in a manner that the policy author didn't
intend.
In the case of the Attribute type in the Context schema, the
problem is compounded. First, the implementation is harder,
since when you're parsing the Request object you can't parse
any of the attribute types, since you don't know what type
they are until you start processing the policy and find what
functions are being used. Not only is this harder, but it's
(arguably) less effecient. Second, because you can't parse
the attribute values until you consider them in the scope of
a function, you could end up with designators that select the
same attributes as inputs into functions that take different
values. Drawing from the example above, what happens if a
policy wants to interpret the same attribute as a String, an
Integer, and some custom type? Is this an error, or should
this be allowed? I suspect that all Requests will be formed
with attributes of known and intended values, so I think this
is a real problem. Last, because the Attributes aren't being
included in the Request in the scope of a Function, the
requestor has no idea how the attribute will be used in the
policy, and so trying to guess at the value based on the
function's types seems very dangerious to me. I would suggest
that the type field in the Attribute type be made
manditory. It may not seem as pretty in the language, but it
heads off a lot of ambiguity without adding almost any
overhead to the language (or making it any harder to form a
Request), and that seems like a very worthwhile tradeoff to
me.
I would welcome any discussion on this topic with those of
you on the list. I would like to see a final version of the
language soon, so please don't take any of this as an attempt
to slow things down. I have backed off on other issues with
Anne that I didn't think were worth taking the time to
address, but I feel this issue is pretty important to sort
out. Including the types of Attibutes and AttributeValues is
a seriously small piece of the schema, but it can have
significant effects on implementation and interpretation.
[Daniel] I would agree with his suggestion of keeping the
dataType.
I would also like to point out his concern that "it requires
an API that is more complex (for extending the engine to
support custom functions)"
I have noticed the same issue. It is even more pronounced
with the "higher-order" functions, with their current syntax.
BTW - was there any discussion on MIchiharu's proposal on
their extensibility?
0070. [Michiharu] resource:scope attribute missing
STATUS: APPROVED (NQ 9/30)
The <prefix>:resource:scope attribute and its values, as
described in 7.2 Hierarchical resources, is not included in
Appendix B or in the Conformance Section. These should be
included.
[Appendix B: add to list:]
This identifier indicates the scope of the resource, as
described in Section 7.2 Hierarchical resources.
urn:oasis:names:tc:xacml:1.0:resource:scope
The allowed value for this attribute is of type xs:string,
and is either "Immediate", "Children", or "Descendants".
[Conformance Section, Attributes, add to list]
urn:oasis:names:tc:xacml:1.0:resource:scope O
0071. [Simon] Appendix B needs text describing syntax of x500Name,rfc822Name
STATUS: APPROVED (NQ 9/30)
[Section B, DataTypes, add after]
urn:oasis:names:tc:xacml:1.0:datatype:x500Name
An x500Name contains an ITU-T Rec. X.520 Distinguished Name.
The valid syntax for such a name is described in IETF RFC
2253 "Lightweight Directory Access Protocol(v3): UTF-8 String
Representation of Distinguished Names".
urn:oasis:names:tc:xacml:1.0:datatype:rfc822Name
An rfc822Name contains an "e-mail name". The valid syntax
for such a name is described in IETF RFC 2821, Section 4.1.2
Command Argument Syntax, under the term "Mailbox".
0072. [Simon] subject attribute designators
http://lists.oasis-open.org/archives/xacml/200210/msg00001.html
STATUS: e-mail dated Tue,01 Oct 2002
Xacml request context allows for multiple subjects. Each
subject block is identified with the subject-category.
Subject-category identifies different 'actors':
access-subject, codesource, etc.
Category of 'access-subject' is requestor's identity.
There are use cases, such as 'integrated login' where
multiple auth mechanisms are integrated. Sun solves this
with 'pluggable auth module' framework (pam). Pam allows for
multiple authentication protocols to be configured per
application.
This shows that xacml context may contain multiple subject
blocks with the same category of 'access-subject': separate
block per authentication protocol.
Subject blocks are accessed with
subject-attribute-designators.
Assumpsion: subject block is uniquely addressed by
subject-category and authentication protocol.
Proposal.
Drop DataType attribue of the <xacml-context:AttributeType>.
Extend xacml:subject-attribute-designator with
subject-category, and protocol attributes:
<complexType name SubjectAttributeDesignatorType>
<attribute name="AttributeId" type="xs:string" use="required"/>
<attribute name="Issuer" type="xs:anyURI" use="optional"/>
<attribute name="SubjectCategory" type="xs:string" use="optional"/> <-- new
<attribute name="Protocol" type="xs:anyURI" use="optional"/> <-- new
</complexType>
example 1.1 - match 'group' attribute of a subject
authenticated with kerberos:
subject-match match-id="string-equal"
subj-attr-desig attr-id="group" issuer="some-issuer" subj-cat="access-subject" protocol="kerb"
attr-value admin
example 1.2 - match 'subject-id' attribute of a subject
authenticated with kerb:
subject-match match-id="rfc822Name-match"
subj-attr-desig attr-id="subject-id" subj-cat="access-subject" protocol="kerb"
attr-value bart@simpson.com
Note that in example 1.2 subject block is identified by the
protocol (kerb), not by the name format.
[Polar] This is where we get into complex principals that are
subject to the requests. If you allow more than one for the
subject category, You end up with the same problem with
subject-category="access-subject", whether you have it as an
Attribute or not, because your designator will return values
for each attribute type requested, and you will not be able
to tell which one they are from.
I thought, we were saying that for now, i.e. 1.0, there is
only one access-subject, denoted by the subject-category
attribute.
True with the PAM you may have several IDs for a subject
based on different protocols. However, on the target side,
when a request is made, you will generally only have one
authentication protocol used, and therefore only one id for
the access-subject.
Please, let's keep this simple enough to provide
acess-control for simple subjects on simple resources at the
target.
I don't know if this is happed, but I think we should stay
with the model that:
1 "subject-category" is an Subject Attribute.
2. Only one Subject per "subject-category" in the
RequestContext.
However, we can add "authentication-mechanism" as attribute,
as well as "authentication-protocol". Note; the two may be
different, or not implied by one or the other.
[Simon] Polar, I do agree with you that unique subj-category
is the simpliest case. And it was my understanding for some
time.
We have to decide if the 'integrated login' that is solved by
sun with pam is a requirement that must be met in xacml
1.0. Pam specifically calls out a use case when user must be
authenticated with more than one protocol.
I would support postponing 'integrated login' till the next
version, but in the mean time I wanted to have concrete
proposal how to deal with it if we have to.
0073. [John Howard] Comparing KeyInfos
http://lists.oasis-open.org/archives/xacml/200210/msg00003.html
STATUS: e-mail dated 02 Oct 2002, forwarded by Anne
In a couple of the conformance tests (IIB016, 11B017) there
is a requirement to compare KeyInfos. The comparison is
performed as a string-match even though the data type is
KeyInfo. As KeyInfos can be compared in a number of ways the
string-match would appear inadequate. e.g. In the simple
case
<ds:KeyInfo>
<ds:KeyName>jhibbert-key</ds:KeyName>
</ds:KeyInfo>
would not match
<ds:KeyInfo>
<ds:KeyName>jhibbert-key</ds:KeyName>
<ds:KeyValue>....</ds:KeyValue>
</ds:KeyInfo>
Although the KeyInfos are the same.
Is there a need for a keyinfo-match function or is there a
more generic object-match that would match based on the data
type and therefore be completely extendable.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC