UnsolicitedSSOConfiguration in relying party

[Cantor, Scott]

On 4/12/17, 9:40 PM, "users on behalf of Lalith Jayaweera" <users-bounces at shibboleth.net on behalf of ljayaweera at gmail.com> wrote:

> Anyway does this mean any relying party configured in IdP 3.2.x can be accessed via below URL pattern as well,

You don't "access" relying parties.

A relying party override is a set of rules for configuring behavior and enabling profiles when a request is handled. The system applies each override until one matches the request, and then it uses the settings in the override. That's it. Most overrides are based on the identity of the relying party. In V3 overrides can be based on essentially anything all the way down to time of day.

Unsolicited SSO is just a binding for invoking SAML 2 SSO and there's nothing materially different about it from any other binding, Redirect, POST, whatever. It's interchangeable from an unsigned AuthnRequest message from an SP and is handled identically. The SAML2.SSO profile bean in V3 is used to enable it and configure the settings, same as if a standard request was issued.

The old "provider" attribute in V2 that self-names the IdP is the "responderId" property in a V3 override and is largely unnecessary. V2 was a pain, because you have to repeat all kinds of settings in every override, but V3 tends to automate all that behind a bunch of Spring syntax you don't see and things like the entityID of the IdP are just automatically globally used.

The "id" attribute in V2 overrides means "the override applies if the RP has that entityID or is contained in that group". V3 is more explicit and the examples show how to define overrides based on the RP name or group if that's what you're doing.

-- Scott