[
https://issues.apache.org/jira/browse/CXF-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283722#comment-14283722
]
Niels Bertram commented on CXF-6206:
------------------------------------
The JAASAuthenticationFilter seems to fit the bill when used with a JAX-RS
endpoint. It nicely challenges with HTTP 401 until an authenticated subject is
provided. The JAASLoginInterceptor just throws a 500 server error with a XML
payload regardless of the HTTP Accept header of the resource consumer.
Under the hood the JAASAuthenticationFilter delegates authentication to the
JAASLoginInterceptor itself. But as discussed with Christian in the [Karaf
User
Forum|http://karaf.922171.n3.nabble.com/Security-Subject-from-AccessControlContext-is-null-when-using-JAAS-and-CXF-JAASAuthenticationFilter-td4037821.html],
the JAASAuthenticationFilter disables a feature on the JAASLoginInterceptor to
continuation execution of the exchange under a Privileged Action ( as in
Subject.doAs(...) ). This is hard wired in the filter and means that the filter
can never be used with any downstream code that relies on a properly populated
jaas AccessControlContext.
My question is, are there plans to get rid of the REST filters and use the
standard interceptors for rest services as well? If not, why can't we make the
JAASAuthenticationFilter configurable to support doAs() ?
If the JAASLoginInterceptor is to be enabled to support REST style auth
responses, it would also have to become content aware, as in understand the
Accept HTTP headers and what request method type is performed to be able to
craft the appropriate response. It would have to support at least these
scenarios:
* basic authentication of REST service ( content types application/json ...
application/xml )
* basic authentication on a JAXWS endpoint
* WSSE SOAP header used for authentication on JAXWS endpoint
Any thoughts?
BTW: I had a bit of a look around the WS-Security spec to see if it defines the
HTTP response codes for auth failure but not even the RFC 2616 was mentioned.
Which probably means that WSSE support is purely a protocol on top of the HTTP
stack and the HTTP server error 500 and a SOAP Fault would be sufficient to
signal an auth failure.
> JAASLoginInterceptor: Return proper unauthorized response when JAAS login
> with basic auth fails
> -----------------------------------------------------------------------------------------------
>
> Key: CXF-6206
> URL: https://issues.apache.org/jira/browse/CXF-6206
> Project: CXF
> Issue Type: Improvement
> Components: Core, Transports
> Reporter: Christian Schneider
> Assignee: Christian Schneider
> Fix For: 3.1.0
>
>
> Currently we return a Fault with a AuthenticationException when JAAS login
> fails.
> The proper response would be a 401 status with a suitable WWW-Authenticate
> header.
> I experimented with turning the AuthenticationException into a 401 response
> in the http transport. Not sure where to take auth type and realm from
> though. I am also not sure how to distinguish basic auth from WSS Security
> UsernameToken. As in the second case 401 is probably not correct.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
