Please find my comments inline.
-Original Message-
From: Guillaume Nodet [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 25, 2006 10:45 AM
To: servicemix-dev@geronimo.apache.org
Subject: Re: ServiceMix and security
The main problem of using a JBI component to provide security is that
The main problem of using a JBI component to provide security is that
when you use a clustered ServiceMix, JBI exchanges may go to the
security component using a clustered flow. In such a case, the
exchange will be sent on the wire in an unsecured / unauthenticated
way.
I have always thought that
On 4/19/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> On Apr 19, 2006, at 10:40 AM, Bruce Snyder wrote:
>
> > On 4/18/06, Hossam Karim <[EMAIL PROTECTED]> wrote:
> >> Just thinking:
> >> - Security is a service
> >> - A component installed inside SM can support a SM specific security
> >> contrac
I believe that the Subject should be used in some way to carry the
WS-Security envelope information. Then, some authentication mechanism is
responsible to check each message/invocation against the destination
endpoint policy. Each JBI component that has security requirements must
declare the polic
Just thinking:
- Security is a service
- A component installed inside SM can support a SM specific security
contract, in which a security provider implementing this contract can be
bound to one or more installed components. This provider can provide
authentication, digital signature verification, X
I think we need to separate security into a number of categories:
1) protecting the content (confidentiality and integrity)
2) authentication
3) authorization
4) auditing
5) single sign-on
So these can be applied at several levels -- the transport from
outside to binding component, the invocation
