InCommon Technical Discussions

[Eric C Kool-Brown <>]

Hi Eric,

Unfortunately the IdP only sees the request as coming from ADFS rather than 
the originating RP. I don't know if the underlying protocols support naming 
the original requestor. If they don't, that seems like an oversight. The net 
result is that the IdP must release all of the attributes needed by the sum 
of the ADFS RPs. This means that the IdP operators must trust the ADFS 
operators to properly vet the RP claims requests and not release claims 
indiscriminately.

BTW, great follow-up post from Matthew!

Also, I found out that our UW-IT wiki is not currently federated so it cannot 
be accessed with non-UW credentials. The wiki service manager says that this 
could change but there is currently no time line on when that would be done.

Cheers,

    Eric

> -----Original Message-----
> From: Eric Goodman 
> [mailto:]
> Sent: Wednesday, February 07, 2018 9:18 AM
> To: Eric C Kool-Brown 
> <>;
>  
> ;
> 
> Subject: RE: ADFS InCommon Federated Services Help
> 
> 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: 
> 
>  [
> ]
>  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>