Skip to Content.
Sympa Menu

metadata-support - Re: [Metadata-Support] significant slowdown in XML Signature validation

Subject: InCommon metadata support

List archive

Re: [Metadata-Support] significant slowdown in XML Signature validation


Chronological Thread 
  • From: "Cantor, Scott" <>
  • To: "" <>
  • Subject: Re: [Metadata-Support] significant slowdown in XML Signature validation
  • Date: Fri, 19 Feb 2016 00:24:31 +0000
  • Accept-language: en-US
  • Authentication-results: spf=pass (sender IP is 164.107.81.214) smtp.mailfrom=osu.edu; incommon.org; dkim=none (message not signed) header.d=none;incommon.org; dmarc=bestguesspass action=none header.from=osu.edu;
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:23

On 2/18/16, 7:06 PM,
"
on behalf of Jeffrey Eaton"
<
on behalf of
>
wrote:



>The signature check passes (just as slowly as without the
>EntityRoleWhiteList filter), and the filtering completes but doesn’t seem to
>have much effect on the in-memory resident size (still taking ~250MB).

Linux really doesn't release memory. Results on Windows would be different.

>Loading that aggregate complete in 2 seconds, and the resulting shibd
>process only takes up about 40 MB of RAM. That actually seems like a very
>reasonable compromise.

I'm not sure how that's a compromise, that's just the old non-global set of
entities. Or am I not understanding? That would be a rollback, not a
compromise.

>I’m still evaluating what we’re going to recommend to our SP operators, but
>in the worst case, I can have them use the export aggregate, or my split and
>re-signed IDP-only aggregate, with no further changes needed from the
>InCommon side.

I'm still not understanding the real problem, apart from the obvious trend
that eventually it will be. I've run an SP that consumes more than this
amount of metadata for a decade, and it's never been a concern.

-- Scott




Archive powered by MHonArc 2.6.16.

Top of Page