[TIP] Apache module to authenticate a NativeSPApacheConfig to the backend app and sign attributes

[Tom Noonan]

> So no confidentiality (encryption)?

No, no encryption, that's outside the scope of JWTs.  JWTs are
basically simple envelops designed to securely represent claims
between parties in a URL-safe fashion.  They are just base64 encoded
JSON for the JWT header and the claim payload, with an optional
signature that can be used to ensure the data came from the expected
source.  If confidentially is desired the recommendation is to encrypt
the connection, using https in this example, so all the data is
encrypted.  (I can't quickly find this recommendation in writing, but
it's the consensus I've gathered from research and presentations on
JWTs.)  Encrypting the traffic between processes isn't really a JWT
concern anyway, as if confidentially is needed between the proxy and
the backend server then that should be set up regardless of using JWTs
or not.  So connection encryption and confidentiality is something
that would need to be taken into account and resolved regardless of
using mod_proxy_jwt_auth.

> How about key rollover for the signing key, with potentially dozens (or more) of JWT "clients"?

This is something that would need to be solved for the needs of the
deployment and environment.  This isn't much different then rolling
SSL keys when using client SSL certificates for authorization.  JWTs
themselves don't have any rollover mechanism, they're just signed with
the key given.  In an environment where shib and the backend server(s)
are loosely coupled then this may be a challenge, if the certificates
don't match with signing on then the backend server should reject the
connection.  How to solve this depends on the deployment and tools in
use.  The backend application could be programmed to check the JWTs
against multiple keys, allowing for multiple signing keys to be live
without downtime.  Tools like Ansible/Chef/Puppet could be used to
roll the keys rapidly so only a small number of connections fail
during rollover.  In our environment we tightly couple Shib to the
backend, despite using HTTP over TCP between Apache and the backend,
so we just have our deployment tool generate a keypair for the
container configuration when we deploy.

These are all great things to call out and need to be considered,
thanks for mentioning them.  When deciding to use this tool the cost
of this complexity needs to be taken into account vs other solutions.
As mentioned in other posts there are other ways to solve the concerns
this module addresses, such as having Apache fork the backend and/or
using Unix sockets to prevent the backend server from accepting
connections in an insecure fashion.  I believe mod_proxy_jwt_auth is
useful when proxying to the backend over any TCP protocol as it allows
the backend app to ensure the request came from the expected Apache
server, not from some other unexpected process hitting the listener.
When using mod_proxy_jwt_auth I expect then deploying engineer to have
their own reasons for wanting to use TCP between Apache and the
backend where the negatives of key management and confidentially are
outweighed by their environment-specific concerns.  mod_proxy_jwt_auth
is intended to help make that configuration more secure.
--Tom Noonan II


On Fri, May 4, 2018 at 5:22 AM, Peter Schober
<peter.schober at univie.ac.at> wrote:
> * Tom Noonan <tom at joinroot.com> [2018-05-03 18:22]:
>> - mod_proxy_jwt_auth will add Shibboleth environment variables to
>> the token and sign them.  When signature verification is on then the
>> backend server can be confident the header variables are not
>> spoofed.
>
> So no confidentiality (encryption)?
> How about key rollover for the signing key, with potentially dozens
> (or more) of JWT "clients"?
> -peter
> --
> For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net