[OpenID] Discovery and Security

Mon Mar 24 05:29:34 UTC 2008

Nate!

Your discussion about multiple attributes authorities merging attributes (co-mingled with sso flows) in a chaining model is fascinating. This is what the folks at Trustbearer and Rapattoni did, only 3 weeks ago, when building out the Rapattoni/Trustbearer OP. It was so simple and easy, its worth bearing mention. The combo of a mostly stateless OP (using https controls) and a stateful SAML entity (using switched PKI controls) is quite beautiful, so far.

openid.trustbearer.com is a straigthforward OP. It highlights anti-phishing auth, based on leveraging US govt PIV and DoD CAC smartcards, along with OOB smartcard and certificate provisioning procedures. Once folks understand NSA's silo concept, that is anything but bigbother and is intended to be highly commercial in nature, PIV will do fine socially as a US national id card. For folks wanting open source software (since folks often consider any 3-letter US agency to be auto-evil), one can also play in the sand pit using smartcards you build and provision yourself, using the srcware from the musclecard.com project. Depending on your paranoia level, you can go all the way down to the verilog if you want, in such as Atmel's programmable logic array smartcards. This is the kind of thing I do for fun, on weekends.

What we then did was ask ourself, more usefully, how could Rapattoni (working in webapps for Realtors, not smartcard firmware) could leverage the Trustbearer kiosk service (an outsourcing service for OPs). Being a SAML2 capable attribute and websso authority, a family get-together between the sister OP endpoint at Trustbearer and brother SAML2 endpoint at Rapattoni was an obvious way to go. An early choice was to make a choice between leveraging the SAML2 attributeQuery handoff as the mashup technique between the two services, or leverage SAML2's sp-initiated websso. For various reasons, I chose websso. (It allows me to experiment with SAML2's IDP-proxying model, hidden within the Rapattoni cluster.)

We deployed 3 services, without considering XRIs. (XRIs do work, but exactly as at openid.trustbearer.com.) In each case, each of three thread pools in a single OP server act as distinct proxies to one or three distinct SAML entitys, playing the role of sp-initiator. Because of the SAMLentity virtualization features of the Rapattoni SAML2 server (from Ping Identity), one actual endpoint serves all three entities, each distinguished by different publickeys.

1. the OP rapattoni.trustbearer.com delegates almost all control to the backend SAML2 entity. Provided the "localid" asserted by the SAML entity matches what the OP considers to be the (enrolled) localid of the OP user, those attributes from the SAML response that match the openid.sreg schema are signaled to the RP, alongside a positive openid assertion. AX attributes are currently dropped on the floor, pending further work. Directed ID works nicely, leveraging SAML2's persistent nameid protocol. This use of nameid on the rapattoni-enabled OPs contrasts with the openid.trustbearer.com procedures, which allow the enrolling *user* to select their  own choice of directed openid, more along the lines of myopenid.

2. requests to the OP rapattoni.tb.trustbearer.com first consult the trustbearer (tb) service for both websso and attributes. Then requests are chained off to the rapattoni websso and attribute authority. trustbearer merges the two sets of attributes, including openid's pape and nist attributes, according to a decided dominance relation (and/or max function) that takes into consideration the order of the two attributes authorities in the domain name (and thus OP-Identifier/SAMLentityname).

3. tb.rapattoni.trustbnearer.com does the same as 2, in reverse. In terms of attributes, we are simply choosing one or other src for the value. (I supposed that some kind of advanced merge logic could also be invoked, since we have a owl reasoner available, via an odbc/jdbc connection!) In assurance terms , we are playing with "composition of assurances", as in NCSC RedBook and the doctrine of "N-TCBs". We didn't get too theoretical here. We just stuffed the merged attribute set into an id_resp,and threw it down the socket, presuming later analysis of what composition "means".

4. Exploitation of the ability to "merge" two attribute authorities is dependent on the Rapattoni service first concluding SAML2 account linking with a necessarily already-enrolled smartcard-capable tb account. The Rapattoni authority thus "controls" the TB attribute authority, but can only by design influence the public OpenID used (versus attributes pre-provisioned on the smartcard by some silo authority).

5.In either attribute merge case, the Rapattoni SA\Ml2 account linking database controls information flow and provisioning of openids. It thus acts as an openid provisioning authority. In later work, SAML2's nameid protocols might be additional leveraged when "updating" provisioned openids.

6. All the rapattoni TB consumers retain state, allowing for cascaded account linking. Receipt of a id_resp can auto-invoke an IDP-initiated SAML websso flow, using the session state at the consumer as an attribute authority. This allows us to be playful, with states based on directed id vs states based on composed attributes. Formal meaning is currently rather unclear (!), tho its all proving quite useful.

7 .Somewhere above, I really ought to have said that various Rapattoni user auth processes are optionally invoked by each tenanted customer, including EMC's/RSA's infamous  time-synced one time password and CR scheme, as hosted in a variety of containers (fingerprint readers, phones, keyfobs, smartcards, PC  files, browser toolbars...)

Today, the these merge processes assume a chaining and multicast concept, though the multicast group today contains only 1 SAML attribute authority. We use much the same principles as an X.500 DSA used to use , when it parallel-chained or multicast n operation sub-requests to n subordinate servers responsible for subordinate naming contexts in a subtree or 1-level search, collating, caching and returning whatever answers it actually had received ...after some timeout period.

In the openid world, I really do not envision OPs dealing with multiple attribute authorities ever needing to have to enforce X.500s control signals when dealing with multiple attribute authorities. Its surely UNnecessary to have the UA (the openid Consumer) specify requirements on master and slave copies, cached and non-cached attributes handling, or invoke transactional updates in a multicast distributed update! (In the realty space, we have our own update, that will one day hopefully migrate to a SPARQL update, as SPARQL matures) For the purposes of openid, all these matters can hopefully be simply delegated to the XRI infrastructure. Hopefully, XRI just "works".

Peter.

From: Nate Klingenstein
Sent: Sun 3/23/2008 8:24 PM
To: Peter Williams
Cc: openid-general List
Subject: Re: [OpenID] Discovery and Security

Peter, 

For the user, this comes down to a first hand experience of: 1) choose an SP target, 2) select an IDP, 3) be "fowarded" towards the authentication service of that IDP. As a proprietary extension of SAML1.1 facilitatin the (non-standard) SP-initiated websso flow, it makes sense.

This is the most common deployment strategy, yes.  However, there's nothing in Shibboleth or SAML that constrains it to this model; it can be IdP-first, or IdP selection can be done at the resource by use of buttons or a text field, etc. etc.  Any SP can decide through its configuration how to do this.

I think this is the essential point to stress: Shibboleth discovery is completely optional and entirely unrelated to the security model.

To help make the distinction clearer,  let me encourage us to adopt some terminology for what seems to be two, quite different, communication patterns: "chaining" vs "referals".  To be intellectually safe, I'm stealing these terms from the well worn LDAP/X.500 (distributed) directory service protocol -- standardized by the highly formal ISO/ITU-T process, as augmented by additional IETF and MACE profiling work. Because of Drummond's ultra clearly described model for abstract/concrete identifiers (persistent URNs, in webspeak) - where he implied that understanding these construct are essential to comprehension of the OpenID2 model --  I want to note in particular that the LDAP/X.500 directory model subsumes the (really old) X.650 Recommentation - whose  naming/addressing/registration model also concerns those names/identifiers/addresses which are specifically "persistent".

These aren't analogous to discovery in Shibboleth, and we don't have either in Shibboleth today.

To go on a brief tangent, where they will arise is in attribute aggregation, which is the process of pulling identity information from multiple providers and collating it.  This problem will become very real in our federations as community members increasingly have their primary account outside the organization, but there are attributes, licenses, and trust models for which the organization itself will always be the only authority.

The three most likely solutions to the attribute aggregation problem are:

1)  Proxying, e.g. chaining, of requests and attributes.  Today there are quite a few deployers experimenting with this process simply by setting up an IdP -> SP -> IdP + more attributes -> SP chain, which effectively destroys all information about the initial IdP and is a chaining model.
2)  Referrals through sending a unique identifier for a second IdP and a second unique identifier for the user inside an assertion from one IdP.  The SP could then chase the referral by making a query to the second IdP using the second identifier.  The use of separate identifiers maintains the user's privacy and allows for some cool techniques, like the Liberty Alliance's early work, but it's not strictly necessary.  Those core ideas were good, if a little complex and ahead of their time.
3)  Smart clients that can grab and present multiple claims/assertions at once.

#3 is my preferred choice by far, the simplest, and the least likely to succeed.  None has been widely attempted outside of the laboratory to date.

Thanks for your insights,
Nate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080323/c8ad5774/attachment-0002.htm>