Shibboleth Developers

["Cantor, Scott E." <>]

On 6/24/11 11:42 AM, "Peter Williams" 
<>
 wrote:

>I don't see anyone using Internet2 IP  - the Shibboleth brand, for
>example. But, its clear that folks are playing off the reputation of the
>software, since its embedded.

Not much we can or probably should do about that within reason, but as
long as it's "uses", "powered by", "compatible with", etc., that's more or
less within the acceptable range.

>We have long imposed on Paul's several Shib IDPs a bridge model - that
>insulates our SP from Shib thinking _while facilitating what users care
>about: SSO experience.
>I note that bridging is now mainstream

Reality shows are mainstream too. Sorry, but putting "SSO experience" and
bridging into the same sentence is laughable.

>Now considering our own small RP experiment using Joomla, and the
>potential to use embedded-Shib (from a vendor) to add SAML2/ws-fedp
>protocol engines, I ask; so HOW WELL is Shib architected to support
>multi-tenant SPs, like a multi-site installation of joomla.

SAML end to end has demonstrable overhead for vhosting at scale, I haven't
ever denied that. The only way around that is adding a proprietary SSO
component into the mix. Since people can do that with the SP as it stands,
without me having to dictate one, I see no reason to add one myself.

As for multi-tenant, I don't think most would be comfortable with
different tenant's user data mixing in one process. I also think most of
the supposedly more partitioned approaches are mainly semantics. If you
want good separation, you need VMs IMHO.

> This is looking at Shib's last-mile cookie - and considering how well it
>may have been integrated with joomla token handling. Obviously, Im
>looking as much at the design of the joomla integration package as much
>as Shih protocol engine and Shib-cookie, to understand this use case.

I'm never going to formally document the "last mile" when I can't
guarantee it won't change. People don't listen when you say "this is
documented but not publically stable", they just code around it and then
complain if you break their code. I'm not doing it to hide security
details, because there's nothing to hide, it's a cookie, they suck, we
know this.

>same info in each). For other IDPs, the AuthenticationStatement is
>missing. I thus ask, assuming Shib SP would be the recipient of such
>tokens, intending to manage the shib/joomla session, how well would Shib
>do on being presented with a token (in SAML2 format say) that omits the
>AuthenticationStatement.

It would fail, since SAML SSO requires one, as does the WS-Federation
passive interop profile that we supported. The specifications we use are
public, you can just read them.

> I ask this, as when I use PingFederate in its place, PingFederate
>objefts mightly - since essentially it expects an authenticationStatement.

That's a good thing.

> I note that when I build my own SP out of the MSFT WIF tookit, there are
>no problems (presumably as the library is well-aligned to the profiles
>used by ACS).

Yes, this is the well-known "ham sandwich" profile.

>I don't have an answer, and don't really have any recommendations to dev
>folk. But, I hope its useful to see how we were thinking, as folks
>perform design work on the next version. The issues mentioned above are
>very important to us, and are not going away.

We will not be supporting (in our code) non-existent standards for the use
of SAML that allow for arbitrarily missing content.

If you want to plug in your own profile handlers that do support this, the
APIs for that are public and not very extensive. I am more than happy to
help advise somebody how to do that. It requires writing C++ code. This
was a language used by ancient demons now buried deep in the earth who
will someday rise and enslave Ruby programmers.

-- Scott