You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2006/04/19 02:56:36 UTC
ServiceMix and security
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
Re: ServiceMix and security
Posted by Rafael Marins <ra...@exoplatform.com>.
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 policy in using WSDL extensions, specifying the ROLE.
I would prefer another JBI component to be created for handling &
managing the security mapping between endpoints and messages. Then, some
schema should be used to package security mapping activation in the bus
through service units.
Regards,
--
Rafael Marins
Guillaume Nodet 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
>
>
>
Re: ServiceMix and security
Posted by Dan Diephouse <da...@envoisolutions.com>.
Hiya Guillaume,
Some thoughts inlined...
Guillaume Nodet wrote:
> 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 ?
>
>
Could there be a situation where multiple users are using the bus and
they all have different levels of access? And also in that situation
could there be a message broadcast where only certain users have access
to the information? If so I think there may be some need for encrypted
messages.
> 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 ?
>
>
I think I see two ways we could set the SecuritySubject:
- At the configuration level, i.e. configuring the username/password in
the BC configuration
- The API of the Binding Component - say we have a BC which access a
service on the bus that needs the SecuritySubject. When the user
interacts with the API of the BC, they would need to provide their
security information. The BC would then be responsible for setting the
Subject on the NormalizedMessage
- Another option would be to do some sort of ThreadLocal type thing. If
a BC doesn't have a way to set the security info, we could always create
a custom API along the likes of
"SecurityContext.setCurrentSubject(subject)".
I also have been doing some thinking about WS-Security/Policy
integration. WS-Security is easy enough to hook in, we just need to wire
in XFire to listen for requests then pass on the messages to the bus.
I'm guess we can use the ws-sec security tokens and put those on the bus
as well? XFire But there is the whole problem that ws-sec just sucks and
is too damn slow, so I don't really like pushing it as a good option.
Also, it'd be really cool to just to write the policy or policy
fragments and have the endpoint in servicemix enforce that. So we can
require security or RM or whatever else real easily. Guess I need to get
off my arse and do some WS-Policy integration with XFire.
- Dan
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
Re: ServiceMix and security
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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 <gn...@gmail.com> 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
>
Re: ServiceMix and security
Posted by Guillaume Nodet <gn...@gmail.com>.
I do agree that we really need to separate 3 different security issues:
* authentication / authorization
* secure transport
* integrity of the message
In my previous mail, I was mainly talking about authentication / authorization.
Such authorizations could be configured on the ServiceMix container
using a static xml configuration file or dynamically using a JMX
mbean. Using some simple rules for granting access to a given
interface, service or endpoint should be feasible. ActiveMQ already
has such a feature to grant access to jms destinations using a simple
configuration mechanism.
When an exchange is sent by a component, the container could check the
given subject for an authorization (and even use the authorizations to
select a valid jbi endpoint when targeting an interface or service
name). Some components may also need to use the given subject to
access resources (http with authentication, acessing JEE resources),
but this is a problem specific to such a component.
I hope that such a mechanism (on the container side) could be
pluggable and integrated with the authentication mechanism provided by
the hosting JEE container.
A binding component will of course be responsible for securing its own
transport when possible: using https for the HTTP BC, ssl on tcp for
ActiveMQ (do not know of other JMS providers...). When using a
clustered flow, the underlying ActiveMQ broker can already be
configured to use SSL on the tcp transport.
The only way I am aware of to ensure integrity of the message is to
use ws-sec for soap messages, or the underlying xmldsig
(http://www.w3.org/TR/xmldsig-core/) for non-soap messages (problems
may arise on how to carry the needed informations). I still need to
read these specs...
This may be needed by binding components acting as consumers or
providers or clustered flows, as I do not really see the need of
securing informations that are not sent on the network. Such a
service may be implemented as a JBI component so that it can be used
by all components, but I do not see the real need for that yet. I
even doubt that there is a real need for using xmldsig without ws-sec:
using soap may be an acceptable limitation when you want to secure
messages and afaik this is the only way to be interoperable.
Clustered flows could be configured to use wsdsig directly, as they do
not need to interoperate with other components.
Cheers,
Guillaume Nodet
On 4/25/06, Hossam Karim <hr...@gmail.com> wrote:
> Please find my comments inline.
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> 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
> 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.
>
> Yes, this is true, but I believe this is not just a problem for ServiceMix
> only, any clustered application should provide the option of securing the
> network communication, like enabling SSL for example. I think ActiveMQ
> already supports that.
>
> I have always thought that security should be provided by the
> container. I would compare it to a web server which has built-in
> security to secure web applications. The application can always use a
> custom login / authentication scheme, but the prefered way is to
> delegate to the container (and implement a specific realm if needed),
> which is the only way to provide SSO afaik.
>
> Besides this, if security is handled by the container, it will be able
> to detect authorization failures earlier and even use them when
> implicit endpoint selection is used: if the jbi exchange target is an
> interface QName, the container could check matching endpoints for
> authorization instead of selecting one and having an authorization
> failure.
>
> There are two points here, we need to answer the question: What do we want
> to secure and who should be responsible for the security?
>
> - If we are concerned about providing a global security mechanism for
> accessing any of the ServiceMix bus services, then I think what you are
> proposing is exactly what is needed. I hope the specification would address
> this in its next version. Integrating with application servers' security
> would be a great selling point for ServiceMix here. But still, how would you
> do that? How would force all secured services with all their different
> protocols to follow your security model?
> Can you please illustrate more about the technical details you have in mind
> that can lead to implementing such feature?
>
> - If we are talking about securing the transport protocols and message
> contents, I don't think the application server's example is relevant.
> Artifacts that can be deployed to an application server and their deployment
> descriptors are standardized. So if you are deploying a web application or
> some EJBs to the server, you know exactly how to define your security. This
> is not possible for the JBI environment, because the idea of a BC, for
> example, is to support an arbitrary protocol, and if you don't know what the
> protocol is, you certainly don't know the best way to secure it. What I had
> in mind is to build a service which provides operations for XML normalized
> messages security and support for standard security algorithms.
>
>
> Last point, if security is provided by a component, all components
> will have to be rewritten so that they can leverage this feature. It
> seems much more interesting that security is provided transparently by
> the container...
>
> May be we can call it an enhancement not a complete rewriting. Say we can
> have interfaces - with callback methods - that mark a component
> implementation as secured, and helper classes that can be utilized by the
> component in the callbacks. Reminds me why some architects always implement
> the visitor and command patterns even if they have no current use :)
>
>
> I really think that container security is the most flexible and
> pluggable way to handle security as it is centralized.
>
> Any thoughts ?
>
> Cheers,
> Guillaume Nodet
>
> On 4/19/06, Hossam Karim <hr...@gmail.com> wrote:
> > 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, XML encryption and
> > decryption, integration with LDAP, etc.
> > - A component that has a security provider installed should delegate all
> > security operations to its provider.
> > - A component that has a security provider should provide additional
> > management operations through JMX to secure its lifecycle management.
> >
> > Hossam
> >
> >
> > -----Original Message-----
> > From: Guillaume Nodet [mailto:gnodet@gmail.com]
> > Sent: Wednesday, April 19, 2006 2:57 AM
> > To: servicemix-dev@geronimo.apache.org
> > Subject: ServiceMix and security
> >
> > 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/Normali
> > zedMessage.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
> >
> >
>
>
Re: ServiceMix and security
Posted by Antoni Reus <ar...@ibit.org>.
I think that you are right with your example of a web container.
JBI defines a container, just like a web container or a ejb container.
En/na Guillaume Nodet ha escrit:
>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 security should be provided by the
>container. I would compare it to a web server which has built-in
>security to secure web applications. The application can always use a
>custom login / authentication scheme, but the prefered way is to
>delegate to the container (and implement a specific realm if needed),
>which is the only way to provide SSO afaik.
>
>Besides this, if security is handled by the container, it will be able
>to detect authorization failures earlier and even use them when
>implicit endpoint selection is used: if the jbi exchange target is an
>interface QName, the container could check matching endpoints for
>authorization instead of selecting one and having an authorization
>failure.
>
>Last point, if security is provided by a component, all components
>will have to be rewritten so that they can leverage this feature. It
>seems much more interesting that security is provided transparently by
>the container...
>
>I really think that container security is the most flexible and
>pluggable way to handle security as it is centralized.
>
>Any thoughts ?
>
>Cheers,
>Guillaume Nodet
>
>On 4/19/06, Hossam Karim <hr...@gmail.com> wrote:
>
>
>>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, XML encryption and
>>decryption, integration with LDAP, etc.
>>- A component that has a security provider installed should delegate all
>>security operations to its provider.
>>- A component that has a security provider should provide additional
>>management operations through JMX to secure its lifecycle management.
>>
>>Hossam
>>
>>
>>-----Original Message-----
>>From: Guillaume Nodet [mailto:gnodet@gmail.com]
>>Sent: Wednesday, April 19, 2006 2:57 AM
>>To: servicemix-dev@geronimo.apache.org
>>Subject: ServiceMix and security
>>
>>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/Normali
>>zedMessage.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
>>
>>
>>
>>
>
>
>
>
--
----------------------------------------
Antoni Reus Darder
Cap de Projecte
Administració Digital, Negoci Electrònic i Sanitat
F u n d a c i ó I B I T
Illes Balears Innovació Tecnològica
http://www.ibit.org
Tel. +34 971 17 72 70/71
Fax. +34 971 17 72 79
----------------------------------------
RE: ServiceMix and security
Posted by Hossam Karim <hr...@gmail.com>.
Please find my comments inline.
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
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
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.
Yes, this is true, but I believe this is not just a problem for ServiceMix
only, any clustered application should provide the option of securing the
network communication, like enabling SSL for example. I think ActiveMQ
already supports that.
I have always thought that security should be provided by the
container. I would compare it to a web server which has built-in
security to secure web applications. The application can always use a
custom login / authentication scheme, but the prefered way is to
delegate to the container (and implement a specific realm if needed),
which is the only way to provide SSO afaik.
Besides this, if security is handled by the container, it will be able
to detect authorization failures earlier and even use them when
implicit endpoint selection is used: if the jbi exchange target is an
interface QName, the container could check matching endpoints for
authorization instead of selecting one and having an authorization
failure.
There are two points here, we need to answer the question: What do we want
to secure and who should be responsible for the security?
- If we are concerned about providing a global security mechanism for
accessing any of the ServiceMix bus services, then I think what you are
proposing is exactly what is needed. I hope the specification would address
this in its next version. Integrating with application servers' security
would be a great selling point for ServiceMix here. But still, how would you
do that? How would force all secured services with all their different
protocols to follow your security model?
Can you please illustrate more about the technical details you have in mind
that can lead to implementing such feature?
- If we are talking about securing the transport protocols and message
contents, I don't think the application server's example is relevant.
Artifacts that can be deployed to an application server and their deployment
descriptors are standardized. So if you are deploying a web application or
some EJBs to the server, you know exactly how to define your security. This
is not possible for the JBI environment, because the idea of a BC, for
example, is to support an arbitrary protocol, and if you don't know what the
protocol is, you certainly don't know the best way to secure it. What I had
in mind is to build a service which provides operations for XML normalized
messages security and support for standard security algorithms.
Last point, if security is provided by a component, all components
will have to be rewritten so that they can leverage this feature. It
seems much more interesting that security is provided transparently by
the container...
May be we can call it an enhancement not a complete rewriting. Say we can
have interfaces - with callback methods - that mark a component
implementation as secured, and helper classes that can be utilized by the
component in the callbacks. Reminds me why some architects always implement
the visitor and command patterns even if they have no current use :)
I really think that container security is the most flexible and
pluggable way to handle security as it is centralized.
Any thoughts ?
Cheers,
Guillaume Nodet
On 4/19/06, Hossam Karim <hr...@gmail.com> wrote:
> 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, XML encryption and
> decryption, integration with LDAP, etc.
> - A component that has a security provider installed should delegate all
> security operations to its provider.
> - A component that has a security provider should provide additional
> management operations through JMX to secure its lifecycle management.
>
> Hossam
>
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Wednesday, April 19, 2006 2:57 AM
> To: servicemix-dev@geronimo.apache.org
> Subject: ServiceMix and security
>
> 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/Normali
> zedMessage.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
>
>
Re: ServiceMix and security
Posted by Guillaume Nodet <gn...@gmail.com>.
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 security should be provided by the
container. I would compare it to a web server which has built-in
security to secure web applications. The application can always use a
custom login / authentication scheme, but the prefered way is to
delegate to the container (and implement a specific realm if needed),
which is the only way to provide SSO afaik.
Besides this, if security is handled by the container, it will be able
to detect authorization failures earlier and even use them when
implicit endpoint selection is used: if the jbi exchange target is an
interface QName, the container could check matching endpoints for
authorization instead of selecting one and having an authorization
failure.
Last point, if security is provided by a component, all components
will have to be rewritten so that they can leverage this feature. It
seems much more interesting that security is provided transparently by
the container...
I really think that container security is the most flexible and
pluggable way to handle security as it is centralized.
Any thoughts ?
Cheers,
Guillaume Nodet
On 4/19/06, Hossam Karim <hr...@gmail.com> wrote:
> 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, XML encryption and
> decryption, integration with LDAP, etc.
> - A component that has a security provider installed should delegate all
> security operations to its provider.
> - A component that has a security provider should provide additional
> management operations through JMX to secure its lifecycle management.
>
> Hossam
>
>
> -----Original Message-----
> From: Guillaume Nodet [mailto:gnodet@gmail.com]
> Sent: Wednesday, April 19, 2006 2:57 AM
> To: servicemix-dev@geronimo.apache.org
> Subject: ServiceMix and security
>
> 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/Normali
> zedMessage.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
>
>
Re: ServiceMix and security
Posted by Bruce Snyder <br...@gmail.com>.
On 4/19/06, Dain Sundstrom <da...@iq80.com> wrote:
> On Apr 19, 2006, at 10:40 AM, Bruce Snyder wrote:
>
> > On 4/18/06, Hossam Karim <hr...@gmail.com> wrote:
> >> 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, XML encryption and
> >> decryption, integration with LDAP, etc.
> >> - A component that has a security provider installed should
> >> delegate all
> >> security operations to its provider.
> >> - A component that has a security provider should provide additional
> >> management operations through JMX to secure its lifecycle management.
> >
> > Actually I agree with Hossam here. I've always considered that
> > security would be delegated to other components, not built into the
> > core of each component. This will allow a wider variation of security
> > models to be addressed and will also allow custom security components
> > to be created to address custom security models on a per enterprise
> > basis.
>
> When coding Geronimo, I have found that as soon as I say, "no one
> will ever do X" someone shows me a service doing just that, so my
> question is, how will ServiceMix handle components that have security
> "built into the core"?
Let's say we have a model where one component per security contract, I
expect that these security components would be wired together via the
XBean configuration to be used in a sequence of other components that
need the security, e.g.:
componentA -> security-componentX -> componentB -> componentC ->
security-componentY
In effect, then we wouldn't expect a component with security built
into it to be wired to a security-specific component. But honestly I
doubt we can really address a situation like this until we encounter
one really - especially with security. There's no way to anticipate
all security models.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
Re: ServiceMix and security
Posted by Dain Sundstrom <da...@iq80.com>.
On Apr 19, 2006, at 10:40 AM, Bruce Snyder wrote:
> On 4/18/06, Hossam Karim <hr...@gmail.com> wrote:
>> 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, XML encryption and
>> decryption, integration with LDAP, etc.
>> - A component that has a security provider installed should
>> delegate all
>> security operations to its provider.
>> - A component that has a security provider should provide additional
>> management operations through JMX to secure its lifecycle management.
>
> Actually I agree with Hossam here. I've always considered that
> security would be delegated to other components, not built into the
> core of each component. This will allow a wider variation of security
> models to be addressed and will also allow custom security components
> to be created to address custom security models on a per enterprise
> basis.
When coding Geronimo, I have found that as soon as I say, "no one
will ever do X" someone shows me a service doing just that, so my
question is, how will ServiceMix handle components that have security
"built into the core"?
-dain
Re: ServiceMix and security
Posted by Bruce Snyder <br...@gmail.com>.
On 4/18/06, Hossam Karim <hr...@gmail.com> wrote:
> 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, XML encryption and
> decryption, integration with LDAP, etc.
> - A component that has a security provider installed should delegate all
> security operations to its provider.
> - A component that has a security provider should provide additional
> management operations through JMX to secure its lifecycle management.
Actually I agree with Hossam here. I've always considered that
security would be delegated to other components, not built into the
core of each component. This will allow a wider variation of security
models to be addressed and will also allow custom security components
to be created to address custom security models on a per enterprise
basis.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
RE: ServiceMix and security
Posted by Hossam Karim <hr...@gmail.com>.
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, XML encryption and
decryption, integration with LDAP, etc.
- A component that has a security provider installed should delegate all
security operations to its provider.
- A component that has a security provider should provide additional
management operations through JMX to secure its lifecycle management.
Hossam
-----Original Message-----
From: Guillaume Nodet [mailto:gnodet@gmail.com]
Sent: Wednesday, April 19, 2006 2:57 AM
To: servicemix-dev@geronimo.apache.org
Subject: ServiceMix and security
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/Normali
zedMessage.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