RE: [security-services] DDDS RFCs, Liberty and SAML Metadata exchange protocol

["Jahan Moreh" <jmoreh@sigaba.com>]

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