Shibboleth Developers

[Peter Williams <>]

> Did anyone do an interworking  trial already with PingFederate as the IDP?

I can't touch products because of tampering. Since I have no idea how
serious they are about supporting dynamic federation, I don't know what
they've done yet.

Perhaps, since its all public information, we can simply arrange another 
Liberty-sponsored demo before some conference or other. I swear I've seen 
Shib folk do that before, in public, with multiple vendors systems. The only 
"touching" requires shib configuration and interaction with a non-Shib system 
(using SAMLstandards, only)



What I do know from others is that their metadata support
is still not up to snuff, so I don't see how that jibes with claiming to
support this kind of thing.

That is essentially claiming that their "Liberty Interoperable" certification 
is commercially meaningless (since metadata is so critical SAML2) - and 
doesnt jive with what you'd expect from a "respectable" product compliance 
test. Ill assume this means that Liberty is falling down, and not producing 
interworking tests of sufficient veracity. A compliance suite that produces 
this kind of comment about fundamental interoperability is not worth 
acknowledging (speaking as a customer).Shame on Liberty, if is true.



Is Shib2 "Liberty Interoperable"?

> I believe PingFederate does dynamic generation of the metadata from the
> endpoint, in the limited sense that the signature is generated and
attached
> on the fly - so the latest certs always percolate neighbor to
> neighbor...lampson style.

That's a DOS attack waiting to happen, but yes, the SP can do it. It just
isn't necessary to dynamically consume it. You can post a metadata document
ahead of time at the entityID for somebody else to consume.

So, its ambiguous from their manual what they do. It implies that the SP 
caches the retrieved metadata, and goes pick it up upon cache fault. During 
pickup, it implies that the metadata is resigned (since metafacts changed 
meantime (certs, attribute contracts, contact details) etc is supplied at 
that time. Id expect that the cache timeout is NOT allowed to exceed the 
expiry date/time of either the SSLcontrol cert or the SSO certs used for 
metadata-signing and SAML Response/assertion signing.

As the feature of the product to MANUALLY sign single-entity metadata (and 
store it in a file/URL) is not required to be used when arming the 
auto-distribution of metadata mode by its virtual IDPs, its hard to imagine 
that they are distributing static/unchanging signed metadata, minted last 
month, known to be out of date. Hardly seems a viable "product-grade" model 
for a critical infrastructure.

As their IDP server is multi-tenant, each virtual IDP has its own SSO certs 
for signing metadata and/or POSTs.Each must actas an SSL virtual host,whose 
individual SSL cert must have a subject name form with 
cn=value-tied-to-IDPentityId (to address Ping's [proprietary?] validity model 
on the SP, used for importing auto-discovered metadata)



Interesting to see SSL's PKI become a control authority for this "dynamic" 
SAML. The nice thing is... the maagement framework is as open and flexible as 
SSL itself is.