Re: ServiceMix and security
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 <[EMAIL PROTECTED]> wrote: > 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 messag
Re: ServiceMix and security
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 <[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 -- 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
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
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 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
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
> 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)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://incubator.apache.org/activemq/
Apache ServiceMix - http://incubator.apache.org/servicemix/
Castor - http://castor.org/
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
