ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thilina Gunarathne" <cset...@gmail.com>
Subject Re: WS-Security
Date Sat, 29 Sep 2007 04:36:57 GMT
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 <csethil@gmail.com> 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 <bhamtaylor@gmail.com> 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

Mime
View raw message