MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: (local) names and issuer as string issue
In my (ever) continuing effort to find reasons to change the attribute issuer as
string, I came up with an other argument:
As we don't put any restriction on the attributes values, they can be "local"
names, meaning, they are not required to be globally unique and that all is left
to the issuer.
This implies that for example, "frank" could bind a name "tim" to a key and
"hal" could bind the same name "tim" to possibly an other key, and this would
not imply that both frank and hal are referring to the same tim...
In the targets and rules, you can do the matching on both the name and the
issuer to get rid of the ambiguity, which is essentially including the issuer
with the name, like "frank's tim" and "hal's tim"
However, if we take this one level further, then "hal's tim" may not be the same
as "hal's tim", because "hal" may not be "hal" .... ;-)
We can for example have a different "hal" in "polar's hal's tim" and "ann's
hal's tim", and our current attribute scheme won't be able to distinguish them.
One could argue, that we could do the attribute binding validation before we
enter the xacml evaluation world, but I don't believe that works for local name
bindings: one can not see from the name assertion itself whether it is valid or
not as its proper use is only in context, i.e. if there are
xacml-rules/conditions that explicitly use that "issuer's name".
The recursion of these nested name bindings is stopped by an issuer with a
'secure name'. The latter is a name with has implicit trust and is unique within
the context, like a bare public key, a kerberos principal@realm through a shared
secret with that kdc, a path-validate X.500 DN through a configured trust root,
or possibly through a local name-password database.
In a short discussion that brought this all up, Polar suggested that we should
just use some string concatenation convention to include the assertion path in
the name value, like "polar's hal's tim". This would leave the issuer value to
hold a secure name.
My objection was that this string concatenation was not very elegant... but I
believe that Polar doesn't have a very "elegant" impression of XML in general,
so he wasn't impressed with my argument...;-)
In summary, if we allow local name bindings (which is a good thing, btw!), then
we may need some additional facilities to unambiguously identify these names
within the context of the rules.
Comments? Suggestions?
Regards, Frank.
--
Frank Siebenlist franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]