[
https://issues.apache.org/jira/browse/QPID-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15075506#comment-15075506
]
Rob Godfrey commented on QPID-6965:
-----------------------------------
I've added a new Pluggable service - implementations of
org.apache.qpid.server.management.plugin.HttpRequestPreemptiveAuthenticator.
If a request comes in without authentication then all implementations of this
are tried and the first one to return a non null Subject is taken as the
authenticated Subject - if all instances return null, then no authentication
was possible.
There are currently implementations for BasicAuth, SSL Client Certs and
"Anonymous" - each check the authentication provider in user and (if necessary)
details of the request.
One mechanism for authentication which was previously present has been
deliberately omitted, the following code:
{code}
String remoteUser = request.getRemoteUser();
if (remoteUser != null || authenticationProvider instanceof
AnonymousAuthenticationManager)
{
subject = authenticateUser(subjectCreator, remoteUser, null);
}
{code}
previously created an Authenticated user where the request getUser() method
returned non null. I believe that if an instance wants to use the user set by
a proxy server or similar then we should have a specific AuthenticationProvider
type which uses this as the mechanism for getting the Authenticated Principal,
and we can then provide a HttpRequestPreemptiveAuthenticator that works with
that AuthenticationProvider
> Make preemptive HTTP authentication pluggable
> ---------------------------------------------
>
> Key: QPID-6965
> URL: https://issues.apache.org/jira/browse/QPID-6965
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
>
> Currently the HTTP module includes the ability to support a preemptive
> {{Authorization: Basic-Auth <base64>}} authentication. (This is one where
> the client's request includes the Basic-Auth header providing correctly
> encoded credentials allowing the client's interaction with the Broker to be
> 'single-shot', without the need to separately authenticate a session). This
> is very useful when scripting with tools such as {{curl}}.
> This ability should be generalised so that other types of preemptive
> authentication can be supported too. One example would be a OAUTH's bearer
> authorization header {{Authorization: Bearer <token}}. See
> [https://tools.ietf.org/html/rfc6750#page-5].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
