I have the following configuration. The server listens to incoming ActiveMQ messages from producers that run on clients. I want to avoid from a client to create a consumer. Otherwise any client can sniff to all messages on bus and this is serious security flaw. Is there anyway to restrict clients to create only producer?
ActiveMQ feature different security options to control access on a fine grained level.
You typically want to use the authorization plugin.
For instance, if you have a queue Queue1 that user sputnik should produce to and user apollo should consume from, you can setup the authorizationPlugin like this:
<authorizationPlugin>
<map>
<authorizationMap>
<authorizationEntries>
<authorizationEntry queue="Queue1" read="apollo" write="sputnik" admin="admin" />
Read: Consume
Write: Produce
Admin: Create
You can create authorization entries like queue=">" that maps to every queue, or a prefix with queue="SECRET.>"
Ensure you have authentication enabled to use these features.
Related
I have a receive only endpoint as a azure worker role listening to topics on ASB transport. This receive only endpoint is automatically creating receiveonlyendpoint.queue, receiveonlyendpoint.topic etc which i dont want. I just need a subscription to publisher.events and auto subscription works fine. How to control this in NServicebus 6 and NSB Asb transport 7
With ASB transport version 7 you need to choose the topology. Documentation on topologies goes into details how those operate.
Note that endpoint is either a normal endpoint (sends and receives) and send only (doesn't receive). There's no receive only type. Therefore your endpoint is a full endpoint and will create necessary queues.
I have a small project in which tweets from twitter are consumed by an application, put into a JMS queue on an ActiveMQ, read from another application to to enrich each tweet and then returned into another JMS queue on the ActiveMQ server.
Currently, all the routing is defined within each application itself. So the routing from twitter into the JMS queue is defined in application A and the routing from one JMS queue into another is defined in application B.
In my opinion this architecture seems to be wrong, since now I cannot change any route without redeploying one of the applications.
What I want is a solution where I have some (micro)services like a twitter adapter and an enricher, which are independent from each other. But where do I put the routing information then? Somehow into ActiveMQ? Is there a way to configure the routes easily? Somehow this sounds like an ESB, doesn´t it?
I think you can use a central java component hosting Camel + Embedded ActiveMQ server for integrating various applications. This central component can have your micro services/enrichers as well as all routes transferring data between applications.
Camel provides lots of components (VM, file, JMS, RMI, Webservices etc) which you can use as endpoints connecting to Application A/B. About Twitter feed you can put the twitter adapter/listener into this central component so that it can communicate to Camel routes through direct-VM endpoint.
This makes integration easier. All routes are maintained at central place and it decouples the MQ server, micro services and applications.
So I'm looking into implementing NServiceBus in our current setup and just trying to get a better understanding of how things should be setup.
Our current setup consists of multiple clients (websites, scheduled tasks, etc..) calling a WCF service we have set up for handling the sending of emails. Of course, if the service goes down then our clients start getting errors and all of those messages are then lost (one of the reasons we want an ESB).
I've seen how you can configure your WCF service to handle nservicebus messages in a pub/sub setup. What I'm not sure on is what is the best way to set it up.
Setup 1:
Client (Publisher) -> NServiceBus handler (Subscriber) -> WCF Service
In this case, to scale you'd increase the number of handlers (hosted nservicebus services?), keeping just the one WCF service.
Setup 2:
Client (Publisher) -> WCF Service (Subscriber)
This one you just increase the number of WCF services to scale (updates would be a nightmare).
I just started looking into the ESB architecture in general so if I'm completely off let me know. I'm essentially just wanting to know what is working for you, and what the "best practice" tends to be.
Thanks!
I'm not completely clear on what you need WCF for anymore if you implement this via NServiceBus. Is the WCF component required for anything besides receiving messages (to send an email) from the multiple clients? If not, you could remove WCF from the equation.
From the sound of it, you will also want the Service to act as a single logical endpoint that handle requests to send emails. If that's the case, you will want to use Send (a command) instead of Publish (an event). Publish is used to broadcast an event, which means that something happened already; Send is used to instruct another component to do something. It sounds like you want the latter.
Scaling of an endpoint can be done via the Distributor. This may or may not be useful depending on where you expect the bottleneck to be.
Edit: Based on your comment, I would simply go with the second setup, and just add the handler to the WCF service. If you are hosting WCF in IIS, make sure you have something that wakes the process up if the app pool recycles (the incoming message won't wake it up the same way an incoming request to WCF will).
We do something similar internally where one NSB endpoint handles all the sending of email. The clients can either use NSB directly to Bus.Send() the command to send a message to the email endpoint or you can expose that endpoint via WCF as well (only to get the commands over to the endpoint). Once the endpoint has the commands, they would just call your existing service to maintain compatibility with your existing clients.
I'm building a system where several clients are connected to a central server by WCF using duplex MSMQ (updates are sent to the server, messages are periodically pushed out to several clients).
How do I best secure this scenario? The nature of duplex WCF effectively makes each client a server. Does that mean to secure each channel every client needs to shell out $1200 for a verisign cert?
Because MSMQ binding uses regular MSMQ queues, you can implement security using the standard MSMQ queue security model. You need to make sure you set security mode to 'Transport', and then allow or restrict access to the queue as appropriate.
When you create a queue you can set permissions which govern who can send, receive, or remove from the queue using active directory or Windows accounts. The only resource I can find with a few minutes googling is MSMQ for .NET Developers - describes a little about setting permissions.
Have a read of Securing Messages with Transport Security and the examples in the NetMsmqBinding documentation.
So you should either run your services as the same user, or ensure all the users are in a single AD group, etc and then grant queue permissions (send permission?) to that user / group only.
I am looking at various options for a WCF based publish subscribe framework. Say I have one WCF web service that will be the publisher and 1000 clients registered as subscriber. For some published messages all clients will be interested but at the same time I wish the ability to notify a single client with a specific message. On receiving notification the client will call other web service methods on the web service.
Is NServiceBus suitable for this kind of scenario ?
If I use MSMQ for transport does it mean that every PC where the client is installed requires a queue to be created ?
Some of the challenges include how you want the publisher to behave when a given subscribing client is down - do you want that message to be available when the subscriber comes back up? If so, then some kind of durable messaging is needed between them - like MSMQ.
Your question about notifying a single client, is that as a result of a request sent by that client? If so, then standard NServiceBus calls in the form of Bus.Reply will do it for you. When using WCF, if the response is to be asynchronous you'll need to use callback contracts.
NServiceBus can do all the things you described, and has the ability to automatically install MSMQ and create queues so that greatly simplifies client-side deployments.
You also have the ability with NServiceBus to expose messages over WCF so you can support non-NServiceBus clients if you need to as well. It also has its own http gateway and XSD schemas which can allow clients on non-Windows platforms to interoperate even without using WCF.
Hope that answers your questions.