Shibboleth Developers

[Peter Williams <>]

Bridging is nothing new - but offends some (who tie idp assertions to 
infrastructure governance objectives within or across federations).

In one bridge, the samlp relying sp turns around and "releases" an ssl client 
cert. Having induced the session-powered browser to contact a https proxy, 
the released credential creates the peruser-client identified ssl tunnel.

Resources sessions are then tied to ssl's real crypto-based sessions ( rather 
than websso/wif/shib session cookies).

Hardware crypto can manage a hundred thousand such credential sets,   Without 
blinking. Client certs are just soft files, stored on disc within the hsm 
crypto boundary.

What shib really needs is a good solid hsm story, now: exploiting the crypto 
boundary (vs just interfacing to fast math chips).


On Sep 30, 2010, at 3:02 PM, 
"<mailto:>"
 
<<mailto:>>
 wrote:

We are looking at prototyping a Federation Bridge to link together two 
federations that use a different set of attributes/profiles.  Initially we 
are only worried about users of Federation A using the Service Providers of 
Federation B.  Federation A uses the SAML Attribute Query Profile to share 
attributes, and uses a shared PKI for authentication.  Our idea for bridging 
the federations was to deploy a Shibboleth IDP that could authenticate to 
Federation A's PKI and would use a new data connector that implemented SAML 
Attribute Query to get Federation A Attributes.  Then using all the 
capabilities already native in the IDP transform those attributes into 
Federation B attributes (as much as possible of course).  This IDP would 
ultimately exist in both trust fabrics of course.

My questions to the list are:

1) Is there anything blatantly flawed with this approach?
2) Any idea how hard it would be to create that data connector?  Or does 
anything like this exist already?

Thanks,
Jeff