[keycloak-user] Differences between SAML descriptors
Bill Burke
bburke at redhat.com
Wed Feb 8 19:41:39 EST 2017
There is no reasoning why there is an <EntitiesDescriptor> element. I
think I just copied an example from a SAML spec and assumed that was the
correct way to publish it. Can't remember, it was years ago....:) I
created a JIRA for this
https://issues.jboss.org/browse/KEYCLOAK-4399
On 2/8/17 1:49 PM, Muein Muzamil wrote:
> 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 at gmail.com
> <mailto:shmuein+keycloak-dev at 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 at redhat.com
> <mailto:bburke at 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 at lists.jboss.org
> <mailto:keycloak-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-user
> <https://lists.jboss.org/mailman/listinfo/keycloak-user>
>
>
>
More information about the keycloak-user
mailing list