Colleagues -
I had promised to read
up on DDDS RFCs (3401-3405) and summarize my understanding of these RFCs as they
relate to Liberty metadata discovery protocol. This would allow me to
formulate a proposal on SAML 2.0 metadata discovery protocol (Work item W3 and
Action Item 0064). Below is a summary. It is by no means a complete
illustration of DDDS (not even close). I welcome questions, comments
and corrections, especially from Peter Davis, who is the editor of Liberty
metadata specs.
Thanks,
Jahan
Liberty metadata
discovery envisions two methods for "providers" to discover metadata about each
other. As I am sure most people know, Service Providers are roughly equivalent
to SAML assertion consumers and Identity Providers are roughly equivalent to
SAML assertion producers.
The first method is
fairly straightforward. Basically, each provider must have a providerID. A
providerID is a URI and is used to uniquely identify each provider. We already
have this concept in our draft metadata specification. So, this first method
states that the URI is essentially a URL that can be directly dereferenced to
get the provider's metadata. This is a simple method and should work in many
situations. It also has a benefit (as John Linn has stated) in that it does not
require provisioning the network infrastructure (as would be the case with
DDDS).
The second method
uses DNS to publish metadata locations. In a nutshell, using existing DNS
protocols and discovery methods, one can determine the location of the
provider's metadata. DDDS defines a specific DNS resource record
called Naming Authority Pointer (NAPTR) resource record (see RFC 2195 for
details). A NAPTR record specifies a regular expression for what is called
re-writing rules. A simple example follows.
Assume a providerID URI
of http://sigaba.com/saml/consumer/cs.
We can have a regular expression and replacement string
like:
!^([^:/?#]+:)?/*([^:/?#]*@)?(([^/?:#]*\.)*(([^/?#:\.]+)\.([^/?#:\.]+)))(:\d+)?([^?#]*)(\?[^#]*)?(#.*)?$!\3!
Basically, this expression extracts
the FQDN (i.e., sigaba.com), which is "subexpression" #3. The FQDN is used as
the "replacement" string. Next, the requestor performs a DNS NAPTR query to the
domain sigaba.com. It may get back something like
this:
!^.*$!https://sigaba.com/metadata/cs/consumer.xml!
Basically, the
above says "replace your data with https://sigaba.com/metadata/cs/consumer.xml". DDDS and NAPTR provide
a way to tell the requestor if the replacement string is "terminal" or not. This
is accomplished using a flag (not shown in the
examples).
DDDS
has a specific initial regular expression for parsing URNs (see RFC 3403), which
Liberty has adopted. Also, RFC 2535 (DNS Security Extensions) along with SSL/TLS
are recommended for ensuring integrity of DNS records as well as that of the
final metadata document.
I
invite questions, comments, and certainly corrections. The examples above are
intentionally incomplete so that I could express the essence of what is
involved. In actual implementation, NAPTR records have orders, preferences,
flags, and service fields that help the requestor resolve exactly what service
and what location holds the metadata.
Thanks,
Jahan
----------------
Jahan Moreh
Chief Security
Architect
310.286.3070
