X509

[Vedran Bartonicek]

This clarified things (or I just think so :-), thanks.

Let's say that we will have ECP (I see that there are some implementations
available:  https://wiki.shibboleth.net/confluence/display/CONCEPT/ECP).
And let's say that we will have underlaying infra for certs (CA, chains etc)

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)
3) Container (Jetty, Tomcat) authenticates client cert, and let's the
request to /idp/profile/SAML2/SSO/Redirect
4) IdP returns IdP session cookie to ECP + redirects it  to SP
4) ECP gets SP session cookie and then proceeds to protected URL

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.





On 28 September 2016 at 15:54, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 9/28/16, 7:17 AM, "users on behalf of Vedran Bartonicek" <
> users-bounces at shibboleth.net on behalf of vbartoni at gmail.com> wrote:
>
> > It seems that we should also support X509 authentication - for clients
> that are not using
> > browser to access a protected resource.
>
> 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.
>
> 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.
>
> > I don't get here what happens after client gets authenticated?
>
> 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/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.
>
> 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.
>
> > What mechanisms are in place (maybe something that is not part of
> Shibboleth) to make sure
> > that the authenticated client can then do something (e.g. access some
> URL or something
> > else)
>
> 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.
>
> -- 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/20160929/cbcb5472/attachment.html>