Should be able to specify whether a plugin acts a Proxy-Level Authentication or direct Authentication

[ahmadnassri]

right now all the authentication plugins (basic, oauth) are using the Authorization header, I should be able to customize that header, at the very least, I should be able to configure it to use Proxy-Authorization in case I want to maintain my own authentication scheme in my API service.

[subnetmarco]

How about checking if Proxy-Authentication exists first. If it doesn't, fall back to Authorization ?

[ahmadnassri]

How about checking if Proxy-Authentication exists first. If it doesn't, fall back to Authorization ?

not sure how that's even related!?

this should be a choice by the operator to decide what level of Authentication to apply, and with #462 should be able to apply both if wanted.

[ahmadnassri]

currently the behavior for oAuth and Basic Auth is only enabled on the Authorization header.

• I want to enable any of the Kong authentication plugins on `Proxy-Authorization
• I want to enable any of the Kong authentication plugins on a custom authorization header e.g. X-Authorization, MY-APP-Authorization, Kong-Authorization, etc ..

only the keyauth plugin currently allows to customize the header field value ... but that's by nature of the plugin itself, which is a none-standard authorization flow.

[subnetmarco]

Basic Authentication cannot have an arbitrary header because it violates the spec: http://tools.ietf.org/html/rfc1945#section-10.2

Same thing for OAuth 2.0: http://tools.ietf.org/html/rfc6749

[subnetmarco]

not sure how that's even related!?

It is, since it's a very well standard behavior documented in the spec http://tools.ietf.org/html/rfc2617#section-3.6

We cannot arbitrary translate how HTTP works.

[ahmadnassri]

Authorization and Proxy-Authorizaton are interchangeable.

also, allowing to setup a custom X-Authorization header is also common practice, specifically for namespacing applications and services beyond the standard authorization flow, also allows for combining authorizations, e.g. this is valid:

Proxy-Authorization for authenticating on proxy level, followed by Service-Authorization for authorization with service provider / applciation developer, followed by Authorization for authenticating the user.

also, the oAuth spec does not even specify a specific header name

[ahmadnassri]

also, RFC 2617 is outdated, please stop referring to it and checkout RFC 7235 http://httpwg.github.io/specs/rfc7235.html#challenge.and.response

[ahmadnassri]

We cannot arbitrary translate how HTTP works.

again, not the point. the focus here is to allow enabling authentication plugins for proxy level separately from request level.

the operator should have the choice to use Kong for either, or both, while retaining any existing authentication in the API service behind Kong.

[subnetmarco]

X-Authorization is being deprecated by another proposal because it starts with X- which is also one thing you asked #324.

Proxy-Authorization for authenticating on proxy level, followed by Service-Authorization for authorization with service provider / applciation developer, followed by Authorization for authenticating the user.

That's what I recommended doing: check for a Proxy-Authorization header first, and only then check for Authorization, so we handle both scenarios (with or without an additional backend Basic Authentication).

[subnetmarco]

As per OAuth 2.0, it's in the spec: http://tools.ietf.org/html/rfc6749#section-2.3.1

Clients in possession of a client password MAY use the HTTP Basic
authentication scheme as defined in [RFC2617] to authenticate with
the authorization server.

[ahmadnassri]

"May"

[ahmadnassri]

X-Authorization used an example of customizing Authorization header name, MY-APP-Authorization was also used as an example...

this is standard practice for namespacing headers, X- it self was deprecated because it was not specific to an application domain.

for example: VMWare uses X-VCloud-Authorization as a tokenized header for authentication.

[subnetmarco]

If you need something like X-VCloud-Authorization then the keyauth plugin can be used.

• Basic Authentication: We cannot change the header or we will break the specification
• OAuth 2.0: You are interpreting MAY in the wrong way. OAuth 2.0 clients can send the credentials in the request body, or MAY use Basic Authentication if that's not an option. "MAY" as in "MAY use Basic Authentication as opposed to using the body", not as in "MAY use Basic Authentication or other headers".

So to answer the original question:

I should be able to customize that header

It can be done using the Key Authentication plugin. It's not allowed in the Basic Authentication or OAuth 2.0 plugins by specification.

I should be able to configure it to use Proxy-Authorization in case I want to maintain my own authentication scheme in my API service.

This is correct. We need to add support for Proxy-Authorization if it's being sent along with the request when the Basic Authentication plugin is enabled.

[ahmadnassri]

think of "namespaceing" as the key term here ...

I want to namespace the oauth header, the spec still applies, but I want to namespace it.

hence MY-APP-Authorization

a relatable example would be Mashape Marketplace, an API could already have oauth on Authorization and the marketplace authentication could also be through oauth by namespacing: Mashape-Authorization hence two oauth credentials can be used for different purposes using the same standard (in this case oauth)

[subnetmarco]

I want to namespace the oauth header, the spec still applies, but I want to namespace it.

Basic Authentication does not allow namespacing in the specification, and because OAuth 2.0 mentions Basic Authentication, then OAuth 2.0 doesn't support namespacing of the Authorization header.

Happy to reconsider this if you prove me wrong.

The client is expected to retry the request, passing an Authorization header line, which is defined according to the framework above, utilized as follows.

https://tools.ietf.org/html/rfc2617#section-3.2.2

[sonicaghi]

Lets address this once we're past v. 0.5 and 0.6 since it's not in the current roadmap. If the spec is still valid, and it's just a different header name than is no brainer.

[subnetmarco]

If the spec is still valid, and it's just a different header name than is no brainer.

A different header name for Basic Authentication will invalidate the spec. As far as I am concerned this issue can be closed, but as I said I will be happy to reconsider it if proven wrong.

I am pushing support for Proxy-Authorization soon.