InCommon metadata support

[Nick Roy <>]

Thanks for this addition, Patrick.  I somehow read Azure as ADFS.
Patrick is quite correct about all of this.  We are not able to register
Azure as an IdP for these and other reasons.

Best,

Nick

On 1/26/18 12:41 PM, Patrick Radtke wrote:
> Hi Roy,
> 
> I believe InCommon requires that your IdP entity ID be from a domain you
> control. 
> AzureAD's entityIds are under https://sts.windows.net/[tenant] and would
> not qualify.
> I don't believe they support editing the IdP entityID.
> 
> I believe you would also face issues with the signing keys. AzureAD
> publishes 3 signing keys, and I believe InCommon's UI supports 2.
> We've had a customer experience unexpected SAML key rotation on the free
> tier of AzureAD. If you experienced such an event it may take over a day
> to get your updated keys published and distributed through the federation.
> 
> - Patrick
> 
> On Fri, Jan 26, 2018 at 8:37 AM, Roy Hatcher 
> <
> <mailto:>>
>  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____
> 
>     __ __
> 
>     __ 
>