Return-Path: Delivered-To: apmail-ode-dev-archive@www.apache.org Received: (qmail 51523 invoked from network); 29 Sep 2007 04:37:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Sep 2007 04:37:28 -0000 Received: (qmail 22850 invoked by uid 500); 29 Sep 2007 04:37:18 -0000 Delivered-To: apmail-ode-dev-archive@ode.apache.org Received: (qmail 22832 invoked by uid 500); 29 Sep 2007 04:37:18 -0000 Mailing-List: contact dev-help@ode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ode.apache.org Delivered-To: mailing list dev@ode.apache.org Received: (qmail 22822 invoked by uid 99); 29 Sep 2007 04:37:18 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 28 Sep 2007 21:37:17 -0700 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 csethil@gmail.com designates 64.233.162.237 as permitted sender) Received: from [64.233.162.237] (HELO nz-out-0506.google.com) (64.233.162.237) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 29 Sep 2007 04:37:19 +0000 Received: by nz-out-0506.google.com with SMTP id z3so1892260nzf for ; Fri, 28 Sep 2007 21:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=d1ufJ9GQWkBNFtAzfBjFR7iDRifZfAsZNQnes3fXw0A=; b=rwRCapgL4KQ4NJSDql+MiS0TY2Qkaw/KCDUt+qruU1gGtHzQqyEeaSVEvCLv+OYfZ2ZivqnCD62GOu1mWIupHXMXB+v+AbUF8eLS6abvUyCH9W6fEeSoTAmkoXn7UbWFTGQ0v/VWXLwD6I8xcbkLpolrohQYfCXQNog6XUxJ0XQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OP8Ezl9lrP26c6CgS0D8u7OpvvwfUyB1QrVGzPcjVPtSipkmM6wYZuoOxk5RGHrZSYNDzdOixNjRjwnNw1aVf+6myIfVU9T39P++OqClAl4ahD7KISuOBKskgPr+fx5RQhM2SmapdTXbwHY9QfWwfKjAp8GxrKlc+6+50v5ZsiE= Received: by 10.114.193.1 with SMTP id q1mr1713298waf.1191040617691; Fri, 28 Sep 2007 21:36:57 -0700 (PDT) Received: by 10.115.93.8 with HTTP; Fri, 28 Sep 2007 21:36:57 -0700 (PDT) Message-ID: Date: Fri, 28 Sep 2007 23:36:57 -0500 From: "Thilina Gunarathne" To: "Matthieu Riou" Subject: Re: WS-Security Cc: dev@ode.apache.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5582dd3b0709271228s73490864o8be7540e60bc007d@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Hi, I think our first action item would be to get the per-process axis configuration in place. We would be able to use almost all the Axis2 modules in the invocation path (for receive activities) of the process when we have that correctly in place. Then we would need to figure out a mechanism to specify the configurations (module engagements/parameter) in the outgoing path from the server (invoke activities). AFAIKS this would require more work than the previous one, as we can't use the services.xml functionality to specify those. > 1. How do someone gets the authorization to invoke a given process and how > do that process gets the authorization to invoke another service, assuming > that the process itself is oblivious of this machinery. Propagating of authentication information would be bit tricky.. We will need a mechanism to share information between the in path and the out path. One way to achieve would be to use the same serviceContext of the process or the configContext in the out path unless we figure out a mechanism to propagate it through ODE. > In this scenario > there's nothing much to do at the engine level as authentication is handled > by the integration layer (axis2). A simple endpoint/credential mapping could > do the trick. The only issue I see is per-process configuration which could > be handled either by extending our configuration descriptor or including and > loading an Axis2 service.xml as part of the deployment unit. > 2. How does a process gets aware of credentials and authorizations and > manipulates them. Here we have more work and discussion to do (perhaps > someone could draft a proposal that we could iterate upon?) as this will > most probably require BPEL extensions. May be I did not understand what you meant.. But do we really need the process to be aware of the credential or authorizations. I feel those needs to be handled by the configuration or through a mechanism like ws-policy. thanks, Thilina > > I think we should address 1 first and then extend it to allow 2 once we're > ready. What do you think? > > Matthieu > > > On 9/28/07, Thilina Gunarathne wrote: > > Hi guys, > > This is where I'm also interested in (Deep integration with Axis2)... > > Please let us know the plans, so that we can also contribute some > > cycles.. > > > > thanks, > > Thilina > > > > On 9/27/07, Alex Boisvert < boisvert@intalio.com> wrote: > > > On 9/27/07, Rich Taylor wrote: > > > > > > > > I'm interested in using WS-Security with Ode in the Axis2 distro. I > see > > > > that Axis2 supports WS-Security via the Rampart project. Has anyone > > > > successfully utilized WS-Security with Ode? I'm interested in using > > > > WS-Security to secure incoming messages to Ode (receives etc.) as well > as > > > > outgoing messages (invokes). In particular I'm just interested the > > > > UsernameToken profile. > > > > > > > > > For what it's worth, I haven't heard any success stories yet :) > > > > > > > > > If not, how are others securing their processes and calling into secured > web > > > > services from their process? Do people use proxies for this sort of > > > > thing? > > > > > > > > > What I see most is 1) HTTP Authentication and/or 2) passing a (custom) > > > security token inside the message header or body and doing explicit > checks > > > in the process and in subordinate services. > > > > > > I did see the recent security discussion, but 1 I'm wondering how people > are > > > > presently securing their processes and calling secure services and 2. > I'm > > > > not sure I understood what the conclusion was in the end of that > thread. > > > > > > > > > The conclusion for me is that we have a lot of work ahead and we still > need > > > to reconcile our understandings in order to move forward. I see better > > > Axis2 integration (deploying services.xml inside the process package) as > > > being a first step in the right direction since you can then secure your > > > process without any impact on the process itself (external policy). The > > > next step would be to propagate the security context into the process so > > > it's accessible for further propagation to services. This is where it > gets > > > interesting because we haven't agreed on how to represent and manipulate > the > > > security context in the process. There is interest in separating it > from > > > the partnerLink. > > > > > > alex > > > > > > > > > -- > > Thilina Gunarathne - http://thilinag.blogspot.com > > > > -- Thilina Gunarathne - http://thilinag.blogspot.com