idpv4 SAMLAuthnConfiguration customization

[Cantor, Scott]

On 4/29/20, 9:49 AM, "users on behalf of Francesco Malvezzi" <users-bounces at shibboleth.net on behalf of francesco.malvezzi at unimore.it> wrote:

> Documentation says the SP entityID is customizable: can you point me to
> a link?

You use the same settings used in the other direction: a RelyingParty override with a SAML2.SSO profile configuration with settings that you want to change. For the entityID, you set p:responderId in the RelyingParty override itself (the name is historical obviously).

Any bean with a parent="RelyingParty" is implicitly setting p:responderId="#{getObject('entityID')}" which is a system bean wired up with the value of the idp.entityID property. That's how the defaulting is done. Overriding it is just p:responderId="whatever".

> How far customization can be pushed? May I mimic the shibboleth-sp sessionInitiator to define AuthnRequest [1]?

There is nothing analagous to a session initiator. The settings come from the profile configuration beans as in the outbound direction, and/or via functions and predicates for more dynamic or scripted behavior, or via metadata tags to use the metadata-driven configuration approach. In this case, tags in the proxied IdP's metadata.

Just flip your brain around and everything that applies in the normal direction tends to work the same way in the other.

>  Can I provide another different certificate for the SP part (I would like to spare me
> another metadata registration because in the use case I am thinking of
> it is time-consuming),

Security configuration wiring is complex and ugly because it's heavily nested, but the mechanism is again the same in both directions and is described in the documentation under SecurityConfiguration with examples of using specific credentials.

However, note that the credential needed as an SP is generally for encryption and the IdP already has an encryption certificate that is generally unused anyway, so that's likely what you'd want to use for the SP role, which it will automatically attempt tp use by default for decryption. There's no reason to sign anything because we don't have logout support upstream yet anyway.

-- Scott