[OpenID] [Muscle] updated experience, 2 years later.

Sun Mar 9 11:35:18 UTC 2008

Long-winded end-user-requirements focused architecture discussion concerning openid, generally. 

Blacklist the thread now, folks, if the topic OR the writing style is objectionable. 

---------------

The interesting (but slightly off topic) question is. Does https://rapattoni.trustbearer.com/ support https? The fast answer is no - sort of by design - as https and PKI always end up getting in the way of adoption (once you step out of the VeriSign management domain)!

1. rapattoni.trustbearer.com is a lab experiment in composite OP architecture. Today, https may well work with the front end protocol engine (at trustbearer labs) who (Im guessing) use the common-and-garden openssl libraries. 

2. But being a composite OP, we have to also consider its backend SAML2 websso/nameid protocol server - which is probably not configured for public-trust https (since typically I rely on SAML's reader-to-writer signature/encryption mechanisms, rather than channel security, for secure websso). Is that server operating on IIS5.1?  No. Its a jboss/jetty server, ultimately, and the SSL will come from java standard libraries. 

3. That demo server is not using the HSM array, for SSL crypto offloading.  And, I dont believe we specified that the gateway's openid/SAML2 handoff should use https, either, as its SAML2-nameid protocol is not set to provision https openids! 

4 However, we have to consider that the SAML handshake in the multi-stage, composite OP has its own backend web services...screens for doing simple user auth - which are hosted on IIS with both public (aka VeriSign ) and private PKI trust domains. Its probably IIS 6.patch.

So that really was longwinded! The answer is: I dont know, since 4 or 5 different SSL platforms (including the F5 and Zeus loadbalancers at the cluster) are involved. I'm still finding out about openid and what https specifically means in openid, really. In SAML websso the topic is easy handled, by contrast. Sign the metadata used in discovery (including the key distribution for PRMD PKI domains), and sign the requests/responses and/or assertions. You dont need to worry about https and http semantics: its all end-end and uses an OOB control system (or use public/VeriSign trust when relying on security-critical metadata "automatically")

-------
https and SAML gatewaying aside, the ultimate goal of that site is to explore a topic mentioned almost incidentally by Sxip folks a while ago. What happens when an OP returns to a consumer a claimed id that is not identical with that in the id_req (other than the Directed ID case made famous by Yahoo!)? The answer was: the discovery process starts up again at a careful consumer site.  (Its what in 20-year old X.500 one would have called this a secure UA referral to a naming context known by secure inband-metadata to be mastered at a different agent's access-point.)

So, Peter now speaking, what user-induced discovery introduced as a claimed-id (from untrustworthy http or semi-trustworthy https land based on UCI-managed metadata in some HTML file) may become an asserted claimed-id by a trusted OP, over the openid auth association's HMAC. This, by its distinctive form, SHOULD cause the id_res to be considered a "second order" discovery server. Being an OP, it will probably offer more identity managemt facilities than the blogging site's webserver serving the initial HTML file with RDFa - and openid's older - metadata tags. 

So - to the point Peter! - whereas SAML has a formal IDP proxing model based on message exchange patterns that uses the chaining model, Openid can let you do the UA hop from one OP to another OP along a chain of asserting/discovering parties, once the id_res messages' claimed ids point you upstream. 

The experiment will explore how these two proxying visions of secure chaining and secure referals combine, merge, complement or fight each other.

Peter.

Does it support https? On Firefox 3 I received (Error code: ssl_error_rx_record_too_long) * when trying to connect to https://rapattoni.trustbearer.com/ but also see http://www.startssl.com/?app=25#81 (update of ca-bundle needed).

* See https://bugzilla.mozilla.org/show_bug.cgi?id=410339

-- 
Regards 

Signer: Eddy Nigg, StartCom Ltd.
Jabber: xmpp:startcom at startcom.org
Blog: Join the Revolution!
Phone: +1.213.341.0390

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080309/82ac10c6/attachment-0002.htm>