Return-Path: 
 <users-return-214975-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 99877 invoked from network); 23 Jul 2010 07:26:59 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 23 Jul 2010 07:26:59 -0000
Received: (qmail 70383 invoked by uid 500); 23 Jul 2010 07:26:56 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 70173 invoked by uid 500); 23 Jul 2010 07:26:52 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 70163 invoked by uid 99); 23 Jul 2010 07:26:51 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Jul 2010 07:26:51 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Jul 2010 07:26:43 +0000
Received: from [192.168.245.235] (p549EA850.dip0.t-ipconnect.de
 [84.158.168.80])
	by tor.combios.es (Postfix) with ESMTPA id 7E4C422620D
	for <users@tomcat.apache.org>; Fri, 23 Jul 2010 09:24:18 +0200 (CEST)
Message-ID: <4C494404.6030006@ice-sa.com>
Date: Fri, 23 Jul 2010 09:25:56 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Spring security configuration in web.xml results in 403 error
References: <AANLkTinYkNgu53NnBw4-NpX0XexyREFQ9SnLY-kHAkDY@mail.gmail.com>
 <AANLkTinu7Csvwy2DpXaegOFNDCKO5v3hib9v-3kQ-0B2@mail.gmail.com>
In-Reply-To: <AANLkTinu7Csvwy2DpXaegOFNDCKO5v3hib9v-3kQ-0B2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ashish Jain wrote:
> any takers for this Q???
> 
> On Thu, Jul 15, 2010 at 1:38 PM, Ashish Jain <ashjain2@gmail.com> wrote:
> 
>> Hi,
>>
>> I have an application which uses non interactive login and hence utilizes
>> NONLogin Authenticator in tomcat. Here is a snippet from web.xml.
>>
>> <context-param>
>>         <param-name>contextConfigLocation</param-name>
>>         <param-value>/WEB-INF/applicationContext-security.xml</param-value>
>>     </context-param>
>>
>>     <filter>
>>         <filter-name>springSecurityFilterChain</filter-name>
>>
>> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
>>     </filter>
>>
>>     <filter-mapping>
>>         <filter-name>springSecurityFilterChain</filter-name>
>>         <url-pattern>/*</url-pattern>
>>     </filter-mapping>
>>
>>     <listener>
>>
>> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
>>     </listener>
>>
>> <login-config>
>>        <auth-method>NONE</auth-method>
>>        <realm-name>cas-authorize</realm-name>
>>     </login-config>
>>
>> <security-constraint>
>>         <web-resource-collection>
>>             <web-resource-name>Protect JSPs</web-resource-name>
>>             <url-pattern>*.jsp</url-pattern>
>>             </web-resource-collection>
>>         <auth-constraint>
>>             <role-name>testUsers</role-name>
>>         </auth-constraint>
>>     </security-constraint>
>>
>>     <security-role>
>>         <role-name>testUsers</role-name>
>>     </security-role>
>>
>> however I see that container security is invoked before any spring related
>> stuff. 

Exactly.  It is not specific to to spring.  The container security is invoked before even 
invoking the application, of which servlet filters are the first layer.

Since it is a Non interactive login Subject is not populated with any
>> principals
>> and hence tomcat is unable to authorize the access to resource. My Question
>> is
>>
>> How can I revert the security mechanism so that Spring security is invoked
>> before tomcat security.
>>

I don't think you can.  As they say in French, you can't have at the same time the butter, 
and the money of the butter.

If you want your first filter to be called in order to authenticate the user, then you'll 
have to remove the container security, and do your own security check in a second filter, 
invoked after the filter you already have has set the user-id.

Alternatively (but I don't know that part very well, so don't take my word for it), you 
would have to remove your first filter, and use/create a Realm which authenticates the 
user, which container-based security could then use.
See the standard
       <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
              resourceName="UserDatabase"/>
for an example.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org