Return-Path: Delivered-To: apmail-camel-users-archive@www.apache.org Received: (qmail 65220 invoked from network); 2 Apr 2010 14:38:53 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 2 Apr 2010 14:38:53 -0000 Received: (qmail 7041 invoked by uid 500); 2 Apr 2010 05:38:53 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 6956 invoked by uid 500); 2 Apr 2010 05:38:53 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 6948 invoked by uid 99); 2 Apr 2010 05:38:52 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Apr 2010 05:38:52 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=FREEMAIL_FROM,SPF_HELO_PASS,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Apr 2010 05:38:46 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1NxZaL-00062m-Al for users@camel.apache.org; Thu, 01 Apr 2010 22:38:25 -0700 Message-ID: <28116119.post@talk.nabble.com> Date: Thu, 1 Apr 2010 22:38:25 -0700 (PDT) From: jliu To: users@camel.apache.org Subject: Re: Camel security In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jervisliu@gmail.com References: <28106100.post@talk.nabble.com> <4BB4AB99.3070904@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Claus Ibsen-2 wrote: > > Its important that we do this in a manner so the security framework of > choice can easily be plugged in, as many have different needs. > And some are forced to use JAAS etc. > > So it should NOT be a Spring Security that master how we do this in Camel. > +1. Ideally the Camel security will be pluggable, so that ppl can plug different security implementations into Camel. For example, for Drools project, I may want to use Picketlink (http://www.jboss.org/picketlink) as the underlying authentication and authorization implementation. Other people may prefer Spring security or their own implementations. If we dig into technical details a little bit, I believe the authentication part should be straightforward. As long as JAAS is used, different authentication implementations can always be plugged in easily. The headache part is the authorization. There is no standard we can use in this area, and I am not sure how easy it is to write a framework that can plug in different authorization implementations. For example, it may not be possible to write an authorization framework that is flexible enough to switch its underlying impl among Picketlink Authz (http://www.jboss.org/picketlink/AuthZ.html) and the authorization part in Seam3 Security (http://www.seamframework.org/Seam3/SecurityModuleOverview) and the authorization part in Spring security. Mostly likely Camel will have to come out with its own specific authorization implementation or just choose an existing one. -- View this message in context: http://old.nabble.com/Camel-security-tp28106100p28116119.html Sent from the Camel - Users mailing list archive at Nabble.com.