[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Handle-globus] The LDAP URL Format



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.

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.

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?



-Sam




----- 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