<div dir="ltr">Hi again Peter,<div>   I'd like to share our solution which is based on you suggestion (thanks!) in the hope it's of some use to others.</div><div>   - configure an External flow to capture the EntityID and then redirect to protected servlet using the "previous" auth filter</div><div>   - previous auth filter uses entityID to login and authorization using entitiy ID and then redirects to External-part2</div><div>   - External-part2 uses th user principal to complete the shibboleth login</div><div><br></div><div>        thanks everyone,</div><div>                           -Simone</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-10-16 14:59 GMT+02:00 Simone Avogadro <span dir="ltr"><<a href="mailto:simone.avogadro@gmail.com" target="_blank">simone.avogadro@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">thanks Peter,<div>  technically we're using RemoteUserInternal (<a href="https://wiki.shibboleth.net/confluence/display/IDP30/RemoteUserInternalAuthnConfiguration" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP30/RemoteUserInternalAuthnConfiguration</a>) with success because this is exactly what we're doing (providing a java.security.Principal via a container-provided auth) with the exception of EntityID.</div><div> Our problem is that our implementation of the container auth requires the EntityID of the requesting SP.</div><div> Implementing ExternalAuthn seems way more complicated (keep in mind that we already have RemoteUserInternal implemented from v2!) so I wander if this will provide us the EntityID of the calling SP  (I know... this also imply renouncing IDP-provided SSO but this is already ok)</div><div> Did you already use ExternalAuth? </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>          -Simone</div><div>  </div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-10-16 14:38 GMT+02:00 Peter Schober <span dir="ltr"><<a href="mailto:peter.schober@univie.ac.at" target="_blank">peter.schober@univie.ac.at</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">* Simone Avogadro <<a href="mailto:simone.avogadro@gmail.com" target="_blank">simone.avogadro@gmail.com</a>> [2015-10-16 13:57]:<br>
<span>>   Our custom authentication is basically a servlet filter which sits on top<br>
> of:<br>
><br>
</span>>    - /Authn/*<br>
>    - /profile/SAML2/Unsolicited/SSO<br>
>    - /profile/SAML2/Redirect/SSO<br>
<span>><br>
>  and wraps request/response to provide a Principal<br>
<br>
</span>I think the proper way to do this was the "external authentication"<br>
mechanis, both for v2 and v3. The docs for v3 are here:<br>
<a href="https://wiki.shibboleth.net/confluence/display/IDP30/ExternalAuthnConfiguration" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/display/IDP30/ExternalAuthnConfiguration</a><br>
<span><font color="#888888">-peter<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>