Closed antonpiatek closed 8 months ago
Ok, debugging the read method it is simply asserting that the xml id matches the url if (metadata.EntityId.Id != this.EntityId.Id)
but Azure is returning an EntityId of https://sts.windows.net/59ec147a-a915-41b8-b363-f5137ac841f0/
which is much shorter than the original url.
What is the value in that assertion? Can we just use the EntityId as provided? If not, what about a way to specific the EntityId and URL separately (I'd still have to fetch and parse the xml to achieve this).
There is a long story why this behaviour is enforced that dates back 10 years to when the library was designed...
The way to configure it is to set the actual Entity Id as the EntityId
in the constructor and use the MetadataLocation
for the URL of the metadata. Setting MetadataLocation
automatically sets LoadMetadata
so there's no need to set it.
Thanks! that works and I got Azure SAML working.
In case anyone else is searching for Azure SAML, I also had to configure the name id policy to something else, eg
opt.SPOptions.NameIdPolicy = new Sustainsys.Saml2.Saml2P.Saml2NameIdPolicy(true, Sustainsys.Saml2.Saml2P.NameIdFormat.EmailAddress);
Running the sample AspNetCore application with an Azure SAML2 IdP fails to start with the error
I can't see anything obviously wrong with the IdP metadata generated by azure at https://login.microsoftonline.com/59ec147a-a915-41b8-b363-f5137ac841f0/federationmetadata/2007-06/federationmetadata.xml? appid=f6890359-6a2b-4336-a34d-9c12913df9c4
Using
Sustainsys.Saml2.AspNetCore2 Version=2.9.0
onnet6.0
The config is defined as
I'm not even sure where to start looking for contributing a fix here