| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Another New Feature being added to MQAUSX (and z/MQAUSX) |
View previous topic :: View next topic |
| Author |
Message
|
| RogerLacroix |
 Posted: Mon Jul 06, 2015 2:44 pm Post subject: Another New Feature being added to MQAUSX (and z/MQAUSX) |
 |
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
A customer requested a solution to a problem that is not really an MQ Authenticate User Security Exit (MQAUSX) issue.
The customer has several applications that, shall we say, are poorly written and they will not likely be changed. These particular customer applications connect, open, put (and/or get), close and disconnect from the queue manager (over & over again). The applications generate up to 700 connection requests per minute (over 12,000 per hour). The MQAdmin recently changed the MQAUSX authentication target from Local OS to LDAP over SSL. This has caused a noticeable impact on their LDAP server to the point that the LDAP server is intermittently unavailable.
I have requested that the poorly written applications be changed/updated but it appears there is no interest/motivation to fix the poorly written applications and I keep getting asked to fix MQAUSX. MQAUSX only generates an LDAP request when the application connects to the queue manager.
i.e.
application --> QMgr MCA --> MQAUSX --> LDAP server
So, this is a case of the messenger being shot. I looked at a couple of solutions to the problem but the best answer is to implement a Credential Cache in MQAUSX. When this feature is enabled, MQAUSX will cache the user credentials (in an encrypted format) for ‘x’ minutes (default is 5 minutes) in shared memory. Hence, when there is a new connection, MQAUSX will first check the cache for the incoming UserID and if found then the entry’s timestamp will be checked. If the cache entry has expired then the entry is removed from the cache. If the entry is valid then the cached password is compared to the incoming password. If the passwords match then the connection is allowed. If the passwords do not match then the entry is removed from the cache and MQAUSX will perform an authentication against the target (i.e. LDAP).
| Code: |
UseCredentialCache = Y
CacheLife = 7 |
The above example says to enable caching of user credentials and make the “time to live” for the credentials be 7 minutes.
If you would like to try out the new feature then send an email to support@capitalware.com and we will send you the latest release of MQAUSX or z/MQAUSX.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Last edited by RogerLacroix on Fri Jul 10, 2015 11:06 am; edited 1 time in total |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Jul 06, 2015 3:41 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
Another related new feature in MQAUSX worth pointing out is the ability for MQAUSX to alert the MQ Admin if an application has made more the x connection attempts in a particular period of time. If this is configured in all environments from the start, the MQ Admin can identify the stinker application when they first start testing their poorly written code in DEV, not after the fact in a Production crisis the day of the release when its too late to fix things right away.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Jul 06, 2015 3:51 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2494
Location: Melbourne, Australia
|
Hi Roger. What happens when the password changes in the app and LDAP? Is there going to be a mechanism to clear the cache, or refresh from LDAP if the cached authentication fails?
_________________
Glenn |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jul 07, 2015 7:06 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| PeterPotkay wrote: |
| Another related new feature in MQAUSX worth pointing out is the ability for MQAUSX to alert the MQ Admin if an application has made more the x connection attempts in a particular period of time. If this is configured in all environments from the start, the MQ Admin can identify the stinker application when they first start testing their poorly written code in DEV, not after the fact in a Production crisis the day of the release when its too late to fix things right away. |
Yes, Excessive Client Connections (ECC) was requested by a very pro-active customer.  It was included in v3.0 of MQAUSX. ECC is an alert system that counts the number of connections over a period of time (i.e. Day / Hour / Minute) and writes a message to the log when the count exceeds a particular value. If the keyword WriteToEventQueue is set to 'Y' then an event message is also written to an event queue.
i.e.
| Code: |
UseECC=Y
ECCWarnCount=300
ECCInterval=H |
The above example says to generate a warning logfile message (and event message) if the channel receives more than 300 connections over the hour.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Jul 07, 2015 7:18 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| gbaddeley wrote: |
| What happens when the password changes in the app and LDAP? Is there going to be a mechanism to clear the cache, or refresh from LDAP if the cached authentication fails? |
Yes, it is handled as noted here:
| RogerLacroix wrote: |
| When this feature is enabled, MQAUSX will cache the user credentials (in an encrypted format) for ‘x’ minutes (default is 5 minutes) in shared memory. Hence, when there is a new connection, MQAUSX will first check the cache for the incoming UserID and if found then the entry’s timestamp will be checked. If the cache entry has expired then the entry is removed from the cache. If the entry is valid then the cached password is compared to the incoming password. If the passwords match then the connection is allowed. If the passwords do not match then the entry is removed from the cache and MQAUSX will perform an authentication against the target (i.e. LDAP). |
I didn't give a lot of detail but it goes like this (assuming UseCredentialCache=Y):
- Loop through the cache looking for the matching UserID - not found go to (A)
- If the UserID is found then check the stored timestamp to see if it is expired - if true, remove entry from cache and go to (A)
- Compare the passwords - if different, remove entry from cache and go to (A)
- If the passwords match go to (S)
(A) Perform authentication against whatever target (i.e. LDAP) is defined in the IniFile - if success add entry to cache and go to (S). If the authentication fails, go to (E).
(S) Allow the channel to continue
(E) Close the channel.
The description is bit on the simplistic side but you should get the idea.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
