Using client certificate authentication with the REST API and IBM MQ Console
You can map client certificates to principals to authenticate IBM® MQ Console and REST API users.
Before you begin
- Configure users, groups, and roles to be authorized to use the IBM MQ Console and REST API. For more information, see Configuring users and roles.
- When you use the REST API,
you can query the credentials of the current user by using the HTTP GET method on the
login
resource, providing the client certificate to authenticate the request. This request returns information about the authentication method, the user name, and the roles that the user is assigned. For more information, see GET/login
. - When you map client certificates to principals to authenticate users, the distinguished name of
the client certificate is used to match against users in the configured user registry:
- For a basic registry, the Common Name (CN) is matched against the user. For example,
CN=Fred, O=IBM, C=GB
is matched against a user name ofFred
. - For an LDAP registry, by default the full distinguished name is matched against LDAP. You can set up filters and mapping to customize the matching. For more information, see Liberty:LDAP certificate map mode in the WebSphere® Application Server Liberty documentation.
- For a basic registry, the Common Name (CN) is matched against the user. For example,
About this task
When a user authenticates by using a client certificate, the certificate is used in place of a user name and password. For the REST API, the client certificate is provided with each REST request to authenticate the user. For the IBM MQ Console, when a user logs in with a certificate, the user cannot then be logged out.
The procedure assumes the following information:
- That your
mqwebuser.xml
file is based one of the following samples:basic_registry.xml
local_os_registry.xml
ldap_registry.xml
zos_saf_registry.xml
- That you are using a UNIX, Linux®, or Windows system.
- You are a privileged user.
Note: The following procedure outlines the steps necessary to use client certificates with the
IBM MQ Console and REST API. For developer convenience, the steps detail how
to create and use self-signed certificates. However, for production, use certificates that are
obtained from a certificate authority.
Procedure
Example
Important: In the example, not all cURL implementations support self signed
certificates, so you must use a curl that does.
The following cURL example shows how to create a new queue
Q1
, on queue manager QM1
, with client certificate authentication.
The exact configuration of this cURL command depends on the libraries that cURL was built against.
The example is based on a Windows system, with cURL
built against OpenSSL:- From IBM MQ 9.0.5, you only need to
issue a single HTTP request. Use the HTTP POST method with the queue resource, authenticating with
the client certificate and including the
ibm-mq-rest-csrf-token
HTTP header with an arbitrary value. This value can be anything, or blank; it is not checked by the mqweb server.IBM MQ 9.0.5 and later:curl -k https://localhost:9443/ibmmq/rest/v1/admin/qmgr/QM1/queue -X POST - -cert-type P12 --cert c:\user.p12:password -H "ibm-mq-rest-csrf-token: value" -H "Content-Type: application/json" --data "{\"name\":\"Q1\"}"
- For IBM MQ 9.0.4 and earlier two HTTP requests are
needed:
- The first request generates the CSRF token cookie.Use the HTTP GET method with the
login
resource, authenticating with the client certificate. The CSRF token that is returned is stored within thecookiejar.txt
file. The--cert-type1
flag specifies that the certificate is a PKCS#12 certificate. The--cert
flag specifies the location of the certificate, followed by a colon,:
, and then the password for the certificate. The-c
flag specifies the location of the file to store the CSRF token in:curl -k https://localhost:9443/ibmmq/rest/v1/login --cert-type P12 --cert c:\user.p12:password -c c:\cookiejar.txt
- The second request creates the queue.
Use the HTTP POST method with the queue resource, authenticating with the client certificate and including the contents of the CSRF token in a header:
IBM MQ 9.0.3 and earlier:curl -k https://localhost:9443/ibmmq/rest/v1/qmgr/QM1/queue -X POST --cert-type P12 --cert c:\user.p12:password -H "ibm-mq-rest-csrf-token: A6E85DE02E15EEAD2DBE49C0BCD6F191A7FA9535A161A4B7F019F2DE4625A8A5D24191E2409D2011F8700 8E28786BD4E0ABD202B26C89360E8DA1F77CE737167A08E54AAB7C932CED1CF040E1F83C1D87F49C50BE724803A1642DB23FDF959CAA27B12 A5BE36259FC2D9F92199B8AFFE886670EE454BD4B14A32C8A24E574F1FA0F251686B3670ED24F301615FC417BD40457CFCC92AC15C1A1C567 3BCBB43963598FA9A1A77D91F53861290B0598AADD04591CEFBD18D6D55BB157A4F67FDB4D203AD42EB82799AC61CA0071417446C9E47A982 099C0331AE4F3CD9C2F1611FC5FB122CE3C0F0A60AAC166EF98DE19234A524265391F9BF5496695EEAFED847" -H "Content-Type: application/json" --data "{\"name\":\"Q1\"}"
- The first request generates the CSRF token cookie.