SP V3 metadata types

Tom Scavo trscavo at gmail.com
Tue Jun 12 10:01:02 EDT 2018


Brent, thanks for weighing in.

On Mon, Jun 11, 2018 at 4:57 PM, Brent Putman <putmanb at georgetown.edu> wrote:
>
> Like Scott, I don't think we agree on what "smarter" could mean.

No doubt about that :-)

> Are you
> perhaps missing that the metadata in the persistent cache is loaded into
> memory on every refresh?

Can you define what you mean by "refresh" here? Do you mean query?
(Sorry, I don't mean to be overly pedantic.)

> (as long as still valid, not expired, etc)  What
> that means is that, once it's primed into the provider by the first request
> for it [1], it's going to effectively be available for as long as it is
> still valid - the same as an aggregate would be.

Okay, but under what conditions will the persistent cache be accessed
by the IdP?

> At that point it effectively is "local", in that no query is attempted for
> those entities, and it doesn't matter whether the source server is available
> etc.  Isn't that what you're essentially trying to do with the notion of the
> separate batch provider accessing an aggregate of "high value" entities?

Yes, I think so, but I'm not sure since this is new to me. I've read
all the documentation and AFAIK there is nothing in the docs along
these lines. What did I miss?

In any case, I'm not sure I understand this well enough to document
it. Can you describe what happens if the server goes down for, say, 20
mins?

Also, what happens if the server returns 304 Not Modified?

> ...
> the other approach we talked about was a simple Spring bean that would take
> a metadata resolver ID and a list of entityIDs and just do the
> resolution/priming internally on IdP (re)start.

Is this another application of <md:AffiliationDescriptor>?

Thanks Brent.

Tom


More information about the dev mailing list