X509

[Cantor, Scott]

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