Being more of a pure C# backend kind of guy, I’ve had to integrate with another SAML system recently. I’ve actually never worked with SAML, so I dug into the spec and did the standard Googling.
As is not uncommon, I ended up on a wild goose chase of hyperlinks, after trying to find out what this meant:
It’s tucked inside standard SAML nodes (which is built on top of XML). I figured I’d share with you what this whole “urn” moniker is all about.
All developers know what a URL is. Most would call it a hyperlink or “web link” of some sort. You’d be half right. It stands for Uniform Resource Locator – and technically, it’s a subset of a URI – Uniform Resource Identifier. A URI fits the following pattern (see RFC 3986):
(grabbed from Wikipedia)
So our standardized definition would be “A compact sequence of characters that identifies an abstract or physical resource.” The “physical or abstract” part is important – the target resource could be a physical file, or could return a representation of a logical piece of data. Remember, to good .Net developers , XML and JSON are merely the representations of our objects – they are the means, not the ends.
So, a URL is a type of URI – specifically a URI that is located over a network. A URL could be any of these:
The first section is our network protocol (referenced as scheme), followed by host, port, path, and query fragments.
Being a visual person, the image made much more sense than delving through a spec somewhere trying to make sense of all the terminology.
I’ve always viewed the URI class in dot net as not adding much value – but after better understanding the URI structure, I have a whole new appreciation for it! Take a look at these:
Uri ftpUrl = new Uri("ftp://ftp.funet.fi/pub/standards/RFC/rfc959.txt"); Uri ldapUrl = new Uri("ldap://[2001:db8::7]/c=GB?objectClass?one");
Yields some pretty useful information automatically, without tedious parsing!
A URL is a type of URI, and, as it turns out, a URN is a type of URI! Uniform Resource Name is still a type of identifier, just intended to identify a hierarchical namespaces.
For example: urn:isbn:0451450523
A URN is still supposed to be a unique identifier, so the above line implies that the ISBN number refers to one book, and one book only. So when it came to define the SAML protocol in a SAML message itself, it made sense to use an accepted standard instead of something custom. OASIS can manage its own naming schema and convention under the “urn:OASIS” namespace.
As an aside, if you’re in web development, don’t go using Uri for parsing and doing tricky things with query strings. It wasn’t designed for that, and you’d be using the wrong tool for the job.
To get a little more “spec-y” – a resolution request can be made for any URN (of which these examples are) – but a URN resolver is responsible for taking that URN and translating it into a URL, or the resolvable location of that identifier. This is somewhat abstract – but it’s quite simple really – a DNS server takes the URN of “https://app.pluralsight.com/library/” and resolves a physical network location to serve up that resource. Subsequently, the web server accepts that URL and serves up the resource representation. This is, in effect, a form of decoupling, which I find rather interesting.
It seems as if the deeper you get into web development, the farther back in time you end up. Indeed, this holds true for our industry as a whole. REST API’s are my current specialty, and seeing so much similarity in terminology (“identifiers of resources”, “actions upon those resources”, “resource representations”) fascinated me when I first saw this. It served to reinforce my commitment to the future of REST – as opposed to something new, custom and non-uniform. REST is how the internet works – it makes sense to develop web services which minimize the deviation from natural HTTP constraints (ASP.Net session state is one such example – phenomenal idea when it came out – now pretty much everyone regrets it). I’ll be blogging about REST alot, but if you need another hyperlink to continue on your stream of curiosity, check out Roy Fielding’s work – any REST tutorial will reference him.