Mailing List Archive

On Wed, Mar 18, 2020 at 8:00 PM Graham Leggett <minfrin@sharp.fm> wrote:
>
> Hi all,
>
> With support for AJP becoming scarce, there has been a need to get information from an Apache httpd to a backend server (Tomcat, etc) in a secure way.
>
> The following patch introduces two new modules:
>
> - mod_auth_bearer: This provides bearer authentication, as described in RFC6750. A token can be received by Apache httpd, and accepted if recognised, and in addition a token can be generated by httpd, and sent to a backend server. This allows the details of a digital certificate to be passed securely to the backend, when the digital certificate has been terminated by httpd.
>
> - mod_autht_jwt: RFC6750 does not mandate the type of token used, it can be anything. One such token supported is JWT, as implemented in mod_autht_jwt. We can verify incoming JWT tokens, and we can sign outgoing JWT tokens today using HS256, with more algorithms to come.
>
> We introduce a new type of auth module: autht for authenticating tokens. A token can carry usernames, or IP addresses, or any metadata that might subsequently be used by authn or authz.
>
> We depend on apr_jose support in apr-util v1.7, which in turn depends on secure apr_json support, and apr_crypto hashing functions.
>
> This work (in APR and httpd) has been sponsored by NLNet as part of the Redwax Project at https://redwax.eu.
>
> Example configuration to accept a token:
>
> AuthType bearer
> AuthName example-name
> AuthBearerProvider jwt
> AuthtJwtVerify hs256 file /Users/minfrin/src/apache/sandbox/proxy/conf/secret
> Require valid-user
>
> Example configuration to send a token to a proxy backend:
>
> AuthBearerProxy %{JWT_TOKEN}
> AuthtJwtClaim set sub %{REMOTE_USER}
> AuthtJwtSign hs256 file /Users/minfrin/src/apache/sandbox/proxy/conf/secret
>
> Work still to be done includes porting this to trunk, as well as documenting it properly. This will follow.

Neat, have you thought about mod_auth_form in relation to this?
Something on my wishlist has been to not put the password in the
session / not continue to call the original auth provider.

On 19 Mar 2020, at 02:40, Eric Covener <covener@gmail.com <mailto:covener@gmail.com>> wrote:

> Neat, have you thought about mod_auth_form in relation to this?
> Something on my wishlist has been to not put the password in the
> session / not continue to call the original auth provider.

Yes - the two modules that will benefit from token support are mod_session (which mod_auth_form is just one possible “onramp” to obtain a session token), and mod_ssl, where the token is the cert.

There is the addition of the (non backportable, but optional and we can leave it out of the backport) check_user() provider function, which allows a user in token to be checked if they still exist. The token being verified as valid is the “password”, leaving just the request to verify whether the user exists. This lets us remove the “the password is set to ‘password’” hack on mod_ssl, that makes life difficult if you want to support certs and passwords during a transition period, or certs for mobile apps and passwords for the web.

typedef struct {
/* Given a username and password, expected to return AUTH_GRANTED
* if we can validate this user/password combination.
*
* Use with AUTHN_PROVIDER_VERSION / AUTHN_PROVIDER_VERSION1 providers.
*/
authn_status (*check_password)(request_rec *r, const char *user,
const char *password);

/* Given a user and realm, expected to return AUTH_USER_FOUND if we
* can find a md5 hash of 'user:realm:password'
*
* Use with AUTHN_PROVIDER_VERSION / AUTHN_PROVIDER_VERSION1 providers.
*/
authn_status (*get_realm_hash)(request_rec *r, const char *user,
const char *realm, char **rethash);
/* Given a username, expected to return AUTH_GRANTED
* if we can validate this user exists.
*/
authn_status (*check_user)(request_rec *r, const char *user);

} authn_provider;

The main problem being solved (and the thing that kicked all of this off) was that one of the Atlassian products said “we no longer support AJP” which was being used to make certs work. We went “eek” and all of this became a thing.

Regards,
Graham
—

On 19 Mar 2020, at 12:26, Graham Leggett <minfrin@sharp.fm> wrote:

On 19 Mar 2020, at 02:40, Eric Covener <covener@gmail.com> wrote:

Neat, have you thought about mod_auth_form in relation to this?
Something on my wishlist has been to not put the password in the
session / not continue to call the original auth provider.

Yes - the two modules that will benefit from token support are mod_session (which mod_auth_form is just one possible “onramp” to obtain a session token), and mod_ssl, where the token is the cert.

Getting back to this.
Added in r1909409 and r1909411.
There is a corresponding library for tomcat that allows it to receive bearer auth here: https://github.com/minfrin/tomcat-jwt-authenticator"]https://github.com/minfrin/tomcat-jwt-authenticator
Regards,Graham—