ADFS, SharePoint, and InCommon?
jean-marie.thia at upmc.fr
Mon Nov 5 02:40:28 EST 2012
ADFS is not build with federation (trust circle) in mind, so claims
providers and relaying parties should be set one by one.
I just configured a SharePoint 2010 to use full claims authentication with
Shibboleth through and ADFS.
For the ease of configuration and for metadata refresh (156 IdPs), I wrote
a a powershell script that consumes the french federation (RENATER)
metadata, populates ADFS, builds the RHD (WAYF/DS) page and refreshes the
IdP metadata. It is not fully documented yet, so Albert email me if you
want it. It might help me have the explanation done earlier and shorten a
release to the community.
The other script (FEMMA) is written in python and deals with SP and is
hosted on SourceForge.
The last point is publishing the ADFS metadata to the Federation. For
RENATER I had to manually declare ADFS as an SP, but my test IdP can
directly consume the OOTB ADFS metadata. I plan to do something one day
and I am not sure that it will comply with Incommon.
On 11/3/12 5:56 PM, "Tom Scavo" <trscavo at gmail.com> wrote:
>On Fri, Nov 2, 2012 at 4:28 PM, Albert Lunde
><albert-lunde at northwestern.edu> wrote:
>> cookbook examples seem to describe tweaking both Shibboleth and ADFS
>> configurations, but we have no control of remote InCommon Shibboleth
>> IdPs, and I'm not sure that the metadata for an ADFS/SharePoint web site
>> would be orthodox enough to publish via InCommon.
>The problem is not so much publishing metadata for the SP (since
>InCommon completely controls the format and content of that metadata),
>but rather how your SP will 1) refresh metadata, and 2) discover IdPs.
>The two problems are related.
>AFAIK, AD FS 2.0 will not consume InCommon metadata (or any metadata
>wrapped with an <md:EntitiesDescriptor> element) so you'll need a
>workaround for that. There is a 3rd-party script floating around
>somewhere but I haven't tried it. I'd be interested in knowing how you
>ultimately solve this problem.
>Once the workaround is in place, you may get discovery for free, but
>if that too requires a workaround, a centralized discovery service
>might help. InCommon provides one but you may wish to deploy a
>different DS (such as the Shibboleth DS) to service AD FS.
>Just some thoughts for your consideration :-) Let me know how it turns
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
More information about the users