Shibboleth IDP and ADFS federation claim problem

[Chris Phillips]

If you are going the route of WIF for native WS* style protocol for your
webapp & want a shibboleth sign on, the web app will be a client hidden
behind an ADFS gateway that does the SAML to WS* claims conversion. The
WIF standalone app will not understand anything otherwise.

If you are looking for a how-to document from Microsoft about this, cut
and paste this into google:

Step-by-Step Guide: Federated Collaboration with Shibboleth 2.0 and
SharePoint 2010 technologies

It's 80+ pages and is a complete walk through.  Substitute your web app
for the Sharepoint 'webapp'.

Dealing with gateways works but it certainly adds many more cogs to the
machine of Single Sign On.
If you have an entire ecosystem of MSFT native apps that MUST use WIF and
you MUST use (a) Shibboleth IdP(s) you are in the land of gateways.

YMMV, but it may be easier to install the Shibboleth IIS SP and just use
SAML2 through and through. That said, we don't know your business
requirements or the identity protocol ecosystem you have to live in which
are likely to influence the choices you need to make.


Chris.




On 12-10-31 1:50 PM, "Peter Schober" <peter.schober at univie.ac.at> wrote:

>* Renzo De Renzi <renzos at me.com> [2012-10-31 17:05]:
>> Then I launched the WIF Federation utility Wizard to estabilish the
>> trust relationship between my Web App and the Shibboleth IDP but
>> when I select the STS WS_Federation metadata document location
>> (idp-metadata.xml) I get an ID1018 Error (The WS-Federation metadata
>> document does not contain a security token service descriptor.
>
>The protocols supported by the Shibboleth software are listed in the
>documentation. WS-Federation with STS (?) is not amond those.
>So it seems you're doing something wrong. More a question for some M$
>forum ("How do I add a SAML2.0 IdP").
>-peter
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net