Shibboleth Developers

[Tom Scavo <>]

I've been following Steven's posts regarding LionShare support and
such, and although I don't have anything substantive to add at this
point, there does appear to be a considerable amount of overlap
between LionShare and GridShib.  What works for one may very well work
for the other.

Tom


On Wed, 8 Dec 2004 13:07:57 -0500, 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
> 
>