Shibboleth Developers

["Scott Cantor" <>]

Was thinking a little more about this, and realized that I forgot one little
detail about the current trust APIs, namely it doesn't really even *have*
any support for authenticating the client end of an SSL connection. My end
didn't need it, so I ignored it at the time.

Since we need to fix that now anyway for 1.3, seems like that's the obvious
hook to hang whatever we need for LionShare off.

The Trust layer in my code takes the metadata layer as a parameter, in
effect, but it isn't required to use it (or at least not in any specific
way). I also realized that even now, while I support the idea of fetching
KeyDescriptors from the metadata based on the providerId, that's not a
requirement now. It's not even the typical approach I use, we do more based
on the Site or SiteGroup, not individual key names. So being able to
reference specific keys based on the SP isn't needed here.

So I could easily see having a trust plugin that knows to recognize
LionShare clients based on the providerId (or whatever we use) and simply
specifies a trust policy to apply for the credential supplied based on the
SASL CA or whatever you need.

Long way of saying I was making it a lot harder in my head than it actually
is. No need for a database or anything fancy (unless you have to actually
map from an opaque DN to a real username without some kind of encryption
approach, which seems unnecessary since we already support that).

-- Scott