Shibboleth Developers

[Peter Williams <>]

Why such scorn? The issue with ACS v2 is obviously about some trivial fixes, 
based on learning what happens when deploying the technology you have been 
all working on for decade now to 1,000,000 sites run by your  typical, 
self-taught-computing, vb programmer (vs a 100 universities, with 
scholar-grade education levels and funding).

I took the PingFederate (latest build) demo application, already well used 
and built specifically for SAML2 conformance testing and certification, and 
modified the metadata configs so that instead of its own IDP talking unto its 
own SP (using SAML2), the assertions/responses/requests now to wander by a 
Azure ACS intermediator/bridge (using ws-fedp as the communication protocol). 
The bridge's presence is entirely hidden from the user, who seems no 
alteration of the very UI used in the (SAML2) conformance tests. The choice 
to present a home realm selector (didn't SHib 1 have a strange name for that 
function? counties, or shires, or something) is entirely optional, and only 
really has value when bridging social network IDPS presenting openid2  
interfaces to the world (yahoo, myopenid, google). By default ACS, is just a 
token relay, entirely hidden in existence mapping one blog into another, one 
communication session in another.

Of course, it doesn't actually work... but that is (at it stands, before 
someone deploys a debugger for an hour) because (a) PingFed in SP-role needs 
to be happy to receive a SAML-format assertion over ws-fedp that omits an 
AuthenticationStatement (just as WIF-build SP are evidently happy), or (b) 
MSFT engineers tell me how to config the bridge so it populates the 
Authentication Statement for a PingFederate IDP being mapped/bridged by ACS. 
(The latter info has not been forthcoming, yet, despite trying several 
forums. I can guess the design reasons, BTW).

It all does work JUST fine if instead of using a PingFederate IDP mapped to 
ACS udner ws-fedp in the scenario,  I swapped it out and presented an ADFS 
IDP (again bridged by ACS and using ws-fedp protocol). ACS populates the SP's 
token's AuthenticationStatements as you'd expect, and PF thus 
transforms/projects these tokens as SP to the usual complex of 100 last mile 
integration ...kits for all the usual legacy web frameworks. PingFed in that 
role is essentially just a Shib SP, doing some other proprietary (set) of 
last-mile integrations.

Now, how well does Shib *fit* into this bridging world in light of the fact 
that SPs (RP sites fronted by SP protocol interfaces on per-RP endpoints) are 
going multi-tenant... is my real issue set? I'm assuming (from context) that 
really it doesn't, given the architects' scorn for very concepts involved. In 
which case, if I go with Shib/Joomla in a world of bridging, I'm heading for 
failure. It would be like sticking a Russian space engineer into NASA, where 
the very engineering style clash dooms the integration - which is to say 
nothing about the quality of the Russian engineer. It's just a culture clash.

Yes, it's all a bit of a "ham sandwich" of a design - in the sense that the 
SAML profiles are fungible, in ACS-land. But, that's the nature of the 
generic types in the SAML/OASIA standard, surely. But, doing this is what 
Microsoft is good at, when making products, so the result scales to 1 million 
(working only with the bottom 80% use cases). But, such dumbing down is what 
always happens in software manufacturing, as a technology goes mainsteam. I 
don't expect the engineering that suits early adopters  with 20% needs to be 
that which suits the mainstream with 80% needs; the requiremnets are 
different, and profiling is the process which facilitate one token to rule 
them all (even if there are several variations, thereof.

Ok. Im starting to convince myself that I need to be negative on Shib 
(embedded) for Joomla. I'm just asking for trouble. Might as well stick with 
the php script, based on simpleSAML, that translates one 
(unsigned/unencrypted) blob into another, once communicated over https. I was 
hoping the Shib integration would "showcase" multi-tenancy, provisioning on 
the fly, entitlement mapping, etc. But, I don't it's going to; or at least 
not in a joomla integration.


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Cantor, Scott E.
Sent: Friday, June 24, 2011 9:10 AM
To: 

Subject: Re: [Shib-Dev] how good is the Shib SP ws-fedp support?

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