Metadata Issue

Thomas Jones thomas.jones.g at gmail.com
Thu Oct 31 11:31:51 EDT 2013


Thanks Brent and Peter!

I've been doing some tests and know I'm getting an error about not finding
metadata of the service provider:

.......

17:04:10.612 - DEBUG
[org.opensaml.saml2.metadata.provider.ChainingMetadataProvider:253] -
Checking child metadata provider for entity descriptor with entity ID:
google.com/a/mygoogledomain.com
17:04:10.613 - DEBUG
[org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:518] -
Searching for entity descriptor with an entity ID of
google.com/a/mygoogledomain.com
17:04:10.613 - TRACE
[org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:531] -
Metadata root is an entity descriptor, checking if it's the one we're
looking for.
17:04:10.614 - TRACE
[org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:538] - Found
entity descriptor for entity with ID google.com/a/mygoogledomain.com but it
is no longer valid, skipping it.
17:04:10.615 - DEBUG
[org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:167] -
Metadata document does not contain an EntityDescriptor with the ID
google.com/a/mygoogledomain.com
17:04:10.615 - WARN
[edu.internet2.middleware.shibboleth.idp.profile.AbstractSAMLProfileHandler:287]
- No metadata for relying party google.com/a/mygoogledomain.com, treating
party as anonymous
17:04:10.616 - WARN
[edu.internet2.middleware.shibboleth.idp.profile.saml2.SSOProfileHandler:220]
- SAML 2 SSO profile is not configured for relying party
google.com/a/mygoogledomain.com
17:04:10.653 - TRACE
[edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter:109] -
Attempting to retrieve IdP session cookie.

As you can see, from my original post, the entity descriptor was found in
the index cache, and because of that it worked ok. Now, from the log of
this post, it can't found the descriptor in the cache and it's treating the
relying party as anonymous and make sense that it can't find the SSO
profile. So:

How Shib adds the descriptor in the cache? and when? (I suspect this has to
do with the *refreshDelayFactor* and the other attributes)

Is there a way of resetting the cache?

How can I add the descriptor to the cache?

I did another test and I reinstalled shibb (install.sh) and add again the
relying party and metadata, and everything start working again with the
same log from my first post. Any idea why this happens?

Peter I don't understand:

> Note that for locally managed metadata there's no gain in having any
> validUntil on the EntityDescriptor. So leaving that out is one
> possibility.

Since you mention that validUntil is useless in this context, how can I
make a local managed metadata expired?

> The other one is setting requireValidMetadata="false" on the IdP's
> MetadataProvider for that custom relying party, but I see you already
> have that (so either way an expired EntityDescriptor from a local file
> shouldn't disrupt operations).
> -peter

is not that what is happening? (the operation it's been disrupted). Due the
fact that the EntityDescriptor is not valid (I'm assuming that the reason
is because it has expired) is showing that it's treating the relyingParty
as anonymous, right?


Thanks for all the help.

Best,

Thomas.


On Thu, Oct 31, 2013 at 5:09 AM, Peter Schober
<peter.schober at univie.ac.at>wrote:

> * Thomas Jones <thomas.jones.g at gmail.com> [2013-10-30 23:31]:
> > I've tried to add the attribute validUntil to my SP metadata but
> > there's no difference:
> >
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <EntityDescriptor entityID="google.com/a/mygoogledomain.com"
> > xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
> > validUntil="2014-01-01T00:00:00Z">
>
> Note that for locally managed metadata there's no gain in having any
> validUntil on the EntityDescriptor. So leaving that out is one
> possibility.
> The other one is setting requireValidMetadata="false" on the IdP's
> MetadataProvider for that custom relying party, but I see you already
> have that (so either way an expired EntityDescriptor from a local file
> shouldn't disrupt operations).
> -peter
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20131031/494e2b2a/attachment.html 


More information about the users mailing list