Apparent inconsistencies in the Shibboleth wiki concerning persistent NameIDs for federating a Shibboleth IDP with Microsoft Azure
Florian.Lengyel at cuny.edu
Thu Apr 14 13:42:21 EDT 2016
This reminds me that I neglected to mention the Microsoft federation metadata at
<SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol" WantAssertionsSigned="true">
Accordingly, I have omitted
from my relying-party.xml override for Microsoft online.
(I also neglected to mention how my test setup was provisioned.)
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Wednesday, April 13, 2016 3:01 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Apparent inconsistencies in the Shibboleth wiki concerning persistent NameIDs for federating a Shibboleth IDP with Microsoft Azure
On 4/13/16, 2:56 PM, "users on behalf of Carlos Milán Figueredo" <users-bounces at shibboleth.net on behalf of cmilanf at hispamsx.org> wrote:
>I can't be grateful enough with every person who contributed in this thread. Thanks to you I was able to get Shibboleth IdP 3.2 up and running against Azure Active Directory (Office 365). The wiki page was absolutely misleading. I'll be creating a new one with the correct procedure if you don't mind.
Given that I think the original was/is mostly accurate, I don't really think that's going to help much but confuse people more.
The problem here is that dumping a ton of XML into a page doesn't help but to propagate mistakes. What's needed in providing integration guides is to cover the *technical requirements of the service*. Since the vendors aren't capable of documenting their own services, that's really what people are doing here.
Basically, the instructions need to be "what", not "how". "How" is a matter for the existing IdP documentation to cover.
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users