InCommon Technical Discussions

[Eric Goodman <>]

Thanks for all of this detail, Eric. Good info!

In this context you describe below, is ADFS acting as a Proxy? I.e., will 
IdPs see authentication requests coming from "UW ADFS" or from specific UW 
services? That's been an issue for UC in (non-ADFS) proxy type situations 
before. 

--- Eric


-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Eric C Kool-Brown
Sent: Wednesday, February 07, 2018 9:08 AM
To: 
;
 

Subject: [InC-Technical] RE: ADFS InCommon Federated Services Help

I think I left off one bit of perhaps relevant info regarding the second use 
case of ADFS as the IdP. The ADFS metadata (as a service provider) would need 
to be added to the InCommon aggregate in order to be trusted by the other 
InCommon IdPs. I suppose that ADFS could also have IdP metadata added so it 
could be a full federation partner as well. Does anyone on the list know of a 
federation member that has done either of these things?

Thanks,

    Eric

> -----Original Message-----
> From: 
> 
>  
> [ 
> ]
>  On Behalf Of Eric C 
> Kool-Brown
> Sent: Wednesday, February 07, 2018 8:44 AM
> To: 
> ;
>  
> 
> Subject: [InC-Technical] RE: ADFS InCommon Federated Services Help
> 
> Hi Alex,
> 
> There are two ways to configure ADFS for federation with InCommon. The 
> route we take at the UW is to configure ADFS to use our Shibboleth IdP 
> as the ADFS "Claims Trust Provider." ADFS used to be unable to consume 
> the InCommon metadata aggregate so in the past I used a special 
> metadata URL for our Shib. The latest version of ADFS has added the 
> ability to consume an aggregate, but it is fairly finicky to get working.
> 
> The other way would be to have ADFS be the IdP (its default 
> configuration) but again have it consume the InCommon metadata 
> aggregate. You could then use the default ADFS "Home Realm Discovery" 
> UI to select one of the InCommon IdPs. I've not gone down this road 
> because we send all of our ADFS relying parties to our Shib for authN.
> 
> ADFS does some things in an opposite fashion from what the SAML design 
> specifies. In particular, with SAML configuring federation is up to 
> the service providers. They provide a discovery (WAYF) page that 
> allows users to select an IdP. ADFS instead provides IdP discovery for 
> all relying parties. This can be overridden within ADFS to specify an 
> IdP per relying party. This is the route we've taken by configuring all of 
> our RPs to go to Shib for authN.
> 
> I've done some ADFS blogging which might be helpful:
> http://blogs.uw.edu/kool/.
> 
> I also have a wiki on ADFS here at the UW. I believe it uses federated 
> authN, but let me know if that's not the case:
> https://wiki.cac.washington.edu/x/5EMrAw.
> 
> This document is a great guide to configuring ADFS to use Shib as the IdP:
> http://download.microsoft.com/documents/France/Interop/2010/Using_AD
> FS2_0_For_Interoperable_SAML_2_0-Based_Federated_SSO.docx. It is 
> somewhat dated as ADFS now has more configurability and capabilities, 
> but it is still accurate.
> 
> Also, feel free to ask any other questions you may have.
> 
> Cheers,
> 
>     Eric Kool-Brown, 
> 
>     Software Engineer
>     University of Washington - IT Infrastructure
> 
> 
> > -------- Forwarded Message --------
> > Subject:    ADFS InCommon Federated Services Help
> > Date:       Mon, 29 Jan 2018 21:15:32 -0700
> > From:       Alexandre Adao 
> > <>
> > To:         
> > 
> > <>
> >
> >
> >
> > Hello, I am a novice in InCommon and Microsoft ADFS. I would like to 
> > know the procedures on how to configure MS ADFS for InCommon. Any 
> > information or assistance will be gratefully appreciated.
> >
> > ​Thanks,​
> >
> > --
> > ​Alex Adao​
> >
> > =============================================
> > Alexandre Magno Adão
> > Director of Information Security
> > Morgan State University (CGW 300k)
> > Office of  Information Technology (OIT)
> > 443-885-4415 Office
> > 443-803-3154 Cell
> > <http://www.morgan.edu>