{"id":932,"date":"2008-02-27T21:25:17","date_gmt":"2008-02-28T05:25:17","guid":{"rendered":"\/?p=932"},"modified":"2008-02-27T21:25:17","modified_gmt":"2008-02-28T05:25:17","slug":"handbags-at-dawn","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=932","title":{"rendered":"Handbags at dawn?"},"content":{"rendered":"<p>Here is <a href=\"http:\/\/blogs.sun.com\/superpat\/\" class=\"broken_link\">Pat Patterson&#39;s\u00a0post<\/a> on my recent discussion with Ben Laurie.\u00a0\u00a0 Pat\u00a0is a widely respected member of\u00a0Sun&#39;s identity team, blogs at <a href=\"http:\/\/blogs.sun.com\/superpat\/\" class=\"broken_link\">Superpatterns<\/a>, and runs the useful\u00a0<a href=\"http:\/\/planetidentity.org\/\">PlanetIdentity<\/a>\u00a0RSS feed.\u00a0\u00a0 There are a number of ways you could build a Password Manager for CardSpace, but I thought readers would enjoy seeing Pat&#39;s\u00a0take on\u00a0it:<\/p>\n<blockquote><p>You might have noticed the exchange between <a href=\"http:\/\/www.links.org\/\">Ben<\/a> and <a href=\"https:\/\/www.identityblog.com\/\">Kim<\/a> over the past day or two&#8230; Ben made a point that <a href=\"http:\/\/www.links.org\/?p=297\">CardSpace makes OpenID redundant<\/a> &#8211; why not just send a password to the RP? <a href=\"\/?p=924\">Kim jumped all over him<\/a> &#8211; somewhat misinterpreting what Ben later describes as <a href=\"http:\/\/www.links.org\/?p=298\">one of my most diabolical hungover bits of prose ever<\/a>. Ben goes on to clarify that maybe CardSpace can have a role in helping the user manage passwords; <a href=\"\/?p=928\">Kim says &#8220;Hmm&#8230; Food for thought&#8221;<\/a> (okay, I&#39;m paraphrasing); Ben <a href=\"http:\/\/www.links.org\/?p=299\">admits he didn&#39;t explain himself too clearly to begin with<\/a>; and, glory be, they&#39;re <a href=\"\/?p=929\">violently agreeing<\/a>. Phew! I thought we were going to be seeing <a href=\"http:\/\/en.wiktionary.org\/wiki\/handbags_at_dawn\">handbags at dawn<\/a>&#8230; <img src=\"http:\/\/blogs.sun.com\/images\/smileys\/smile.gif\" \/><\/p>\n<p>Reading all this lit a spark in my mind of how this could work. The crux is to consider the username\/password token, usually sent as one of a set of possible <em>input<\/em> tokens to an identity provider security token service (IP\/STS), as an <em>output<\/em> token.<\/p>\n<p>Here&#39;s how it would work&#8230; Borrowing a diagram from Microsoft&#39;s <a href=\"http:\/\/msdn2.microsoft.com\/en-us\/library\/bb298803.aspx\">Guide to Interoperating with the Information Card Profile V1.0<\/a>:<\/p>\n<p><img src=\"\/wp-content\/images\/2008\/02\/patflow.gif\" \/><\/p>\n<p>First of all, the IP\/STS would specify <strong>ic:RequireAppliesTo<\/strong> in the managed card. This tells the identity selector to include a <strong>wsp:AppliesTo<\/strong> element in the <strong>wst:RequestSecurityToken<\/strong> (RST). The IP\/STS is going to need this later&#8230;<\/p>\n<p>Now, the user visits the relying party (RP) in step 1, requesting some resource. In step 2, the &#8216;service requestor&#8217; (application client with identity selector) requests security policy from the RP. The RP would indicate, in step 3, that it wanted a username\/password token by specifying a token type of <strong>http:\/\/docs.oasis-open.org\/wss\/2004\/01\/oasis-200401-wss-username-token-profile-1.0<\/strong> in the policy.<\/p>\n<p>Now the identity selector presents some set of information cards (hopefully just one) to the user (step 5) and the user selects one (step 6). Steps 7 and 8 would see the RP requesting security policy from the IP\/STS, and the IP\/STS supplying it, exactly as in the standard information card interaction. Here the IP\/STS could require any form of input token, but username\/password is most likely.<\/p>\n<p>Between steps 8 and 9, the identity selector prompts the user for credentials (bad Microsoft, missing that out of the diagram!) and in step 8, the identity selector packages up the user&#39;s credentials in a WS-Trust RST and send them to the IP\/STS.<\/p>\n<p>Now, here&#39;s the interesting bit. The IP\/STS authenticates the user, exactly as in the standard CardSpace case, but now it looks at the <strong>wsp:AppliesTo<\/strong> element, and looks up the user&#39;s username\/password pair for that RP (this is an implementation detail &#8211; there could be a mapping of RP identifiers to username\/password pairs per user, all encrypted on disk, of course). The IP\/STS packages them as a <strong>wsse:UsernameToken<\/strong>, which is then encrypted with the RP&#39;s public key and returned to the identity selector (step 10). The display token could just show ******** for the value of the password claim. Now we have a nice, securely packaged credential that the identity selector can send to the RP in step 11.<\/p>\n<p>Here&#39;s the other nice bit&#8230; All the RP has to do is to decrypt the incoming token and it has the user&#39;s username and password, exactly as if they had arrived by a conventional form post. No further customization required at the RP &#8211; no changes to directory or database schemas, no extra steps of associating an information card with your account. Passwords on steroids.<\/p><\/blockquote>\n<p>If the\u00a0RP uses https, I&#39;m not even sure there is any need to decrypt at the token layer, which simplifies implementation to\u00a0decoding a simple xml structure.\u00a0 RP&#39;s who are looking for\u00a0greated levels of security should switch to public key.<\/p>\n<p>I&#39;d like to\u00a0hear Pat&#39;s ideas about\u00a0the user experience of\u00a0bootstrapping the passwords into the Identity Provider.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>No further customization required at the RP &#8211; no changes to directory or database schemas, no extra steps of associating an information card with your account. Passwords on steroids.<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[15,11,5,4],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/932"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=932"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/932\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=932"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=932"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=932"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}