12:49 p.m.
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#">
<EntityDescriptor entityID="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> 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#">
<EntityDescriptor entityID="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> 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#">
> >> <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
>