X509

[Vedran Bartonicek]

Thank you for the explanations, it helped us a lot to understand better
this flow.
-Vedran


On 29 September 2016 at 14:49, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 9/29/16, 2:47 AM, "users on behalf of Vedran Bartonicek" <
> users-bounces at shibboleth.net on behalf of vbartoni at gmail.com> wrote:
>
> > Is this what is happening (roughly)?
> >    1) ECP makes request to protected URL at SP
> >    2) ECP is redirected by SP to IdP for authentication
> (/idp/profile/SAML2/SSO/Redirect)
>
> No, it's redirected to the SOAP SSO endpoint that implements the ECP
> profile. It's also not a redirect, the client is a SOAP intermediary that
> has to know what that endpoint is.
>
> >    3) Container (Jetty, Tomcat) authenticates client cert, and let's the
> request to
> > /idp/profile/SAML2/SSO/Redirect
>
> Excepting that that's not the right path, yes.
>
> >    4) IdP returns IdP session cookie to ECP + redirects it  to SP
>
> Again, no redirect.
>
> Otherwise, basically that's true.
>
> > 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.
>
> I have no idea what you do or don't need to implement, but you have no
> business using a browser binding/profile for a non-browser client unless
> you control the client and the IdP. Screen scraping is a bad idea, but if
> you control both ends, you're in control of whether it works and stays
> working. What makes it a bad idea is that people who control both ends
> still end up breaking screen scraping clients because they don't even
> realize what they've done.
>
> -- 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/20160930/efb551d3/attachment.html>