<div dir="ltr"><div>Thanks Scot for the explanation,</div><div><br></div><div>One other thing which I thing will be useful is ......</div><div><br></div><div>For each such bean, if I want to know what are the relevant properties, where is the documentation on that?</div><div><br></div><div>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).</div><div><br></div><div>I am not sure current documentation leads(or refer) to that API level if I am not mistaken</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 13, 2017 at 11:55 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 4/12/17, 9:40 PM, "users on behalf of Lalith Jayaweera" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:ljayaweera@gmail.com">ljayaweera@gmail.com</a>> wrote:<br>
<br>
> Anyway does this mean any relying party configured in IdP 3.2.x can be accessed via below URL pattern as well,<br>
<br>
</span>You don't "access" relying parties.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.<wbr>net</a><br>
</div></div></blockquote></div><br></div>