Metadata question for Embedded Discovery and SP authentication of IdP

Jason Bau jasonbau at gmail.com
Tue Aug 2 21:47:13 BST 2011


Hi All,

I was setting up the Embedded DS v1.0.1 on my Stanford SP using the
InCommon metadata
(instead of using the metadata supplied directly by the Stanford IdP
at idp.stanford.edu).
I then tried to log in after selecting the Stanford IdP
and found the following:

* I was able to be redirected to the Stanford Login page
* However, the SAML2/POST response was not authenticated on the SP server.

After looking at the logs on the SP, I found that the SP could not
"establish the identity of the assertion
issuer (https://idp.stanford.edu)" because it could not find this
identity in the InCommon metadata.

After chaining in the Stanford issued metadata under
<MetadataProvider>, the entire login process was successful.

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).
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).  I checked and the InCommon Metadata
contains only an old, expired cert under
<AttributeAuthorityDescriptor>, along with an up-to-date cert under
<IDPSSODescriptor>.  The stanford-issued
Metadata has up-to-date certs in both places.

Here's my question:  is the expired cert to blame for my SP failing to
authenticate the IdP?


Thanks for your help.

Jason


More information about the users mailing list