Metadata question for Embedded Discovery and SP authentication of IdP

[Jason Bau]

On Tue, Aug 2, 2011 at 3:54 PM, Cantor, Scott E. <cantor.2 at osu.edu> wrote:
> On 8/2/11 4:47 PM, "Jason Bau" <jasonbau at gmail.com> wrote:
>>
>>I then noticed that the entityId for the Stanford IdP was different in
>>the metadata
>>("urn:mace:incommon:stanford.edu" for InCommon and
>>"https://idp.stanford.edu/" as issued by Stanford).
>
> Yeah, that's not ideal. Lots of things break when you introduce that kind
> of inconsistency. If you notice at all, that means the IdP isn't taking
> ownership of naming itself based on who you are, but by far the best
> approach is to avoid multiple names.
>
>>However, during both the successful and unsuccessful login attempts,
>>the cookie "_saml_idp"is set to base64(urn:mace:incommon:stanford.edu)
>>(presumably the successful attempt used the Stanford Metadata
>>with a different entityId).
>
> All the DS does is remember what you pick. If the metadata it's generating
> the list off of uses the InCommon name, then that's what it will store.
>

A follow-up question here.  Won't the SP use the InCommon metadata for the IdP
to authenticate the assertion?  I assume it will do the lookup in the
metatdata based on urn:mace:incommon:stanford.edu, and the cert for
the IdP is there under this name.  What is
missing for this lookup (and thus the SP's authorization of the IdP) to fail?

Jason


>>Here's my question:  is the expired cert to blame for my SP failing to
>>authenticate the IdP?
>
> No, the lack of metadata was.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
>