Re: [xacml] (local) names and issuer as string issue

[Frank Siebenlist <franks@mcs.anl.gov>]

Polar Humenn wrote:

> On Mon, 15 Sep 2003, Frank Siebenlist wrote:
> 
> 
>>[snip]
> 
> 
>>So instead of leaving the (local) name assignement and proper usage procedure
>>outside of the xacml world through some unspecified means, it may be better to
>>have the rule-writer specify that it is "acme-hr's polar" instead of just "polar".
> 
> 
> Still, how do you get the rule writer to understand "acme-hr"?
> 
> 
>>(unless you want to enforce the use of these @#$%^& x500 style names ;-)
> 
> 
> No, I don't, but somewhere you have to make a descision to say that
> "CN=The Human Resources Department, OU=Human Resources, O=ACME, C=US"
> equals "acme-hr". Where do you do that?
> 
> That translation will have to be put somewhere. And it will probably be
> specific to the organziations involved and their particular structures.
> For instance, why wouldn't it be "acme's hr"?


I'm afraid that there may be a big misunderstanding here.

"acme-hr" is a local name used in the spki/sdsi sense to facilitate the 
adminstration of rules by warm bodies.

The rule-writer would use that name in its policy expressions because that name 
makes sense to him/her.

So there should be an additional attribute assertion that binds the name 
"acme-hr" to the bare key used by ACME's HR assertion authority asserted by self.

Or using one level of indirection, a local naming authority could bind acme-hr 
as the prefered name to ACME's HR's key, which should be used in all policy 
rules to standardize name usage.

But you bring up a good point as even if an x500 style name is presented in an 
authenticated certificate, the local administrators may not want to use that 
"unwieldy" x500 name in their authorization policy expressions, but instead use 
the names in their HR/customer records that make more sense to them, i.e. local 
names. You may then need a federation/mapping authority, like you outlined, and 
somehow state that mappings of this authority can be considered to resolve the 
names used in the policy expression...


-Frank.



> I'd rather not see the unwieldy obtuse logic for this in XACML. It is a
> mapping function that can change with weather.  Of course, we can invent a
> formal language or logic for these mappings and invent an IdentityMapper
> function specifying the semantics of the mapping.
> 
> It maybe that in XACML (in order to keep things interoperable) specify the
> semantics identitfier with the issuer name, so that when you are
> specifying names, you use the correct mapping.
> 
> Let's say using "sdsi" could explain a standard translation such as
> "sdsi:polar!tim". Or company/application specific where "adiron" defines
> that the kerberos users at
> 	alice1@sys1.adiron.com,
> 	alice342@sys2.adiron.com,
> 	consultant2@client.org
> 
> are simultaneously defined as "adiron:alice".
> 
> But even then, specifying the "semantics identifier" gets you into
> interoperability problems.
> 
> -Polar
> 
> 
> 
>>Regards, Frank.
>>
>>
>>
>>
>>>On Thu, 11 Sep 2003, Frank Siebenlist wrote:
>>>
>>>
>>>
>>>>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
>>
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
> 

-- 
Frank Siebenlist              franks@mcs.anl.gov
The Globus Project - Argonne National Laboratory