ADFS, SharePoint, and InCommon?

[Chris Phillips]

Hi Albert,

It can be done.  Like any sp that wants attributes released for sign in, it is always a challenge in that respect.  The deployment is not just sharepoint either but also the ADFS gateway infrastructure component to support it. 

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. 

A big difference in the above doc(among some things) is using edupersonPrincipalName instead of their config which uses email for the userid/UPN to sharepoint.(Uhgg!)

That should start you off..

C

/mobile_____________________
chris.phillips at canarie.ca

On Nov 2, 2012, at 4:28 PM, "Albert Lunde" <albert-lunde at northwestern.edu> wrote:

> We've got a group at Northwestern that is interested in setting up a 
> SharePoint site for external (non-Northwestern) inCommon users, using 
> the ADFS 2.0 features that interrelate to SAML 2.0, and "Claims-Based 
> Authentication" as the Microsoft wrapper around SAML 2.0.
> 
> I'm having a hard time figuring out of this is really feasible.  The 
> 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 protocols used seem to be a mix of WS-Federation and SAML WebSSO, 
> and many gotchas are listed.
> 
> We aren't anywhere near production, we are just trying to see if this is 
> feasible enough to work on in some testbed context, but if it really 
> won't work in practice, that would be good to know.
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net