[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-globus] The LDAP URL Format
Sam X. Sun wrote:
> Yes, this is the RFC that I referred to. I agree with the mapping you
> suggested. It's a good way to get rid of those "loose" characters...
>
> To clearify my understanding, this method maps each URI/DN into a
> handle suffix. The prefix of the handle is a pre-determined one homed
> at the handle server (e.g. 12.34). If the SAML message is sent to
> another handle server (with a different prefix), those SAML attributes
> will map to different handles under a different prefix assigned to the
> other handle server.
Correct.
It should be a configuration of the SAML AA to what NA its subject names
are mapped.
> I think the mapping should work for our purpose, where AA will know
> which handle prefix to use. On the other hand, Itmight help to point
> out that this is not a general mapping between the URI/DN and handle
> as I originally thought. Instead, this is a mapping from URI/DN to
> handles under a specific handle prefix.
Initially, I was looking for a single way to map those unique
identifiers, like DNs, into a single way into the handle name space. You
could maybe/probably find a scheme to do that by dedicating a single NA
to map certain URI schemas in.
However, we're not issuing the URIs as they already exist, but merely
binding attributes to those names.
Now, theoretically anyone in the world could potentially bind any
attribute to any unique name, and it becomes an issue that you only will
be interested in certain authorities to do that. It this case, a handle
system Naming Authority is not so much a keeper of the name, but a
keeper of certain name bindings that have a trust and application domain
as indicated by that NA.
I'm still struggling to find the right mental model here...
> I'm still not clear on how to map attribute-<name, value> into
> handle-<type, values>. It seems straightforward if the attribute-value
> can be determined by a simple attribute-type. But the simple mapping
> doesn't seem to be able to capture compound-attribute type such as:
> <saml:NameIdentifier
>
> Format="urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName"
> NameQualifier=http://uchicago.edu/gridshib/idp> ....
> </saml:NameIdentifier>where the attribute-type contains multiple URIs;
> or attributed-<type, value> pair under nested context, such as:
>
> <samlp:AttributeQuery>
> <saml:Subject>
> <samlp:AttributeQuery>
> <saml:NameIdentifier...>
> attribute-value...
> </saml:NameIdentifier...>
> </samlp:AttributeQuery>
> </saml:Subject>
> </saml:NameIdentifier>
>
> where the surrrounding context may play a role to determine the
> <saml:NameIdentifier..., attribute-value> pair.
>
>
> Are these something that we need to worry about?
I'm not sure if I understand your example... could you maybe make it a
little more specific?
-Frank.
> ----- Original Message ----- From: "Frank Siebenlist"
> <franks@mcs.anl.gov>
> To: <handle-globus@cnri.reston.va.us>
> Sent: Friday, June 24, 2005 3:06 AM
> Subject: [Handle-globus] The LDAP URL Format
>
>
>> The LDAP URL Format
>> http://www.faqs.org/rfcs/rfc2255.html
>>
>> Maybe this was what Sam was referring to (?).
>>
>> I've attached the "example" section of the RFC.
>>
>> Maybe we should use the following convention for X509 Subject DNs:
>> "12.34/uri:ldap:///cn=john%20doe,o=University%20of%20Michigan,c=US";
>>
>> In other words, reserve a handle prefix of "12.34/uri:" for URI-like
>> names, and use the URI-form "ldap:///"; prefix for the DN part...
>> (pls help me check whether that is the right format for URIs)
>>
>> Furthermore, I think we should try to use URIs for as many identifiers
>> as we can, including xml-element identifiers and such (so no "loose"
>> QNames...).
>>
>> -Frank.
>>
>> ------------
>>
>> 6. Examples
>>
>> The following are some example LDAP URLs using the format defined
>> above. The first example is an LDAP URL referring to the University
>> of Michigan entry, available from an LDAP server of the client's
>> choosing:
>>
>> ldap:///o=University%20of%20Michigan,c=US
>>
>> The next example is an LDAP URL referring to the University of
>> Michigan entry in a particular ldap server:
>>
>> ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
>>
>> Both of these URLs correspond to a base object search of the
>> "o=University of Michigan, c=US" entry using a filter of
>> "(objectclass=*)", requesting all attributes.
>>
>> The next example is an LDAP URL referring to only the postalAddress
>> attribute of the University of Michigan entry:
>>
>> ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,
>> c=US?postalAddress
>>
>> The corresponding LDAP search operation is the same as in the
>> previous example, except that only the postalAddress attribute is
>> requested.
>>
>> The next example is an LDAP URL referring to the set of entries found
>> by querying the given LDAP server on port 6666 and doing a subtree
>> search of the University of Michigan for any entry with a common name
>> of "Babs Jensen", retrieving all attributes:
>>
>> ldap://host.com:6666/o=University%20of%20Michigan,
>> c=US??sub?(cn=Babs%20Jensen)
>>
>> The next example is an LDAP URL referring to all children of the c=GB
>> entry:
>>
>> ldap://ldap.itd.umich.edu/c=GB?objectClass?one
>>
>> The objectClass attribute is requested to be returned along with the
>> entries, and the default filter of "(objectclass=*)" is used.
>>
>> The next example is an LDAP URL to retrieve the mail attribute for
>> the LDAP entry named "o=Question?,c=US" is given below, illustrating
>> the use of the escaping mechanism on the reserved character '?'.
>>
>> ldap://ldap.question.com/o=Question%3f,c=US?mail
>>
>> The next example illustrates the interaction between LDAP and URL
>> quoting mechanisms.
>>
>> ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)
>>
>> The filter in this example uses the LDAP escaping mechanism of \ to
>> encode three zero or null bytes in the value. In LDAP, the filter
>> would be written as (int=\00\00\00\04). Because the \ character must
>> be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
>>
>> The final example shows the use of the bindname extension to specify
>> the dn a client should use for authentication when resolving the URL.
>>
>> ldap:///??sub??bindname=cn=Manager%2co=Foo
>> ldap:///??sub??!bindname=cn=Manager%2co=Foo
>>
>> The two URLs are the same, except that the second one marks the
>> bindname extension as critical. Notice the use of the % encoding
>> method to encode the comma in the distinguished name value in the
>>
>> bindname extension.
>>
>> --
>> Frank Siebenlist franks@mcs.anl.gov
>> The Globus Alliance - Argonne National Laboratory
>>
>>
>> _______________________________________________
>> Handle-globus mailing list
>> Handle-globus@cnri.reston.va.us
>> http://www.cnri.reston.va.us/mailman/listinfo/handle-globus
>
>
>
> _______________________________________________
> Handle-globus mailing list
> Handle-globus@cnri.reston.va.us
> http://www.cnri.reston.va.us/mailman/listinfo/handle-globus
>
--
Frank Siebenlist franks@mcs.anl.gov
The Globus Alliance - Argonne National Laboratory
_______________________________________________
Handle-globus mailing list
Handle-globus@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-globus