InCommon metadata support

[Nick Roy <>]

Hi Roy,

InCommon tries to ensure that each institution lists only one IdP in
metadata, since having more than one IdP can cause very large change
management and loss of access problems for your users, among other
problems.  If you want to migrate from one IdP to the other and retire
one of the two IdPs long term, please let me know and we can discuss
options.  If you truly want to have two IdPs, one for one purpose and
the other for another purpose (say, Shibboleth for SAML federation in
InCommon, since Shibboleth actually works for that purpose, and ADFS
does not) and keep ADFS for your bilateral stuff, that would be an
option.  In that case, you could consider having ADFS front Shibboleth
using a RemoteUser login handler, so that you get perceived Single
Sign-On for your users.  Or you could try to front ADFS authentication
with Shib, but then you'd probably lose SPNEGO / Windows Integrated
Authentication (if that is what you're using) unless you modify your
Shib deployment.

If you do decide you need two IdPs in metadata, there is a charge for
that.  Please email 

 to request an additional IdP.
Again, I'd strongly recommend you not do this.

Best Regards,

Nick Roy
Director of Technology and Strategy, InCommon

On 1/26/18 12:00 PM, Roy Hatcher wrote:
> Greetings,
> 
>  
> 
> I'm writing because our institution, University of Arkansas, has begun
> using AzureAD SSO for single sign-on purposes. However, we have also
> been running Shibboleth IDP for years, and want to continue to use it,
> as well, in the near term.
> 
>  
> 
> We're currently trying to work with a new Service Provider that requires
> our Metadata be loaded into a federation aggregate, however, we would
> like to configure this SP to work with AzureAD rather than Shibboleth.
> 
> Logging into Federation Manager, there doesn't appear to be a way to
> allow two different sets of IDP metadata.
> 
>  
> 
> Is there a method for allowing both our IDP's metadata to be loaded into
> the InCommon aggregates?
> 
>  
> 
> Thank you,
> 
> Roy
> 
>  
> 
> --
> 
> Roy Hatcher
> 
> Security Analyst
> 
> University of Arkansas
> 
>  
> 
>  
>