November 4th, 2008

There’s a new revision of the SIP-SAML profile spec..

SIP SAML Profile and Binding
http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-05.txt

The key changes in this revision are that we’re aiming for experimental track (for now) due to a subtle-but-important impedance mismatch with the “SIP Identity” spec (RFC 4474, which we build upon), and we’ve add an additional profile to the spec. This new profile simply specifies SAML assertion conveyance “by value” in the body of SIP message(s) rather than “by reference”.

Note that the overall notion of “SIP Identity” has been in-flux over the last year+. Once that set of issues is (hopefully) resolved, then we can do another SIP-SAML spec on the standards track.

Also, the SIP WG co-chairs have called for Working Group Last Call on this -05 revision.

=JeffH sez getcher comments in!

Average Rating: 4.7 out of 5 based on 249 user reviews.

October 22nd, 2008

I found the existing protocol flow diagram in the current OAuth spec..

OAuth Core 1.0
http://oauth.net/core/1.0/

..somewhat hard to follow. So I concocted three separate new ones using the so-called “swimlane” technique that I’m used to.

I posted these to the OAuth list a while back, and a few folks reposted them to their blogs, but no one has yet piped up to say I got anything wrong. But YMMV, there might be bugs in here.

FWIW, I’ve posted them below in case others find them useful. Also, I have them in a single file..

http://identitymeme.org/doc/draft-hodges-oauth-05-figures.txt

..also featuring OpenID and SAML Web Browser SSO Profile diagrams for comparison purposes. Note that in all things protocol, definitions of terms are essential in order to be able to effectively communicate and reason about protocols, so I’ve included key definitions from the OAuth spec in the file.

NOTE: fixed-pitch font required for viewing. Also, wordpress is obviously messing up the diagrams below, and they consequently look sorta lame, here on the blog. This site presently uses an old wordpress install, maybe this will help motivate me to upgrade it. In the meantime, check out the file linked-to above for the best viewing experience πŸ˜‰

Fig 1: out-of-band consumer setup/config

                                           photos.example.net
                                             +----------+
                                             |          |
                                             | OAuth    |
                                             | service  |
                  printer.example.com        | provider |
                      +---------+            |          |
                      |developer|            |  Sys     |
                      |   of    |            |  Admin   |
                      | OAuth   |            |          |
                      |consumer |            |          |
                      |         |            |   [SP]   |
                      +----+----+            +----+-----+
                           |                      | 
                           | obtain Consumer Key  |
                           | and Consumer Secret  |
                           | [details unspec'd,    |
                           |  performed out-of-   |
                           |  band.]              |
                           |--------------------->| 
                           |< ---------------------|
                           |                      | 
                           |                      |

Fig 2: "Web-based consumer"

The "consumer" is a website or other application that accesses 
the Service Provider on behalf of the wielder (user) of the user agent 
(UA is typically a browser,  but could be some other app).  

Steps 1.n.   "Obtain Unauthorized Request Token"
      2.n.   "User Authorizes Request Token"
      3.n.   "Exchange Request Token for Access token"
      4.n.   UA accessing protected resources at SP
      
      

                                           photos.example.net
                                             +----------+
                                             |          |
                                             | OAuth    |
                   printer.example.com       | Service  |
                       +--------+            | Provider |
                       |        |            |          |
                       | OAuth  |            |[protected|
                       |Consumer|            |resources]|
 +----+                |        |            |          |
 | UA |                |  [RP]  |            |   [SP]   |
 +-+--+                +---+----+            +----+-----+
   |                       |                      |
   | 1.0.  User Agent inter-|                      |
   | acts with Consumer    |                      |
   | site [optional]       |                      |
   |< --------------------->|                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 1.1.  UA informs/directs                      |
   | Consumer to do something                     |
   | with a resource (e.g.  |                      |
   | a photo) at SP        |                      |
   |---------------------->|                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       | 1.2.  Consumer attempts
   |                       | accessing photo at SP|
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       | 1.3.  SP replies with |
   |                       | a HTTP 401 containing|
   |                       | a "OAuth" www-authn  |
   |                       | header field         |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       | 1.4.  Consumer replies|
   |                       | with a request for   |
   |                       | "unauthorized Request|
   |                       | Token" (uRT) via POST|
   |                       | to SP's "request token
   |                       | URL"                 |
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       | 1.5.  SP issues uRT & |
   |                       | token secret to      |
   |                       | Consumer.             |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.0.  Consumer redirects                      |
   | UA to SP "User Author-|                      |
   | ization URL" including|                      |
   | the uRT.               |                      |
 +<- - - - - - - - - - - - |                      |
 .  | (indirected via UA)   |                      |
 .  |                       |                      |
 +-------------------------+--------------------->|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.2.  User authenticates with the Service     |
   | Provider (optional,  methods vary,  realization|
   | is out of scope)                             |
   |< ============================================>|
   | 2.3.  User grants or declines permission      |
   | for the Service Provider allow Consumer      |
   | access to the resource (e.g.  photo).          |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |                      |
   | 2.4.  If permision granted,  UA redirected back|
   | to Consumer's "Callback URL",  conveying the  |
   | uRT.                   |                      |
 +< - - - - - - - - - - - - - - - - - - - - - - - -|
 .  | (indirected via UA)   |                      |
 .  |                       |                      |
 .  |                       |                      |
 +------------------------>|                      |
   |                       |                      |
   |                       |                      |
   |                       |3.0.  Consumer requests|
   |                       |Access token,  supplies|
   |                       |uRT.                   |
   |                       |--------------------->|
   |                       |                      |
   |                       |                      |
   |                       |                      |
   |                       |3.1.  SP grants Access |
   |                       | Token.                |
   |                       |< ---------------------|
   |                       |                      |
   |                       |                      |
   |                       |4.x.  Consumer uses the|
   |                       |Access Token,  Access  |
   |                       |Token Secret,  Consumer|
   |                       |Key,  and Consumer Secret
   |                       |to make authenticated |
   |                       |request(s) to the Service
   |                       |Provider.              |
   |                       |=====================>|
   |                       |           .           |
   |                       |           .           |
   |                       |           .           |
   |                       |                      |



Fig 3: “desktop-based consumer”


this is case where user is wielding some app that is both a UA and a Consumer.


                                             +----------+
                                             |          |
                                             | OAuth    |
                                             | service  |
 +--------+                                  | provider |
 |        |                                  |          |
 |Desktop-|                                  |[protected|
 |based   |                                  |resources]|
 |Consumer|                                  |          |
 |        |                                  |          |
 | UA     |                                  |   [SP]   |
 +-+------+                                  +----+-----+
   |                                              |
   | 1.  Consumer requests "unauthorized Request   |
   | Token (uRT)" with POST to SP's "request token"
   | URL.                                          |
   |--------------------------------------------->|
   |                                              |
   |                                              |
   | 1.1.  SP issues uRT and Token Secret to       |
   | consumer.                                     |
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 1.2.  User authenticates with the Service     |
   | Provider (optional,  methods vary,  realization|
   | is out of scope)                             |
   |<============================================>|
   | 3.  User grants or declines permission        |
   | for the Service Provider to issue Access     |
   | Token.                                        |
   |                                              |
   |                                              |
   |                                              |
   |                                              |
   | 4.  Service Provider authorizes the uRT to be |
   | exchanged for an Access Token and secret.     |
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 5.  Consumer exchanges the uRT and secret     |
   | for an Access Token and Secret.               |
   |--------------------------------------------->|
   |< ---------------------------------------------|
   |                                              |
   |                                              |
   |                                              |
   | 6.  Consumer uses the Access Token,  Access    |
   | Secret,  Consumer Key,  and Consumer Secret    |
   | to make authenticated request(s) to the Service
   | Provider                                     |
   |<============================================>|
   |                      .                        |
   |                      .                        |
   |                      .                        |
   |                      .                        |
   |                      .                        |
   |                      .                        |
   |                                              |

Average Rating: 4.7 out of 5 based on 246 user reviews.

March 10th, 2008

I just ran across this group at Last.fm..

Stats

..it’s denizens post articles about and pointers to cool little gizmos/widgets/whathaveyous that one can use to leverage Last.fm data.

I ran across it via this person’s profile..

Anthony Liekens

..he has a personal website where he offers..

Data mining musical profiles
Anthony Liekens, March, 28-April, 2 2007

..that article, and a web interface to his various tools.
.
=JeffH sez check it out πŸ˜‰

[update] ps: note that sites such as last.fm have relevance to the more general notion of identity in that publishing the music one listens to is an aspect of one’s identity.

Average Rating: 4.9 out of 5 based on 259 user reviews.

January 30th, 2008

I’m blogging about my personal computing environment over on my “personal” blog, and just posted a note about my recent migration from MS Windows XP to (K)ubuntu GNU/Linux. Here’s a pointer to it..

I Done Left Los WindowsÒ€¦
http://kingsmountain.com/blog/archives/2008/01/30/i-done-left-los-windows/

=JeffH

Average Rating: 4.7 out of 5 based on 193 user reviews.

January 21st, 2008

Eve (aka xmlgrrl) posted the following bit of musing today..

Circles of trust: disaster? or really bad idea?
http://www.xmlgrrl.com/blog/archives/2008/01/21/circles-of-trust-disaster-or-really-bad-idea/

..which I tend to think hits the proverbial nail pretty squarely on the head wrt “open internet”, “trust all comers”, and “trust circles”.

One very small, detail-level comment I have on her post is that where she writes..

(where users are okay with this sort of back-channel communication)

..I would instead make it explicitly clear that “users” sometimes don’t have any direct say with respect to the machinations of the IT department on their behalf. Hence I would write it as..

(where users are okay with this sort of back-channel communication, or where they don’t have any say (e.g. in an enterprise deployment))

Note I don’t feel that the latter is necessarily a good thing, but it’s reality in corporate, governmental, and education worlds (at least), and no amount of attesting that “I want to own my identity data!” is going to change it any time soon (admittedly unfortunately). Besides one’s identity, outside of one’s own thoughts, “..is a story“, as Bob Blakley noted a while back, but has been understood for quite a while by social scientists and philosophers (see, for example, Erving Goffman).

But I digress… πŸ˜‰

Average Rating: 4.9 out of 5 based on 153 user reviews.

January 21st, 2008

I’ve done a modest editorial and copy editing update to the OpenID SAML technical comparison document announced earlier. Going forward, the latest rev will be available via this URL:

http://identitymeme.org/doc/draft-hodges-saml-openid-compare.html

Average Rating: 4.8 out of 5 based on 283 user reviews.

December 18th, 2007

It looks like this new SAML wiki..

SAML.XML.org

..opened for business on or about the middle of October 2007. Looks like it’ll be a good resource for the wide SAML community.

There’s also another wiki that’s apparently for the members of the OASIS Security Services Technical Committee (SSTC – the group creating and shepherding the SAML specs)..

SSTC Wiki

..so it looks like we’ll have to be careful to figure out what sort of content goes where.

Average Rating: 4.4 out of 5 based on 212 user reviews.

December 18th, 2007

This page..

SAML Open Source Implemenations

..lists eight (at this time) open source SAML implementations of one flavor or another. If you have one and it isn’t listed there as yet, create an account and edit the wiki page appropriately πŸ˜‰

Average Rating: 4.9 out of 5 based on 280 user reviews.

December 17th, 2007

Over the past couple of years quite a few folks have asked me, and I’m sure others, “what’s the salient differences between OpenID and SAML?” So earlier this year I began hacking together a technical comparison of the two. It’s an interesting exercise comparing two Web SSO protocols, even one as ostensibly simple, and straightforwardly specified, as OpenID. It turns out to be a fairly complex task given all the different facets inherent in authentication protocols in general, and in web-, i.e. HTTP-based, protocols (and profiles thereof) in particular. And also given the various audiences affected by such protocols: implementors, deployers, end users, and protocol designers.

The resultant comparison paper, “Technical Comparison: OpenID and SAML – Draft 05” seems to me to be at a stage where it can be shared widely (i.e. on the web πŸ™‚ ), here it is..

http://identitymeme.org/doc/draft-hodges-saml-openid-compare-05.html

..For many readers, sections 1, 2, and perhaps 3 ought to cover things. For those necessarily interested in gory, really geeky details, parts or all of section 4 will be of interest. Note that this is still a “draft“–there are various items, especially in section 4, that are not as yet evaluated as thoroughly as I’d like, or at all (as yet).

I’ve tried as much as possible to provide an objective comparison. It’s admittedly difficult given I’ve been intimately involved in SAML’s gestation since essentially the very beginning. It’s also a technically difficult comparison because of the differing design centers of OpenID and SAML, as well as differing specification styles, and thus the difficulty in presenting the comparison to the reader, not to mention attempting to be “balanced“.

So, I hope this paper will prove at least somewhat enlightening and useful to the multifaceted “identity” community out there, and to those shepherding websites who are wondering what these two oft-mentioned beasts are, how’re they’re different/similar/alike, and also nominally how they work.

=JeffH sez check it out.

Average Rating: 5 out of 5 based on 227 user reviews.

September 21st, 2007

I’ve updated the SAML-lSSO and SAML OpenID Profile specs just to bring them up-to-date with the latest revisions of various SAML and OpenID specs and to fix minor editorial issues. The SAML-lSSO spec is presently not a current IETF Internet-Draft — it’s prior version expired a few months ago. We’re thinking about whether we want to pursue that spec “officially” or not. The issue with it being that in implementing it, one can optionally turn security completely off — which is a “feature” various folks advocating for so-called “open Internet” identity management desire. But SDOs such as IETF, OASIS, W3C, Liberty Alliance, etc all would look askance at blessing such a spec. In fact the IETF definitely would not allow it to go forward in that they have an explicit policy against promulgating insecure protocols.

The SAML OpenID Profile is a simple hack I threw together a year or so ago (in a single afternoon) to prove the point that there’s nothing OpenID accomplishes protocol- and user-experience-wise that is inherently un-do-able with SAML. [1]

Anyway, here’s the links to said specs…

SAMLv2 Lightweight Web Browser SSO Profile

OpenID-SAML Lightweight Web Browser SSO Profile – Draft 02

=JeffH sez check ’em out.

[1] Note that I’m not claiming that they are equivalently “easy” to implement. By “implement” I mean to write code implementing the protocol on both or either the Relying Party or Identity Provider (aka OpenID Provider) side. Also note that I don’t use the term “implemneting” as a synonym for “deployment”. Also, I am not claiming that they are equivalently “easy” to deploy. Almost all the artifacts of deployment are inherent in how a protocol is implemented. A “feature” that’s often claimed about OpenID as a differentiator is that anyone with a minimally capable hosting environment can field an OpenID relying party. I.e. they don’t need root access, nor access to their webserver configuration, etc. In fact, the same is true with some (all?) of the “scripty” SAML implementations, e.g. ZXID being a case in point.

Average Rating: 4.9 out of 5 based on 280 user reviews.