Return-Path: X-Original-To: apmail-cxf-issues-archive@www.apache.org Delivered-To: apmail-cxf-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 51C6710428 for ; Tue, 20 Jan 2015 12:28:35 +0000 (UTC) Received: (qmail 11941 invoked by uid 500); 20 Jan 2015 12:28:35 -0000 Delivered-To: apmail-cxf-issues-archive@cxf.apache.org Received: (qmail 11905 invoked by uid 500); 20 Jan 2015 12:28:35 -0000 Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list issues@cxf.apache.org Received: (qmail 11894 invoked by uid 99); 20 Jan 2015 12:28:35 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 20 Jan 2015 12:28:35 +0000 Date: Tue, 20 Jan 2015 12:28:35 +0000 (UTC) From: "Christian Schneider (JIRA)" To: issues@cxf.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (CXF-6206) JAASLoginInterceptor: Return proper unauthorized response when JAAS login with basic auth fails MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CXF-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283771#comment-14283771 ] Christian Schneider commented on CXF-6206: ------------------------------------------ I agree that a SOAP Fault and a 500 response code should be good for WS-Security. So probably we do not need any special handling for it as this is the default handling of exceptions anyway. I also think that we should make REST work with Subject.doAs() as only then further security processing based on a JAAS login can occur. Depending how difficult this is to do with the current REST implementation this can take a while though. So it would be great if Sergey or anyone else familiar with our rest impl can make this happen. I do not know enough about it to do that myself. About standardizing the JAAS security. I agree with Niels that it would be nice to have it in one place. So you can simply add the JAASLoginFeature to e.g. the bus and have SOAP as well as REST secured with it. Of course Sergey is also correct that the JAASLoginInterceptor should not become much more complicated. What I could imagine is that we simply limit and define exactly what JAASLoginInterceptor is responsible for. What I could imagine is that it only forwards existing credentials from the cxf message to JAAS and produces defined exceptions in case of failures. Collecting the credentials as well as converting the exception to a response should be done outside the JAASLoginInterceptor. I think with these limitations it should stay fairly simple while still being the central place to do the JAAS handling. > 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)