[OpenID] cardspace+openid, saml2+openid, secured OP Discovery

[Peter Williams]

A thought experiment on OP discovery and potential security
requirements, for those interested in SAML2+OpenID (only). 

Its long. 

Delete now if the topic or the method is not interesting to you.

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

Thinking along the lines of the the message flow used by cardspace
protocols working in cooperation with OpenID...

...i've been wondering about a similar integration with SAML2. 

What cooperation would work?




Let's say one uses SAML2 Source-first IDP-initiated webSSO to logon to
an SP. There, account-linking occurs where the SP issues an OpenID, in
the namespace of the SP, during the first-time act of name-federation.
Perhaps it creates a blog page for you, while its at it, at the URL of
the openid value. Via SAML2 webSSO, you can at any time access your
blogsite, and do things like....set your html page's head links for OP
delegation, local-OP-identifiers.

So far, this is a SAML-centric equivalent of using a google login to
create/access to a blogsite, like someone had me do the other day in
order to alter the delegation properties of the blogsite's HTML page, as
associated with my OpenID.

Now let's say we add and use SAML2's SP-affiliation feature, so an
OpenID name issued as above by the affiliation-owner is then shared (and
recognized by) by all the other SP sites in the federation's affiliation
set. Whenever one does SAML2 webSSo to any of those other sites, that
issued OpenID will automatically be conveyed to the SP site, regardless
of which name you earlier cited and authenticated, on the IDP's website.






At this point, the SP site would presumably seek to complete OpenID
Auth. While it has assurance via the digital signature on the SAML
assertion that the IDP vouched for the appropriateness of the OpenID
value for the pseudo-anonymous user at that point of usage (one of the
SP affiliates), it is not asserting that the user has "control over that
UCI". That assertion is uniquely tested by an OP Consumer coresident at
that SP, that will perform a run of the OpenID Auth protocol as normal.

In this scenario, the OP Consumer has total confidence that an OP
Provider hosted by the primary SP in the affiliate-set
(affiliation-owner) is entitled to make assertions (or represent the
User's OP delegations) wrt that OpenID. The confidence comes from its
out-of-band act of joining the Sp-affiliation set, and participating in
the associated SAML federation that nominated the participating IDPs and
the affiliation-owner responsible for "issuing" OpenIDs and the
associated blogsites.




Now comes the big question: how to assure all the SP sites (running
OpenID Consumers) that the authoritative OpenID Provider is properly to
be found at URL X? (the endpoint of the SP that is the
affiliation-owner)?

Presumably the answer is for the IDP's cert to have an extension,
denoting the https URL - better still - also the cert issuerDN/serial of
the cert to be offered by the https endpoint at that affiliation-owners
OP Provider's URL. In essence the IDP is, via SAML security,
representing to all members of the affiliate-set the address of the OP
Provider hosted by the affiliate-owner. Via the cert reference, MITM is
addressed, so that http endpoint of the actual OP citing that cert can
be distinguished from https proxies attempting https-MITM against the OP
Provider.





What I like about this, as I thought about it, was the fact that the
assurance level of the OP Provider is essentially controlled by the SAML
IDP, who gets to decide whether a given SP is at a quality-level enough
to act as an affiliate-owner ... and thus a "whitelisted" OP Provider.

If the SAML2 IDP maintains multiple federations, each with several
affiliate-owners (and associated affiliate-SPs), the IDP is essentially
acting as a white-list provider of recommendations about the adequacy of
a group of OP Providers - delivering that very recommendation implicitly
WHILE presenting the OpenID itself during the Source-first webSSO! i.e.
a push model.

By definition the IDP could not do the initial webSSO act if the
affiliation-owner was no longer in the IDPs federation; an implicit act
of blacklisting, again via the push model.




Well. That was a fun thought-experiment, though it seems a bit heavy
weight! Its burdened OP Consumers will really heavyweight SAML2
implementation, in order to secure OP discovery and communicate the
assurance level of the OP.





If I now think about limits (including my own understanding of SAML
affiliation groups)... what I don't really get is what happens if the
very first webSSO to a member of the affiliate-set is NOT to the
affiliation-owner SP? Does SAML2 know to automatically redirect to the
affiliate-owner SP, to complete an account-linking interchange with that
affiliate-owner, first, and thus get the OpenID issued, before then
presenting it to the SP site in question?



Peter.