UnsolicitedSSOConfiguration in relying party

[Lalith Jayaweera]

Thanks Scot for the explanation,

One other thing which I thing will be useful is ......

For each such bean, if I want to know what are the relevant properties,
where is the documentation on that?

especially when I am configuring things new in IdP 3.x, that will help us
to know what the relevant bean properties for each such beans (e.g. in
relyingparty or wherever).

I am not sure current documentation leads(or refer) to that API level if I
am not mistaken

On Thu, Apr 13, 2017 at 11:55 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
>
>
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170413/296fe269/attachment.html>