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 on the component itself,
the transport between components on the bus, etc.
I'm not sure if this is what you're looking for, but here are some
things I'd consider:
- SSL on HTTP to a binding component
- client certs with SSL on HTTP to a binding component
- HTTP Basic Auth on HTTP/HTTPS to a binding component
- Configuring which users are allowed to invoke a particular JBI
component instance
- Encrypting normalized messages between components on the bus,
particular for clustered servers where messages are going between
machines while still "on the network"
- Securing the XML that goes from an outside XML/SOAP message to a
normalized message and let a component decrypt/verify it itself (e.g.
WS-Security)
- If a user signs into a web app, allowing them to securely invoke
components on the bus without having to pass a separate username and
password to ServiceMix
- Like that, but allowing the security to go into the bus and out the
other side via an outbound binding component (perhaps using something
like CAS or Kerberos)
- Auditing connections to/from binding components and invocations to
components on the bus
Thanks,
Aaron
On 4/18/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> One of the important feature ServiceMix does not address yet is security.
> I' m not really familiar with this aspect so please forgive my
> ignorance and speak if you have any idea / corrections.
>
> Security can be applied in different areas:
> * secure transports
> * secure messages
> * secure services
>
> Securing transports can be done using SSL on JMS or HTTP. Securing
> the JMS broker is beyond ServiceMix scope, but ActiveMQ supports SSL
> on tcp transport. So this works fine for both the JMS binding
> component and any clustered flow. Securing HTTP will be done asap (we
> already have a patch, see
> http://issues.apache.org/activemq/browse/SM-372).
>
> Securing messages is not handled yet, but can be done using
> WS-Security on soap enabled transports (servicemix-jms and
> servicemix-http binding components). Is there a need to secure
> messages within the bus ?
>
> Securing services seems to be the most difficult part. The JMS specs
> only mention the use of the subject property on a NormalizedMessage
> http://java.sun.com/integration/1.0/docs/sdk/api/javax/jbi/messaging/NormalizedMessage.html#setSecuritySubject(javax.security.auth.Subject).
> The main problem is how to set / use this information and how
> informations about service authorizations.
> Such security informations may be embedded in the service unit /
> service assemblies deployment, or may be configured separately on the
> container. When a component sends a jbi exchange, the container
> could check the authorizations for the destination endpoint (or
> service, interface ?).
> However, I do not have any clue on how this information will be
> provided by binding components when an external message comes in. HTTP
> transport could leverage HTTP authentication, but what about the other
> transports ?
>
> All this security has also to be integrated with J2EE containers
> security when ServiceMix is deployed into such a container.
>
> Cheers,
> Guillaume Nodet
>
