Windows SP 2.6.0

Cantor, Scott cantor.2 at osu.edu
Fri Jun 9 14:20:58 EDT 2017


On 6/9/17, 2:01 PM, "users on behalf of Young, Darren" <users-bounces at shibboleth.net on behalf of Darren.Young at chicagobooth.edu> wrote:

> At that point the service appears to be up and running correctly. I can
> get /Shibboleth.sso/Status, /Shibboleth.sso/Metadata, registered it and
> logged in to a test page behind /secure/ (which is protected).

It is running, but your server is underresourced and can't handle metadata that large efficiently. The code isn't going to improve, it's not mine and it's not fixable. 2.6 includes a workaround that helps by allowing the system to load the backup file first and skip the signature check (on the theory it was checked to begin with to get there), which helps somewhat. Parsing it is still costly, but the big hit is the signature.

The real fix is to move to per-entity dynamic metadata lookup, which InCommon does not yet support in production. A non-federated SP of course has no reason to be using InCommon metadata to begin with, but assuming you are federated, there's not much else to be done. If you have to rely on the "list everybody" approach for IdP discovery also, then even the per-entity approach won't really help anyway, at least not by itself.

> Seems the portion "no TrustEngine specified or installed, using default
> chain {ExplicitKey, PKIX}² should mean something but I¹ve been unable to
> locate anything that works. No luck with Google.

Nothing to do with anything.

> I then discovered there is now an IdP only aggregate so I reconfigured the
> SP to use that with the following config:

I would expect that to help more. How much RAM are we talking about? 64-bit? 32-bit is essentially unusable now.

-- Scott




More information about the users mailing list