ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » User Exits » Understanding Security Exits in 7.1

Post new topic  Reply to topic Goto page 1, 2  Next
 Understanding Security Exits in 7.1 « View previous topic :: View next topic » 
Author Message
pellcorp
PostPosted: Thu Oct 30, 2014 9:48 pm    Post subject: Understanding Security Exits in 7.1 Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Thu Oct 30, 2014 10:32 pm    Post subject: AuthorisationService question Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Thu Oct 30, 2014 11:35 pm    Post subject: AuthorisationService question cont Reply with quote

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
View user's profile Send private message
smdavies99
PostPosted: Fri Oct 31, 2014 12:04 am    Post subject: Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Fri Oct 31, 2014 1:26 am    Post subject: AuthorisationService question cont Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Fri Oct 31, 2014 1:29 am    Post subject: Reply with quote

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
View user's profile Send private message
mqjeff
PostPosted: Fri Oct 31, 2014 4:49 am    Post subject: Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Fri Oct 31, 2014 6:36 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Oct 31, 2014 6:50 am    Post subject: Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Fri Oct 31, 2014 12:25 pm    Post subject: Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Fri Oct 31, 2014 1:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Fri Oct 31, 2014 10:50 pm    Post subject: Reply with quote

Novice

Joined: 30 Oct 2014
Posts: 13

I found a IBM support pack which has a 7.1+ compatible authorization service so I will play with that next week.
http://www-01.ibm.com/support/docview.wss?uid=swg24011617
Back to top
View user's profile Send private message
pellcorp
PostPosted: Sun Nov 02, 2014 4:28 pm    Post subject: Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Sun Nov 02, 2014 5:40 pm    Post subject: Reply with quote

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
View user's profile Send private message
pellcorp
PostPosted: Mon Nov 03, 2014 3:17 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » User Exits » Understanding Security Exits in 7.1
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.