Shibboleth Developers

I'd like to review this topic again on monday (hopefully for the last 
time)... does anyone see any issues or concerns at this point?

At 1:07 PM -0500 12/8/04, Scott Cantor wrote:
> 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