SP v4 alpha2 testing

[Scott Cantor]

> On Jun 29, 2026, at 8:50 AM, Jarno Huuskonen via users <users at shibboleth.net> wrote:
> 
> Hello,
> 
> I'm testing testing SP v4 alpha2. (Use case would be shared hub for
> multiple existing SPs (all with different certs), some will use one
> IdP(p:authenticatingAuthority) and some will use
> discovery(p:discoveryService)).

As the documentation mentions, I don't see a whole lot of benefit in keeping different certificates at this point, which admittedly means that it's likely pointless to worry ahout preserving existing metadata contracts, even though that is supported. It was a goal, but at any scale, the key issue will make it moot.

The work involved to configure that at any scale right now dwarfs the work to update metadata in most cases. It's possible the configuration may evolve in a direction that makes key handling a bit better, but it's never going to be great since at minimum every single key pair is going to have to be Spring-defined somehow no matter what. Even a flat file of paths to keys or something is nobody's idea of fun if there are hundreds of them.

> Couple of things are not super clear: does the hub need metadata for
> existing SPs or just metadata for all IdPs (that SPs use for
> authentication) ? From what I understand from the docs, only IdPs
> metadata is needed ?

That is correct and is stated explicitly in the documentation.

The SP does not consume its own metadata (now or in V4), nor does the IdP, and they never will. Metadata is about exposing a curated configuration to peers, not accurately reflecting a system's own configuration at any point in time. They are, and must be, independent.

> Second thing that's not clear from hub docs is how to configure
> existing certs for agents, I can certainly copy cert/keys to
> /credentials/sp/, but so far I haven't figured out how to configure
> different cert/key for each agent.

We haven't documented it because it's a lot of work and beyond most people (I wouldn't even have attempted it). It is as bad as it is in the IdP to do that, so is essentially along the lines of
https://shibboleth.atlassian.net/wiki/spaces/IDP5/pages/3199508797/SecurityConfiguration

It's horrendous.

In practice, the design is for a single keypair and some "occasional" overrides based on the peer, not a key per system.

I have plans to do some kind of new service to resolve credentials that would improve matters a bit by separating the declaration of keys from how they get attached to systems, but it doesn't solve the problem of actually declaring 500 or 1000 keys in XML. That is step 1, and nobody wants to do that, nor should they.

We have to work out a solution for OpenID client secrets, but those are just passwords, so even if we come up with something there, it won't generalize that well to keys.

> Do I need to add all cert/keys as
> shibboleth.sp.EncryptionCredentials in sp/saml-credentials.xml then
> somehow configure each for each agent ?

You would (even if it changes, there would be an essentially equivalent file) and you rightly would not want to.

Re: crash

> There's probably something really basic missing ? Is it trying to
> figure out SP's entityID or AssertionConsumerService Binding ?
> 
> Any hints / which logger should help figure out what's the problem ?

It's a bug, but I'll have to poke further to figure out where/why or if something is missing. An NPE is always a bug, logging is only going to go so far in identifying that kind of thing. "pk" sounds key-ish but it's probably a variable name and may not be what it sounds like.

Thanks,
-- Scott