Re: [Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP

[Graham Leggett via dev]

On 19 Mar 2020, at 12:26, Graham Leggett  wrote:On 19 Mar 2020, at 02:40, Eric Covener  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 thesession / 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-authenticatorRegards,Graham—

Re: [Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP

[Graham Leggett]

On 19 Mar 2020, at 02:40, Eric Covener mailto:cove...@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
—



smime.p7s
Description: S/MIME cryptographic signature

Re: [Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP

[Eric Covener]

On Wed, Mar 18, 2020 at 8:00 PM Graham Leggett  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.

[Patch] mod_auth_bearer / mod_autht_jwt: An alternative to AJP

[Graham Leggett]

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.

Regards,
Graham
—


mod_auth_bearer-mod_autht_jwt.patch
Description: Binary data


smime.p7s
Description: S/MIME cryptographic signature