When we try to upload this metadata (downloaded from the public URL) to PingOne, it doesn't like it (metadata from installation tab works fine). Is there any reason for this?

Hi All, Currently, KeyCloak supports two mechanisms to download SAML metadata. One is using this public URL <root>/auth/realms/{realm}/protocol/saml/descriptor. The Second option is to download it from the installation tab of the client or using this API /admin/realms/{realm}/clients/ {id}/installation/providers/{providerId} It seems that there are some differences between them. Especially the first option returns you metadata with an extra <EntitiesDescriptor> tag. Such as <EntitiesDescriptor Name="urn:keycloak" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <EntityDescriptor entityID="http://10.164.44.249:1130/auth/realms/7BOM25F24Y "> ......... </EntityDescriptor> </EntitiesDescriptor>

When we try to upload this metadata (downloaded from the public URL) to PingOne, it doesn't like it (metadata from installation tab works fine).

Is there any reason for this?

On 2/4/17 11:41 AM, John Dennis wrote: > On 02/03/2017 03:23 PM, Muein Muzamil wrote: >> Hi All, >> >> Currently, KeyCloak supports two mechanisms to download SAML metadata. >> >> One is using this public URL >> <root>/auth/realms/{realm}/protocol/saml/descriptor. >> The Second option is to download it from the installation tab of the client >> or using this API /admin/realms/{realm}/clients/ >> {id}/installation/providers/{providerId} >> >> It seems that there are some differences between them. Especially the first >> option returns you metadata with an extra <EntitiesDescriptor> tag. Such as >> >> <EntitiesDescriptor Name="urn:keycloak" >> xmlns="urn:oasis:names:tc:SAML:2.0:metadata" >> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> >> <EntityDescriptor entityID="http://10.164.44.249:1130/auth/realms/ 7BOM25F24Y >> "> >> ......... >> </EntityDescriptor> >> </EntitiesDescriptor> > If the SP is unable to parse SP metadata containing an > EntitiesDescriptor in addtion to an EntityDescriptor then the SP is at > fault. All the EntitiesDescriptor is is a container for multiple > EntityDescriptor elements, it is perfectly permissible to have a > container contain only 1 element just as it's acceptable to omit the > container and have a bare element. > > If your SP cannot parse a metadata file containing a EntitiesDescriptor > tag it's easy to strip it off the xml with a text editor. > > Irrespective of the SP's ability to parse metadata containing an > EntitiesDescriptor element is the requirement stated in Section 4.1.1 of > the SAML Metadata spec which requires metadata published at the IdP's > well known location for metadata retrieval to contain *only* a > EntityDescriptor as the root element. Since > <root>/auth/realms/{realm}/protocol/saml/descriptor is as close as > Keycloak gets to published well known location for IdP metadata > retrieval the use of a EntitiesDescriptor violates the SAML spec. I > don't believe there is JIRA filed for this yet. However, I emphasize > this is independent of the SP's ability ability to parse the IdP > metadata because it does not know where the IdP metadata originated > from. It should iterate over all the EntityDescriptor's looking for an > IDPSSODescriptor and then if it wants to confirm exactly one was found > (or it could just load all of them, depends on the SP). > >> When we try to upload this metadata (downloaded from the public URL) to >> PingOne, it doesn't like it (metadata from installation tab works fine). > There are other inconsistencies in the IdP metadata depending on how > it's retrieved from Keycloak aside from the EntitiesDescriptor tag. The > inconsistent IdP metadata is a known problem and has been reported in > this JIRA: > > https://issues.jboss.org/browse/KEYCLOAK-3373 > >> Is there any reason for this? > Any reason for the inconsistencies, no. > There is a reason....They are different because the published global one is all possible bindings and formats the IDP supports. The one generated in the "Installation" tab is based on how the client was configured and thus may not contain things like redirect bindings. Basically, its how the IDP wants the SP to communicate with it. Cheers, Bill _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Quick reminder to question below. Can you please also explain why the public endpoint has an extra <EntitiesDescriptor> tag whereas it is not there in meta data downloaded from installation tab, is it intentional or should I create a JIRA ticket for this? <EntitiesDescriptor Name="urn:keycloak" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:dsig="http://www.w3.org/2000/09/xmldsig# <http://www.w3.org/2000/09/xmldsig#>"> <EntityDescriptor entityID="http://10.164.44.249:1130/auth/realms/7BOM25F24Y <http://10.164.44.249:1130/auth/realms/7BOM25F24Y>"> ......... </EntityDescriptor> </EntitiesDescriptor> regards, Muein On Mon, Feb 6, 2017 at 12:56 PM, Muein Muzamil <shmuein+keycloak-dev(a)gmail.com <mailto:shmuein+keycloak-dev@gmail.com>> wrote: Bill, Your point about having client tailored metadata make sense based on what is configured for that SP. Can you please also explain why the public endpoint has an extra <EntitiesDescriptor> tag whereas from installation tab it is not there, is it intentional or should I create a JIRA ticket for this? <EntitiesDescriptor Name="urn:keycloak" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:dsig="http://www.w3.org/2000/09/xmldsig# <http://www.w3.org/2000/09/xmldsig#>"> <EntityDescriptor entityID="http://10.164.44.249:1130/auth/realms/7BOM25F24Y <http://10.164.44.249:1130/auth/realms/7BOM25F24Y>"> ......... </EntityDescriptor> </EntitiesDescriptor> Regards, Muein On Sat, Feb 4, 2017 at 1:21 PM, Bill Burke <bburke(a)redhat.com <mailto:bburke@redhat.com>> wrote: On 2/4/17 11:41 AM, John Dennis wrote: > On 02/03/2017 03:23 PM, Muein Muzamil wrote: >> Hi All, >> >> Currently, KeyCloak supports two mechanisms to download SAML metadata. >> >> One is using this public URL >> <root>/auth/realms/{realm}/protocol/saml/descriptor. >> The Second option is to download it from the installation tab of the client >> or using this API /admin/realms/{realm}/clients/ >> {id}/installation/providers/{providerId} >> >> It seems that there are some differences between them. Especially the first >> option returns you metadata with an extra <EntitiesDescriptor> tag. Such as >> >> <EntitiesDescriptor Name="urn:keycloak" >> xmlns="urn:oasis:names:tc:SAML:2.0:metadata" >> xmlns:dsig="http://www.w3.org/2000/09/xmldsig# <http://www.w3.org/2000/09/xmldsig#>"> >> <EntityDescriptor entityID="http://10.164.44.249:1130/auth/realms/7BOM25F24Y <http://10.164.44.249:1130/auth/realms/7BOM25F24Y> >> "> >> ......... >> </EntityDescriptor> >> </EntitiesDescriptor> > If the SP is unable to parse SP metadata containing an > EntitiesDescriptor in addtion to an EntityDescriptor then the SP is at > fault. All the EntitiesDescriptor is is a container for multiple > EntityDescriptor elements, it is perfectly permissible to have a > container contain only 1 element just as it's acceptable to omit the > container and have a bare element. > > If your SP cannot parse a metadata file containing a EntitiesDescriptor > tag it's easy to strip it off the xml with a text editor. > > Irrespective of the SP's ability to parse metadata containing an > EntitiesDescriptor element is the requirement stated in Section 4.1.1 of > the SAML Metadata spec which requires metadata published at the IdP's > well known location for metadata retrieval to contain *only* a > EntityDescriptor as the root element. Since > <root>/auth/realms/{realm}/protocol/saml/descriptor is as close as > Keycloak gets to published well known location for IdP metadata > retrieval the use of a EntitiesDescriptor violates the SAML spec. I > don't believe there is JIRA filed for this yet. However, I emphasize > this is independent of the SP's ability ability to parse the IdP > metadata because it does not know where the IdP metadata originated > from. It should iterate over all the EntityDescriptor's looking for an > IDPSSODescriptor and then if it wants to confirm exactly one was found > (or it could just load all of them, depends on the SP). > >> When we try to upload this metadata (downloaded from the public URL) to >> PingOne, it doesn't like it (metadata from installation tab works fine). > There are other inconsistencies in the IdP metadata depending on how > it's retrieved from Keycloak aside from the EntitiesDescriptor tag. The > inconsistent IdP metadata is a known problem and has been reported in > this JIRA: > > https://issues.jboss.org/browse/KEYCLOAK-3373 <https://issues.jboss.org/browse/KEYCLOAK-3373> > >> Is there any reason for this? > Any reason for the inconsistencies, no. > There is a reason....They are different because the published global one is all possible bindings and formats the IDP supports. The one generated in the "Installation" tab is based on how the client was configured and thus may not contain things like redirect bindings. Basically, its how the IDP wants the SP to communicate with it. Cheers, Bill _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user <https://lists.jboss.org/mailman/listinfo/keycloak-user>