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 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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 > >
