What is @class in authrec in midrange?

Before a user or group can be given access to a specific profile and object type, it needs to have a profile called “@class” in the object type.

This “@class” profile is used for authorising the create object of the specified object type.

The commands

set authrec profile(‘ZZ*’) objtype(namelist) group('test') authadd(INQ)

dis authrec objtype(namelist) group('test')

gave two profiles one for the class and one for the specific resource.

PROFILE(@class) ENTITY(test) ENTTYPE(GROUP) OBJTYPE(NAMELIST) AUTHLIST(NONE)
PROFILE(ZZ*) ENTITY(test) ENTTYPE(GROUP) OBJTYPE(NAMELIST) AUTHLIST(INQ)

So we can see that group test is authorised to inquire with the profile ZZ* for NAMELIST.

But because of PROFILE(@class) OBJTYPE(NAMELIST) AUTHLIST(NONE) , group test it is not authorised to create a namelist.

If you want to control delete name list you specify

set  authrec profile('ZZ*') objtype(namelist) group('test') authadd(DLT)

and the display now gives

PROFILE(ZZ*)ENTITY(test)ENTTYPE(GROUP)OBJTYPE(NAMELIST) AUTHLIST(DLT,INQ)

To display people who have been given any authority to an object type use,

dis authrec profile('@class')objtype(namelist)

PROFILE(@class) ENTITY(colinpaice) ENTTYPE(GROUP) OBJTYPE(NAMELIST) AUTHLIST(CRT)
PROFILE(@class) ENTITY(mqm) ENTTYPE(GROUP) OBJTYPE(NAMELIST) AUTHLIST(CRT)
PROFILE(@class) ENTITY(testuser) ENTTYPE(GROUP) OBJTYPE(NAMELIST) AUTHLIST(NONE)
PROFILE(@class) ENTITY(test) ENTTYPE(GROUP) OBJTYPE(NAMELIST) AUTHLIST(NONE)

Shows that ids in the group colinpaice, and mqm can create namelists. Userids solely in group test or testuser cannot. Userid colinpaice in groups mqm and test is authorised to create name lists. Being in at least one group which is allowed to create a resource means the userid is allowed to create a resource.

Can I clean up the entries?

After using my queue manager for a while I found there were entries like

PROFILE(@class) ENTITY(…) ENTTYPE(PRINCIPAL) OBJTYPE(QMGR) AUTHLIST(NONE)

which existed even though the principal or group had been deleted from MQ.

You cannot delete these entries.

These display authority commands are difficult to use!

I was asked to explain how the midrange security commands work. At first glance it looked pretty easy, but then I tried to use them, and got very confused when it did not work as I expected.

Some of the complexity comes from userids which are also groups, definitions which look like generics but are not generic, some of the definitions seem backwards, and some more documentation is needed! Read on to see how I was baffled and felt very confused.

I was talking to Morag on this, and she said that MQGEM do education on authorization – see here.

 

I was running on Ubuntu (18.04)

Queue manager running userid or group based authorization.

A queue manger can be set up to use user-based or group-based authorization. See here and here. The default is group based.

A linux userid has a private group with the same name as the userid

I set up a userid testuser which had effectively no authority to do anything. This has a (private) group with the same name as the userid. See here.

The command id testuser gives

uid=1002(testuser) gid=1004(testuser) groups=1004(testuser)

I used

sudo groupadd test 
sudo adduser testuser test

to add testuser to the group called test, and will use group test in the rest of the discussions.

There are two ways of displaying and setting MQ authorisation information

There are two ways of using the MQ security commands

  1. Runmqsc and display/delete/set AUTHREC. You can use runmqsc as a client from a remote machine. This can be used for an MQ appliance.
  2. setmqauth and dspmqauth shell commands. You need to have access to the shell environment to be able to issue these commands. This cannot be used for an MQ appliance.

The documentation has similar content but the runmqsc set authrec command is slightly better.

For example see here.

  • runmqsc set authrec explains DSP : Display the attributes of the specified object using the appropriate command set . But it is not clear what a command set is. I think it means PCF or MQSC.
  • setmqauth shows DSP – but does not explain what DSP provides

The syntax of the commands is similar, but different, and this caught me out for a while. For example I used

setmqauth -m QMA -t qmgr -p testuser +inq -dsp

but with the runmqsc I had to specify principal(‘testuser’) in quotes – because as with all runmqsc fields they get converted to upper case when the string is not quoted!

Creating and using profiles

I created profiles

set AUTHREC PROFILE(COLIN_1) OBJTYPE(QUEUE) group('test') AUTHADD(GET) 
set AUTHREC PROFILE(COLIN_2) OBJTYPE(QUEUE) group('test') AUTHADD(SET)
set AUTHREC PROFILE(COLIN_3*) OBJTYPE(QUEUE) group('test') AUTHADD(INQ)
set AUTHREC PROFILE(COLIN_*) OBJTYPE(QUEUE) group('test') AUTHADD(GET,PUT)

When security checks are done, if there are choice of records for a queue the definition, is the most specific one. See here. I could not find anything in MQ which told me which actual profile was used – even though MQ knows this information!

If ‘testuser’ in group test, wants to access some queues, the userid can open

COLIN_1  for get
COLIN_2 for set
COLIN_3 for inquire
COLIN_33 for inquire. The COLIN_3* is more specific than COLIN_*
QUEUE_11 for put + get. This is from the COLIN_* definition.

Displaying a profile

If you issue DIS QUEUE(COLIN*), the * acts as a generic character and says display any queues beginning with COLIN.

The DIS AUTHREC is different. DIS AUTHREC PROFILE(COLIN*) does not say show all profiles beginning with COLIN, it says show me the actual profile COLIN* . Just the same as if it was COLIN@.

Below are some display commands and their responses

DIS AUTHREC PROFILE(COLIN*) returned no object, as explained above.

DIS AUTHREC PROFILE(COLIN_*) this is saying give me the specific profile COLIN_* and it returned

PROFILE(COLIN_*) ENTITY(test) ENTTYPE(GROUP) OBJTYPE(QUEUE) AUTHLIST(GET)

DIS AUTHREC PROFILE(COLIN_1) returned two entries (as both of them could potentially apply)

PROFILE(COLIN_1) … AUTHLIST(GET)
PROFILE(COLIN_*) … AUTHLIST(GET,PUT)

DIS AUTHREC PROFILE(COLIN_*) GROUP(test)returned

AMQ8459I: Not found. This is because the test became upper case TEST

DIS AUTHREC PROFILE(COLIN_*) GROUP(‘test’) returned

PROFILE(COLIN_*) … AUTHLIST(GET)

DIS AUTHREC PROFILE(COLIN_*) group(‘mqm’) returned

AMQ8459I: Not found.

To summarize,

If you issue a display command for a generic looking profile – it will display profiles with the specific name including the ‘*’.

If you display a specific looking name, it will act like a generic, and display all the records which apply to the specific name.

So you can see why I was confused – but it gets more complex.

MATCH(MEMBERSHIP)

There is a parameter MATCH with default PROFILE which says return the profiles and the the value of the principal eg GROUP(TEST), this is what happened above.

There is also MATCH(MEMBERSHIP). This looks into the definitions and gets the list of the userid’s groups and displays the authrecs for the specified userid.

dis authrec profile(COLIN_2) objtype(queue) principal(‘testuser’) match(membership)returned

PROFILE(COLIN_2) ENTITY(test) ENTTYPE(GROUP) … AUTHLIST(SET)

This is because userid testuser is in group test.

You can also specify MATCH(EXACT). This returns the specified profile, and specified principle.

DIS AUTHREC PROFILE(COLIN_1) match(PROFILE)returned

PROFILE(COLIN_1) ENTITY(test)…
PROFILE(COLIN_*) ENTITY(test)…

DIS AUTHREC PROFILE(COLIN_1) match(EXACT)returned

PROFILE(COLIN_1) ENTITY(test)..

How do I find the list of profiles if I cannot use a generic search argument?

To list all queue auth records applicable for group test use

DIS AUTHREC objtype(QUEUE) group(‘test’)

To list all available auth records applicable for group test use

DIS AUTHREC group(‘test’)

To list all auth records, for all objects for all users and groups use

DIS AUTHREC which you may want to capture in a file using

echo “DIS AUTHREC “ |runmqsc QMA > authrec.txt