<div dir="ltr">I've been testing the GEANT OIDC plugin for several months now.  <span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">We're using  IDP 3.3.3, Tomcat 8.5 and Oracle Java 8.   </span>We're using a check out from HEAD that still supports IDP 3.3.  We don't have all of the latest stuff, but it works well and have been able to resolve most of our issues.  <span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Janne and Henri have been very responsive when we've had questions or requests.  </span><div><br></div><div>Our testing has helped us identify some poorly behaved clients.  We've had a number of RPs that expect the default authentication method for the endpoints to be POST.  We know that most of our RPs (or rather their service owners) want the user's principal sent as the sub value.</div><div><br></div><div>I'd be happy to share our experience if anyone has questions.</div><div><br></div><div>Liam</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 11, 2018 at 1:19 PM, 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">Leaving aside the actual value put into the sub claim, you won't need any dedicated service to handle the pairwise or sector-wise IDs, I added that into the code just now.<br>
<br>
Just populate the sector ID from OIDC into AttributeResolutionContext.<wbr>attributeRecipientGroupID and the computed/stored plugins will do the right thing.<br>
<br>
This also opens up options for other resolver behavior or filtering plugins to operate based on the sector ID (I probably need to add this to the filter context too, I'll do that now).<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
<br>
-- <br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>