WebSphere MQ File Transfer Edition and LDAP compatibility?

Question

I'm very new to the WebSphere MQ/FTE software and I am trying to evaluate FTE software for our file transfer needs.

I have the following requirements.

1. Need a scheduling tool for our interfaces.
2. Our interfaces consist primarily of file transfers. They can be event driven (presence of file in some location) or they can be scheduled to run at pre-determined intervals.
3. Certain users can start/stop file transfers based on their permissions.
4. Users responsible for maintaining such interfaces need to be authenticated through LDAP.

Based on the literature I've been able to read so far, I've come to the following conclusions.

1. WebSphere FTE can handle event based file transfers, but is rather limited in its scheduling capabilities. Therefore a custom scheduler needs to be created for the remainder.

2. MQ ID-s are incompatible with LDAP ID-s. In other words, MQ users and groups are limited only to MQ. In order to use LDAP as an authentication tool, you'll need a custom solution that maps groups of/individual LDAP users to a particular MQ FTE user/group that's responsible for writing messages to an agent command queue.

I was wondering whether the conclusions above are correct.

I also have the following questions that I have not been able to find answers for:

1. If you install an FTE Client in a particular machine, how many agents can you create in that machine? (I think an article implied that you can instantiate multiple, but it wasn't clear)

2. Is it possible to access an agent queue from Spring Integration and especially, is it possible to do it remotely?

I did try to install WebSphere MQ and FTE on my developer laptop (Windows), but the installation ran into trouble when MQ required a domain user (my domain ID did not work, I'm guessing because I'm already in the Administrators group in my local machine). I need to evaluate this as a possible solution and time's too short for the learning curve that would be required to come up with a prototype.

If anybody has any suggestions on this, I would greatly appreciate them.

Answer 1

Multi-part question so let me try to address these in order.

Yes, you are correct concerning the functionality in the agent scheduling function and that MQ does not authenticate or authorize against external LDAP providers. Scheduling in FTE is performed by the agents and does not include such things as holiday schedules. Several shops use their enterprise scheduling system to submit FTE jobs directly to the agent command queues using the documented XML schemas.

If the WMQ UNIX/Linux server uses PAM it can use Active Directory or LDAP as its identity and group repository but even then it does not perform password validation without a channel security exit. Windows QMgrs natively use Active Directory as their identity and group repository but also do not check passwords.

The number of agents on a particular machine is limited only by resources such as memory and processors. No two agents should have the same name, even across different servers.

If by "access an agent queue" you mean to put XML commands on the agent's command queue, most definitely. You don't want to GET messages from the agent's queues and you don't want to put messages to any queues other than the command queue. Within those limitations, putting commands to the agent's queue is the prescribed way to initiate agent actions. In fact, the FTE line commands work that way and they use the user's credentials to remotely access the queue manager. Any user authorized to use the FTE commands remotely could use the same credentials and access to put XML messages on the command queue using Spring, DataPower, a scheduler, etc. Generally, mutually authenticated SSL channels are used so that headless agents do not need to provide passwords. The SSL certificate Common Name is mapped to the local user ID authorized to connect and access the agent's command queue.

Neither WMQ nor FTE require a domain ID to perform the install or to run. However, if WMQ encounters an ID that does not resolve locally, Windows tries to resolve the ID in any domains to which it is connected. This means that the ID installing WMQ or running WMQ needs to be able to query IDs and groups in the domain. Simplest way to set up WMQ for a POC is in a VM that is not domain-aware. If you must use a domain-connected Windows instance, please see Special considerations for security on Windows. Note that there is a section describing how to use a domain ID to run queue managers but this is not meant to imply that you must use a domain ID.