<div dir="ltr">This clarified things (or I just think so :-), thanks.<div><br></div><div>Let's say that we will have ECP (I see that there are some implementations available:  <a href="https://wiki.shibboleth.net/confluence/display/CONCEPT/ECP">https://wiki.shibboleth.net/confluence/display/CONCEPT/ECP</a>).</div><div>And let's say that we will have underlaying infra for certs (CA, chains etc)</div><div><br></div><div>Is this what is happening (roughly)?</div><div>1) ECP makes request to protected URL at SP</div><div>2) ECP is redirected by SP to IdP for authentication (<span style="font-size:12.8px">/idp/profile/SAML2/SSO/</span><wbr style="font-size:12.8px"><span style="font-size:12.8px">Redirect)</span></div><div>3) Container (Jetty, Tomcat) authenticates client cert, and let's the request to /idp/profile/SAML2/SSO/Redirect</div><div>4) IdP returns IdP session cookie to ECP + redirects it  to SP </div><div>4) ECP gets SP session cookie and then proceeds to protected URL</div><div><br></div><div>But also this looks like not that good idea (at least using the ECP in stead of browser) since likely we will be on our own to implement and configure the whole thing.</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 September 2016 at 15:54, 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 class="">On 9/28/16, 7:17 AM, "users on behalf of Vedran Bartonicek" <<a href="mailto:users-bounces@shibboleth.net">users-bounces@shibboleth.net</a> on behalf of <a href="mailto:vbartoni@gmail.com">vbartoni@gmail.com</a>> wrote:<br>
<br>
> It seems that we should also support X509 authentication - for clients that are not using<br>
> browser to access a protected resource.<br>
<br>
</span>That really depends on the kinds of clients involved, X.509 is not a technology to deploy on a whim, and it is very complex to configure web servers to support it. If you haven't configured your web server to support it, then you need to start by going off and doing that and becoming familiar with the issues with that.<br>
<br>
Using a non-browser client is also not a use case for the standard flows, you would need to use the ECP support to do that.<br>
<span class=""><br>
> I don't get here what happens after client gets authenticated?<br>
<br>
</span>That's not about what happens after authentication, it's about how authentication is triggered. Using X509Internal means that a request for /idp/profile/SAML2/SSO/<wbr>Redirect (or whatever the path(s) are for SAML, I'm just typing from memory) has to be protected in the container by X.509 authn. Using X509 instead causes it to redirect first to a dedicated servlet path and only that path has to be protected by the container.<br>
<br>
There are issues I no longer understand around use of TLS renegotiation to handle client authentication on specific paths, and I am not the person to address the security trade-offs, usability trade-offs, or other issues with how to handle this feature.<br>
<span class=""><br>
> What mechanisms are in place (maybe something that is not part of Shibboleth) to make sure<br>
> that the authenticated client can then do something (e.g. access some URL or something<br>
> else)<br>
<br>
</span>That has nothing to do with how authentication is done. No matter what you do, the IdP is issuing a bearer token back to the client for use with the service hosting the resources. You need a SAML SP or a CAS client on the other end to utilize the IdP today.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Scott<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>
</font></span></blockquote></div><br></div>