Shibboleth Developers

["Scott Cantor" <>]

> Certainly this is true for if you're comparing only the servlet and 
> filter impls, it should be true for the a Tomcat realm too (as it's just 
> HttpServletRequest/Response based too).  It's likely there would be some 
> difference between those three and a programmatic interface.

That's my point regarding an API. I don't think it's just an API, it's an
API plus a SAML protocol processing function that is living in there
somewhere anyway.

You don't send SAML messages to "application" resources without effectively
making every application implement via library calls (and including all the
config machinery for) a nearly full-blown SP. Or you take shortcuts to
produce a lighter SP (i.e. zxid.org). The former is just stupid, so it's the
latter, or it's a non-SAML SSO protocol that you can hook the app to with a
minimum of effort while the SAML part is elsewhere.

So if you have an API, I think it's to interact with the SAML bits inside
there, most of which probably run as a servlet or filter alongside the
application. At which point it's not what people really mean by an API-based
implementation and it's not self-contained in a library with four parameters
and no config.

> I agree, but most people aren't writing their apps this way.  You're a 
> special case, because of your experience, and have led people (correctly 
> I think) to this model.

My point is just that the models people do use are so broken that no matter
what integration strategy you choose, they can't use it without resulting in
application changes and generally suboptimal integration.

-- Scott