Hi Yulia,

If the client has authority to, and is setting ApplIdentityData in the MQMD of the message, they must also have the authority to (and indeed should) set all the other identity context fields in the MQMD of the message. Can you have them set the User Identifier appropriately so you can tell them apart?

Alternatively, you could get them to set their application name at connect time and then this would be put into the PutApplName MQMD field of the messages they sent. For details of how to set this, see More descriptive Application Names in IBM MQ

From my suggestions, you likely get the impression that there is no easy way to access the certificate of the putting application from the message when it is got from the queue. Even when messages are digitally signed when using AMS, there is no application access to that signature or the certificate details. You either are allowed to see the message or you are not.

I mention AMS because it may be useful for you to think about this. You don't mention why you need to know the certificate details of the putter. If it is just to tell between the two applications, then it would be interesting to know why? Can any application just tell you it is application A, or do you need proof that it is application A? What happens if application B asserts that it is application A?

Why don't they put their messages to different queues so that you can tell who is who that way? Also, then only application A would have put authority to APP.A.Q and only application B would have put authority to APP.B.Q and you wouldn't have a worry that the applications could be accidentally (or maliciously) asserting that they are not who they really are.

Anyway, hope some of that helps.

Cheers,
Morag

Hi,

To have different queue is not an option . We don't want to change the application. Right now client application passes mf user id and pass ticket on ApplIdentityData . Infrastructure transaction reads input messages , performs sign in with user/password and starts application transaction under this user.  It's fine for "real" users but for machine users ( mainly ESB )  we would like to use certificate authentication ( in order to skip sign in )  and to define those users w/o password at all. Because otherwise any person who knows those user's name can revoke them by trying to login with wrong password. 

Yulia.

Hi Yulia,

If the client has authority to, and is setting ApplIdentityData in the MQMD of the message, they must also have the authority to (and indeed should) set all the other identity context fields in the MQMD of the message. Can you have them set the User Identifier appropriately so you can tell them apart?

Alternatively, you could get them to set their application name at connect time and then this would be put into the PutApplName MQMD field of the messages they sent. For details of how to set this, see More descriptive Application Names in IBM MQ

From my suggestions, you likely get the impression that there is no easy way to access the certificate of the putting application from the message when it is got from the queue. Even when messages are digitally signed when using AMS, there is no application access to that signature or the certificate details. You either are allowed to see the message or you are not.

I mention AMS because it may be useful for you to think about this. You don't mention why you need to know the certificate details of the putter. If it is just to tell between the two applications, then it would be interesting to know why? Can any application just tell you it is application A, or do you need proof that it is application A? What happens if application B asserts that it is application A?

Why don't they put their messages to different queues so that you can tell who is who that way? Also, then only application A would have put authority to APP.A.Q and only application B would have put authority to APP.B.Q and you wouldn't have a worry that the applications could be accidentally (or maliciously) asserting that they are not who they really are.

Anyway, hope some of that helps.

Cheers,
Morag

The only place I can think of that you can obtain the certificate details would be in a channel exit. However, on a SVRCONN channel you have no architected way to alter the message data to update it with a user ID based on the the certificate details - yes you can change the bytes in a channel exit, but you need to know which bytes and that format is not published by IBM.

I really do think your best bet is to change the application to accommodate this new requirement that you didn't previously have. Once a message is put, there is no way to trace back to the certificate details.

You said having a different queue is not an option - could you share why? You could have a program read from this other queue that the certificate authenticated applications are the only ones authorised to put to, and have it update the messages to have the correct user ID and then forward the messages onto the 'real' input queue?

Anyway, not sure what else to tell you.

Cheers,
Morag

Hi,

To have different queue is not an option . We don't want to change the application. Right now client application passes mf user id and pass ticket on ApplIdentityData . Infrastructure transaction reads input messages , performs sign in with user/password and starts application transaction under this user.  It's fine for "real" users but for machine users ( mainly ESB )  we would like to use certificate authentication ( in order to skip sign in )  and to define those users w/o password at all. Because otherwise any person who knows those user's name can revoke them by trying to login with wrong password. 

Yulia.

Hi Yulia,

If the client has authority to, and is setting ApplIdentityData in the MQMD of the message, they must also have the authority to (and indeed should) set all the other identity context fields in the MQMD of the message. Can you have them set the User Identifier appropriately so you can tell them apart?

Alternatively, you could get them to set their application name at connect time and then this would be put into the PutApplName MQMD field of the messages they sent. For details of how to set this, see More descriptive Application Names in IBM MQ

From my suggestions, you likely get the impression that there is no easy way to access the certificate of the putting application from the message when it is got from the queue. Even when messages are digitally signed when using AMS, there is no application access to that signature or the certificate details. You either are allowed to see the message or you are not.

I mention AMS because it may be useful for you to think about this. You don't mention why you need to know the certificate details of the putter. If it is just to tell between the two applications, then it would be interesting to know why? Can any application just tell you it is application A, or do you need proof that it is application A? What happens if application B asserts that it is application A?

Why don't they put their messages to different queues so that you can tell who is who that way? Also, then only application A would have put authority to APP.A.Q and only application B would have put authority to APP.B.Q and you wouldn't have a worry that the applications could be accidentally (or maliciously) asserting that they are not who they really are.

Anyway, hope some of that helps.

Cheers,
Morag

It's 3 input queues and not one.Each queue has long running transaction reading it. So we need to start new transactions . But those transactions names hard coded in application ( old ugly code ). I thought about putting to qalias but reading application cannot get it as far as I know . 

Yulia

The only place I can think of that you can obtain the certificate details would be in a channel exit. However, on a SVRCONN channel you have no architected way to alter the message data to update it with a user ID based on the the certificate details - yes you can change the bytes in a channel exit, but you need to know which bytes and that format is not published by IBM.

I really do think your best bet is to change the application to accommodate this new requirement that you didn't previously have. Once a message is put, there is no way to trace back to the certificate details.

You said having a different queue is not an option - could you share why? You could have a program read from this other queue that the certificate authenticated applications are the only ones authorised to put to, and have it update the messages to have the correct user ID and then forward the messages onto the 'real' input queue?

Anyway, not sure what else to tell you.

Cheers,
Morag

Hi,

To have different queue is not an option . We don't want to change the application. Right now client application passes mf user id and pass ticket on ApplIdentityData . Infrastructure transaction reads input messages , performs sign in with user/password and starts application transaction under this user.  It's fine for "real" users but for machine users ( mainly ESB )  we would like to use certificate authentication ( in order to skip sign in )  and to define those users w/o password at all. Because otherwise any person who knows those user's name can revoke them by trying to login with wrong password. 

Yulia.

Hi Yulia,

If the client has authority to, and is setting ApplIdentityData in the MQMD of the message, they must also have the authority to (and indeed should) set all the other identity context fields in the MQMD of the message. Can you have them set the User Identifier appropriately so you can tell them apart?

Alternatively, you could get them to set their application name at connect time and then this would be put into the PutApplName MQMD field of the messages they sent. For details of how to set this, see More descriptive Application Names in IBM MQ

From my suggestions, you likely get the impression that there is no easy way to access the certificate of the putting application from the message when it is got from the queue. Even when messages are digitally signed when using AMS, there is no application access to that signature or the certificate details. You either are allowed to see the message or you are not.

I mention AMS because it may be useful for you to think about this. You don't mention why you need to know the certificate details of the putter. If it is just to tell between the two applications, then it would be interesting to know why? Can any application just tell you it is application A, or do you need proof that it is application A? What happens if application B asserts that it is application A?

Why don't they put their messages to different queues so that you can tell who is who that way? Also, then only application A would have put authority to APP.A.Q and only application B would have put authority to APP.B.Q and you wouldn't have a worry that the applications could be accidentally (or maliciously) asserting that they are not who they really are.

Anyway, hope some of that helps.

Cheers,
Morag

Hi,

To have different queue is not an option . We don't want to change the application. Right now client application passes mf user id and pass ticket on ApplIdentityData . Infrastructure transaction reads input messages , performs sign in with user/password and starts application transaction under this user.  It's fine for "real" users but for machine users ( mainly ESB )  we would like to use certificate authentication ( in order to skip sign in )  and to define those users w/o password at all. Because otherwise any person who knows those user's name can revoke them by trying to login with wrong password. 

Yulia.

Hi Yulia,

If the client has authority to, and is setting ApplIdentityData in the MQMD of the message, they must also have the authority to (and indeed should) set all the other identity context fields in the MQMD of the message. Can you have them set the User Identifier appropriately so you can tell them apart?

Alternatively, you could get them to set their application name at connect time and then this would be put into the PutApplName MQMD field of the messages they sent. For details of how to set this, see More descriptive Application Names in IBM MQ

From my suggestions, you likely get the impression that there is no easy way to access the certificate of the putting application from the message when it is got from the queue. Even when messages are digitally signed when using AMS, there is no application access to that signature or the certificate details. You either are allowed to see the message or you are not.

I mention AMS because it may be useful for you to think about this. You don't mention why you need to know the certificate details of the putter. If it is just to tell between the two applications, then it would be interesting to know why? Can any application just tell you it is application A, or do you need proof that it is application A? What happens if application B asserts that it is application A?

Why don't they put their messages to different queues so that you can tell who is who that way? Also, then only application A would have put authority to APP.A.Q and only application B would have put authority to APP.B.Q and you wouldn't have a worry that the applications could be accidentally (or maliciously) asserting that they are not who they really are.

Anyway, hope some of that helps.

Cheers,
Morag