Author |
Message
|
pellcorp |
Posted: Thu Oct 30, 2014 9:48 pm Post subject: Understanding Security Exits in 7.1 |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
Hi All,
I apologise profusely if I am asking something already asked. I also realised i am probably going to get flamed for trying to write a security exit when I am still very new to MQ. Let me try and explain why I am doing that.
I am writing an exit to allow me to test username / password authentication from a Java application. I don't have the budget to purchase anything such as the capitalware solution. This functionality needs to be tested as I have a potential client who is wanting to integrate my application (based on apache cxf soap/jms) with Websphere MQ using username / password authentication. I realise that mutual SSL appears to be a preferred security practice, but it's not relevant for my customer at this point.
What I have come up with is so far is:
https://github.com/pellcorp/cxf/blob/master/JavaFirst/native/UsernamePasswordExit.c
https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/jms/mq/SecurityExit.java
My C code is dreadful I know, I don't do C and this code will never go into production its just for my improved understanding of how the security flows are supposed to work. So a hacked up ugly mess is ok for my needs, I just need to know if it is even in the ballpark to something I might see on a customer site.
What I ended up doing in my exit is clearing out the MCA User Id in the INIT and only assigning it a value if MQXR_SEC_PARMS is populated and valid (the SecurityExit.java was used on the client) or the standard remote userid / password combo is polulated and valid.
I am then letting the standard CHLAUTH do the rest. I have my QM, Channels and and Queues restricted to known linux users, so unless the username / password is valid the CHLAUTH is going to kick back a 2035 error.
In a previous iteration of my work on the server side exit, I did try setting the pParms->ExitResponse = MQXCC_SUPPRESS_FUNCTION; but it caused a Null Pointer Exception in the Websphere MQ libraries when using the SecurityExit.java
What I am wanting is an opinion over how typical this kind of approach is and if security exits normally result in a 2035 or they always use MQXCC_SUPPRESS_FUNCTION which results in a different error code.
I have also looked at converting my UsernamePasswordExit to a AuthorisationService, I will probably look at that next. I had some issues getting it registered correctly when I first tried it, I suspect I linked against the wrong libraries. I can't find how to debug whether Websphere MQ is even calling the other AuthorizationService.
http://www.ibm.com/developerworks/websphere/library/techarticles/0512_ritchie/0512_ritchie.html#download |
|
Back to top |
|
 |
pellcorp |
Posted: Thu Oct 30, 2014 10:32 pm Post subject: AuthorisationService question |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
Hi again,
I managed to get an AuthorisationService kind of working. Only thing is the test pSecurityParms -> AuthenticationType == MQCSP_AUTH_USER_ID_AND_PWD is always false even though i have configured a client side exit. When I use a security exit I can confirm that the AuthenticationType is certainly set. I think I must be missing something dreadfully obvious.
https://github.com/pellcorp/cxf/blob/master/JavaFirst/native/UsernamePasswordAuthorizationService.c
I would appreciate any assistance you can provide including any good docs as they are hard to come by for java to mq 7. |
|
Back to top |
|
 |
pellcorp |
Posted: Thu Oct 30, 2014 11:35 pm Post subject: AuthorisationService question cont |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
Hi,
I added a modified version of one of the samples from the MQ 7.1.0.3 installation that also demonstrates the issue to take Apache CXF jms stuff out of the problem space.
https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/jms/mq/JmsProducer.java
The AuthorisationService still fails because the AuthenticationType is still = 0, rather than 1 (which is the int code for MQCSP_AUTH_USER_ID_AND_PWD)
I am going to work on a pure IBM call withoutpo JMS and see if that is any different.
Because I am not a customer of IBM I cannot get access to IBM support or updated versions of the jar files. |
|
Back to top |
|
 |
smdavies99 |
Posted: Fri Oct 31, 2014 12:04 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
You don't have to be a paid up customer of IBM to get an IBM ID. That your allow you to download the latest V7.1 client kit.
However, is your employer an IBM Customer? they should have access to everything you need and should be able to get it for you. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
pellcorp |
Posted: Fri Oct 31, 2014 1:26 am Post subject: AuthorisationService question cont |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
Well my final piece of investigation on this topic suggests its thankfully nothing to do with java and more to do with either a bug in my authorization service or a misconfiguration of my mq installation.
I developed an additional java test with pure mq code which failed to authenticate due to the auth type not being correctly passed to the authorization service.
https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/main/java/com/pellcorp/jms/mq/PureMqAuth.java
I then did a final test using some C code compiled against the mq client libs that exhibits the same problem.
https://github.com/pellcorp/cxf/blob/master/JavaFirst/native/authjmsqput.c
I compiled it thus:
gcc -m64 -o authjmsqput authjmsqput.c -I/opt/mqm/inc -L/opt/mqm/lib64 -Wl,-rpath=/opt/mqm/lib64 -Wl,-rpath=/usr/lib64 -lmqic_r -lpthread
In all cases when using the security exit (UsernamePasswordExit.c) the exit is passed the correct auth type, but for the AuthorizationService it's not.
I am not entirely sure where to look now, but at least I think I have isolated the problem away from java which is a relief.
Any assistance or suggestions will be gratefully received as MQ is very new to me.
I am running a 90 day trial of 7.1.0.3 on Ubuntu 14.04 64bit installed according to IBM's own instructions for Ubuntu 14.04.
In case it's relevant I compiled the AuthorizationService thus:
gcc -e MQStart -shared -L/opt/mqm/lib64 -L/usr/lib -lc -lnsl -ldl -lmqmzf_r -o /var/mqm/exits64/UsernamePasswordAuthorizationService UsernamePasswordAuthorizationService.c -I/opt/mqm/inc -fPIC
My qm.ini looks like:
Code: |
ExitPath:
ExitsDefaultPath=/var/mqm/exits
ExitsDefaultPath64=/var/mqm/exits64
#* *#
#* *#
Log:
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=4096
LogType=CIRCULAR
LogBufferPages=0
LogPath=/var/mqm/log/QMGR/
LogWriteIntegrity=TripleWrite
Service:
Name=AuthorizationService
EntryPoints=14
ServiceComponent:
Name=UsernamePasswordAuthorizationService
Module=/var/mqm/exits64/UsernamePasswordAuthorizationService
Service=AuthorizationService
ComponentDataSize=0
ServiceComponent:
Service=AuthorizationService
Name=MQSeries.UNIX.auth.service
Module=amqzfu
ComponentDataSize=0
|
Last edited by pellcorp on Fri Oct 31, 2014 1:40 am; edited 2 times in total |
|
Back to top |
|
 |
pellcorp |
Posted: Fri Oct 31, 2014 1:29 am Post subject: |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
smdavies99 wrote: |
You don't have to be a paid up customer of IBM to get an IBM ID. That your allow you to download the latest V7.1 client kit.
However, is your employer an IBM Customer? they should have access to everything you need and should be able to get it for you. |
I downloaded the trial without an IBM ID. My employer is not an IBM customer. My customer is, but it's going to take too long to arrange anything through them.
Plus now that I know it's does not appear to be a java issue, I need to pursue misconfiguration of my MQ installation or at least the AuthorisationService |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Oct 31, 2014 4:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
I think an important question to ask your customer is - are they trying to use the username/password features in MQV8? If so, this may save you, and them, a lot of trouble.
If they're trying to use the username/password features of MQv8, then either your raw application code, or your exit, merely needs to attach an MQCSP structure with the relevant features to an MQCONNX call. If your app is in Java, there are documented ways to cause this to happen.
There also used to be some kind of IBM developer program, that would give you certain levels of access to things above and beyond "trial" versions. It had some kind of fee - maybe $500/year? It's worth looking into. |
|
Back to top |
|
 |
pellcorp |
Posted: Fri Oct 31, 2014 6:36 am Post subject: |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
mqjeff wrote: |
I think an important question to ask your customer is - are they trying to use the username/password features in MQV8? If so, this may save you, and them, a lot of trouble.
If they're trying to use the username/password features of MQv8, then either your raw application code, or your exit, merely needs to attach an MQCSP structure with the relevant features to an MQCONNX call. If your app is in Java, there are documented ways to cause this to happen.
There also used to be some kind of IBM developer program, that would give you certain levels of access to things above and beyond "trial" versions. It had some kind of fee - maybe $500/year? It's worth looking into. |
Hi,
Thanks for your reply. They are going with mq 7.5. I cant get 7.5 as a trial so that is why i am on 7.1.
Has anyone used authorisation service and mqscp auth in mq 7.1? Do i need to do anything special to get the mqscp and auth type recognised?
Does my authorisation service look ok?
Is it ok to rely on chnauth to do final validation of credentials rather than return a supress function reason?
i am covering my bases as i work for a vendor so this solution will be sold to other mq customers.
I am going to work on enabling support for mq mutual ssl but basic password auth is needed now.
But any ideas on why the authorisation service is not recognising the auth type passed from C code would be good.
Do i need to enable any particular permissions?
Is there a way to turn on detailed tracing? |
|
Back to top |
|
 |
Vitor |
Posted: Fri Oct 31, 2014 6:50 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
pellcorp wrote: |
Thanks for your reply. They are going with mq 7.5. I cant get 7.5 as a trial so that is why i am on 7.1. |
Isn't the Developer Edition of MQ any use for this then?  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
pellcorp |
Posted: Fri Oct 31, 2014 12:25 pm Post subject: |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
Vitor wrote: |
pellcorp wrote: |
Thanks for your reply. They are going with mq 7.5. I cant get 7.5 as a trial so that is why i am on 7.1. |
Isn't the Developer Edition of MQ any use for this then?  |
I am downloading that now. Thanks for the suggestion. |
|
Back to top |
|
 |
pellcorp |
Posted: Fri Oct 31, 2014 1:30 pm Post subject: |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
So I upgraded to 7.5 and rebuilt both the AuthorisationService and the test c code with the 7.5 libraries. I get the same problem. The AuthorisationService does not see the auth type as being MQCSP_AUTH_USER_ID_AND_PWD. |
|
Back to top |
|
 |
pellcorp |
Posted: Fri Oct 31, 2014 10:50 pm Post subject: |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
|
Back to top |
|
 |
pellcorp |
Posted: Sun Nov 02, 2014 4:28 pm Post subject: |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
I realised that I may have made a fundamental mistake in my testing. My test C code was falling back to a 'server' connection rather than a true client connection because I did not define a Queue Manager, but left it blank.
As soon as I tried to define a queue manager parameter, I am left with 2058 errors. I am wondering if using a server connection means that the MQCSP stuff is ignored.
Now I have to figure out how to get /opt/mqm/samp/bin/amqsput working with a specific Queue Manager and perhaps I will make more progress. |
|
Back to top |
|
 |
pellcorp |
Posted: Sun Nov 02, 2014 5:40 pm Post subject: |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
pellcorp wrote: |
I realised that I may have made a fundamental mistake in my testing. My test C code was falling back to a 'server' connection rather than a true client connection because I did not define a Queue Manager, but left it blank.
As soon as I tried to define a queue manager parameter, I am left with 2058 errors. I am wondering if using a server connection means that the MQCSP stuff is ignored.
Now I have to figure out how to get /opt/mqm/samp/bin/amqsput working with a specific Queue Manager and perhaps I will make more progress. |
So I realise I had to export MQSERVER variable:
Before:
/opt/mqm/samp/bin/amqsputc Q1 QMGR
Sample AMQSPUT0 start
MQCONN ended with reason code 2058
After:
export MQSERVER='SYSTEM.DEF.SVRCONN/TCP/127.0.0.1(1414)'
/opt/mqm/samp/bin/amqsputc Q1 QMGR
Sample AMQSPUT0 start
MQCONN ended with reason code 2035
Awesome - 2035 is expected as the user the amqsputc is running as is an mqm admin, so my channel auth rules reject it.
Obviously I can fix with:
alter channel(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('jmuser')
/opt/mqm/samp/bin/amqsputc Q1 QMGR
Sample AMQSPUT0 start
target queue is Q1
adadadasd
Sample AMQSPUT0 end
Awesome, so a step forward.
Edit: I realise it's poor form to use the default SYSTEM. channels, I did create my own channel as a sample, but its just simpler to keep with the defaults initially.
def channel(MY.CHANNEL) CHLTYPE(SVRCONN) TRPTYPE(TCP) MCAUSER('jmsuser') |
|
Back to top |
|
 |
pellcorp |
Posted: Mon Nov 03, 2014 3:17 pm Post subject: |
|
|
Novice
Joined: 30 Oct 2014 Posts: 13
|
It's obvious I am still misunderstanding some fundamental concepts of AuthorisationService (More reading required!)
It looks like the configuration of SYSTEM.DEF.SVRCONN still affects other SVRCONN channels. Regardless of which channel I use, I must configure a valid MCAUSER on SYSTEM.DEF.SVRCONN and add a valid CHLAUTH record something like: SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)
Then the AuthorisationService works as it should.
What I did not realise was that the AuthorisationService was used for much more than just client connection authentication.
My next step is to figure out how to discern an internal auth check against a client check. I want to replace my UsernamePasswordExit with this service, so it needs to throw an auth error for missing credentials as well as invalid ones, otherwise there is a substantial security hole, which is just don't provide SecurityParams. |
|
Back to top |
|
 |
|