Friday, 21 April 2017

WebSphere MQ - Advanced Message Security - Some tinkering and AMQ9021

This is the first of a few posts about my voyage of discovery with WebSphere MQ ( now IBM MQ ) Advanced Message Security (AMS), in the context of message authentication and encryption.

Thus far, I've broken it twice :-)

I'm following this tutorial: -


and was able to successfully send messages from Alice to Bob, via a MQ Queue Manager.

However, I did hit two exceptions: -

/opt/ibm/mqm/samp/bin/amqsput TESTQ TESTQM

Sample AMQSPUT0 start
target queue is TESTQ
MQOPEN ended with reason code 2063
unable to open queue for output
Sample AMQSPUT0 end


The Queue Manager log gave me the queue: -

cat /var/mqm/qmgrs/TESTQM/errors/AMQERR01.LOG 

04/21/2017 04:35:27 PM - Process(27379.1) User(alice) Program(amqsput)
                    Host(bpm857.novalocal) Installation(Installation2)
                    VRMF(7.5.0.2) QMgr(TESTQM)
                   
AMQ9021: An error occured during the certificate import for the following DN:
CN=bpm857.novalocal,OU=PSCell1,OU=Dmgr,O=IBM,C=US, result: 60

EXPLANATION:
The distinguished name is not present in the keystore or invalid.

AMQ9070: The WebSphere MQ security policy interceptor failed to validate a
certificate.

EXPLANATION:
The WebSphere MQ security policy interceptor could not validate a certificate.

...

This seen when attempting to send a message as user Alice.

In the first instance, this was occurring because I'd put the Personal Certificate for my WAS cell: -

"CN=bpm857.novalocal,OU=PSCell1,OU=Dmgr,O=IBM,C=US"

into the MQ Security Policy: -

setmqspl -m $QMGR -p $Q -s SHA1 -a "CN=alice,O=IBM,C=GB" -e AES256 -r "CN=bob,O=IBM,C=GB" -r "CN=bpm857.novalocal,OU=PSCell1,OU=Dmgr,O=IBM,C=US"

rather than the Signer Certificate: -

setmqspl -m $QMGR -p $Q -s SHA1 -a "CN=alice,O=IBM,C=GB" -e AES256 -r "C=US, O=IBM, OU=Dmgr, OU=PSCell1, OU=Root Certificate, CN=bpm857.novalocal"

I'd pulled the Subject DN of the certificate via openssl : -

openssl x509 -in /tmp/was_ca.arm -text -noout

...
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 728601959222 (0xa9a40f9b36)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=IBM, OU=Dmgr, OU=PSCell1, OU=Root Certificate, CN=bpm857.novalocal
        Validity
            Not Before: Mar 12 07:12:08 2017 GMT
            Not After : Mar  8 07:12:08 2032 GMT
        Subject: C=US, O=IBM, OU=Dmgr, OU=PSCell1, OU=Root Certificate, CN=bpm857.novalocal
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)


It was also necessary to add the Signer Certificate into Alice's key store: -

/opt/ibm/mqm/bin/runmqakm -cert -add -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -label CN=BPM857 -file /tmp/was_ca.arm 

Once I did this, I hit another problem: -

04/21/2017 04:58:28 PM - Process(28212.1) User(alice) Program(amqsput)
                    Host(bpm857.novalocal) Installation(Installation2)
                    VRMF(7.5.0.2) QMgr(TESTQM)
                   
AMQ9021: An error occured during the certificate import for the following DN:
CN=bpm857.novalocal,OU=PSCell1,OU=Dmgr,O=IBM,C=US, result: 57

EXPLANATION:
The distinguished name is not present in the keystore or invalid.

...

The solution wasn't too difficult to find …

I'd added the Signer Certificate into the MQ Security Policy in the wrong format.

I'd added this: -

C=US, O=IBM, OU=Dmgr, OU=PSCell1, OU=Root Certificate, CN=bpm857.novalocal

rather than this: -

CN=bpm857.novalocal, OU=Root Certificate, OU=PSCell1, OU=Dmgr, O=IBM, C=US

i.e.

setmqspl -m $QMGR -p $Q -s SHA1 -a "CN=alice,O=IBM,C=GB" -e AES256 -r "CN=bob,O=IBM,C=GB" -r "CN=bpm857.novalocal, OU=Root Certificate, OU=PSCell1, OU=Dmgr, O=IBM, C=US"

Once I fixed the policy, it just started working.

Now to get WebSphere Application Server (WAS) to read messages from the Queue …..

For the record, these sources were of use: -





Thursday, 20 April 2017

IBM Operational Decision Manager - Adding a LDAP server via the Decision Center Business Console

This has been on my To-Do list for some time.

One of my colleagues was looking to configure connectivity between the IBM ODM Decision Center Business Console and an LDAP server.

He, like me, is using ODM Advanced 8.8.1.

I'd previously installed and configured this version on WebSphere Application Server (WAS) Network Deployment 8.5.5.

This is what I have installed: -

/opt/ibm/InstallationManager/eclipse/tools/imcl listInstalledPackages

com.ibm.cic.agent_1.8.6000.20161118_1611
com.ibm.websphere.IBMJAVA.v71_7.1.3040.20160720_1746
com.ibm.websphere.ND.v85_8.5.5010.20160721_0036
com.ibm.websphere.IHS.v85_8.5.5010.20160721_0036
com.ibm.websphere.PLG.v85_8.5.5010.20160721_0036
com.ibm.websphere.odm.dc.v88_8.8.1001.20160912_1319
com.ibm.websphere.odm.ds.rules.v88_8.8.1001.20160912_1339
com.ibm.websphere.odm.pt.dc.v88_8.8.1001.20160912_1435
com.ibm.websphere.odm.pt.rules.v88_8.8.1001.20160912_1441

/opt/ibm/InstallationManager/eclipse/tools/imcl listInstalledPackages -features

com.ibm.cic.agent_1.8.6000.20161118_1611 : 
com.ibm.websphere.IBMJAVA.v71_7.1.3040.20160720_1746 : 
com.ibm.websphere.ND.v85_8.5.5010.20160721_0036 : com.ibm.sdk.6_64bit,ejbdeploy,embeddablecontainer,thinclient
com.ibm.websphere.IHS.v85_8.5.5010.20160721_0036 : arch.64bit
com.ibm.websphere.PLG.v85_8.5.5010.20160721_0036 : com.ibm.jre.6_64bit
com.ibm.websphere.odm.dc.v88_8.8.1001.20160912_1319 : Documentation,com.ibm.wdc.rules.samples.feature
com.ibm.websphere.odm.ds.rules.v88_8.8.1001.20160912_1339 : com.ibm.wds.rules.res.feature,com.ibm.wds.rules.samples.feature,com.ibm.wds.rules.studio.feature,com.ibm.wds.updatesites.feature
com.ibm.websphere.odm.pt.dc.v88_8.8.1001.20160912_1435 : 
com.ibm.websphere.odm.pt.rules.v88_8.8.1001.20160912_1441 : 

My LDAP is a VM running Windows Server 2012, which is configured as an Active Directory server ( plus the usual DNS, Kerberos services etc. ).

Having checked that I can bind to AD via LDAP, from the command-line: -

ldapsearch -x -h windows2012.uk.ibm.com -p 389 -D CN=LDAPBindUser,CN=Users,DC=uk,DC=ibm,DC=com -w Qpassw0rd -b CN=Users,DC=uk,DC=ibm,DC=com CN=BPMUser1 memberOf

# BPMUser1, Users, uk.ibm.com
dn: CN=BPMUser1,CN=Users,DC=uk,DC=ibm,DC=com
memberOf: CN=BPMUsers,CN=Users,DC=uk,DC=ibm,DC=com

...

ldapsearch -x -h windows2012.uk.ibm.com -p 389 -D CN=LDAPBindUser,CN=Users,DC=uk,DC=ibm,DC=com -w Qpassw0rd -b CN=Users,DC=uk,DC=ibm,DC=com sAMAccountName=bpmuser1

# BPMUser1, Users, uk.ibm.com
dn: CN=BPMUser1,CN=Users,DC=uk,DC=ibm,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: BPMUser1

...

I then logged into the Business Console : -


includes an Administration tab: -


Using the + icon to create a new connection: -


Having created the connection, I was then able to import Groups: -



and Users: -



I can/will tinker further, but this is a good starter for 10.

For the record, I did see this early on: -

[20/04/17 16:40:28:822 BST] 000000c3 LDAPManagemen I   Cannot parse url: windows2012.uk.ibm.com
                                 javax.naming.NamingException: Cannot parse url: windows2012.uk.ibm.com [Root exception is java.net.MalformedURLException: Invalid URI: windows2012.uk.ibm.com]
at com.sun.jndi.ldap.LdapURL.<init>(LdapURL.java:109)

Caused by: java.net.MalformedURLException: Invalid URI: windows2012.uk.ibm.com

because I got the LDAP URL wrong. I had: -

windows2012.uk.ibm.com

rather than this: -

Thanks to this: -
Lovely stuff

Thursday, 13 April 2017

JMSMQ1112: The operation for a domain specific object was not valid. The operation 'createProducer()' is not valid for type 'com.ibm.mq.jms.MQQueue'

We saw this exception today: -

Caused by: com.ibm.msg.client.jms.DetailedJMSException: JMSMQ1112: The operation for a domain specific object was not valid. The operation 'createProducer()' is not valid for type 'com.ibm.mq.jms.MQQueue'. A JMS application attempted to perform an operation on domain specific object, but the operation is valid only for the other messaging domain. Make sure that the JMS objects and operations used by your application are relevant for the required messaging domain. If your application uses both messaging domains, consider using domain independent objects throughout the application.

whilst testing an application that had been migrated from WebSphere Application Server (WAS) Network Deployment (ND) 7.0.0.27 to WAS ND 8.5.5.10.

The application or, more specifically, the Message Driven Bean (MDB) is activated ( woken up ) by a Message being placed onto a Queue on an WebSphere MQ Queue Manager, using a JMS Activation Specification and a JMS Queue.

The JMS artefacts act as a buffer ( more accurately, an abstraction ) between the actual Java code and the WebSphere MQ configuration.

This means that the developer merely needs to write his/her code to hit a JMS queue via an alias e.g. jms/OutputQ, rather than specifically writing WebSphere MQ client code within their Java code.

The actual awakening of the MDB occurs via the Activation Specification, rather than in the Java code itself.

Anyway, the incoming Message was awakening the MDB, proving that the WAS to MQ configuration was in order i.e. that there wasn't a problem with the "plumbing" - Queue Manager, Channel, Authentication etc.

And yet ….

I pinged the question to one of my fellow gurus, and he suggested checking the Class Loader.

In parallel, the application developer also dug through the code, and a trace ( thanks to this MustGather: MQ Java Message Service (JMS) problems with WebSphere Application Server ) and came to the same conclusion.

He suspected that the underlying WAS code was actually checking whether the target JMS Queue ( jms/OutputQ ) was really a MQ Queue ( as configured in WAS using the WebSphere MQ Resource Adapter ).

We checked the application ( the Enterprise Archive (EAR) that included the MDB ), and realised that the Class Loader Order differed from the old environment ( WAS 7 ) and the new environment  ( WAS 8.5.5 ), specifically: -


Once we changed the EAR from Parent Last to Parent First, which automatically caused the application to restart, the problem disappeared.

The developer checked and realised that they were packaging JMS 1.1 classes within the EAR file.

This meant that, in the WAS 8.5.5 environment, the JMS classes were being loaded from the EAR rather than from the WAS JVM itself.

Whilst Parent Last is NOT necessarily a problem, it was an issue here because JMS was being loaded TWICE.

Nice :-)

IBM Business Process Manager - RESTing on my laurels

An exceptionally good friend asked me about REST, in the context of the WebSphere Liberty Profile and the "new" Collectives management interface.

Having provided some context about REST, I demonstrated how I can use a Firefox addon, REST Easy, to access the IBM BPM REST UI: -


which returns: -


and: -


However, I also asked my Slack buddies for recommendations on other REST clients, and someone rightly pointed out the Swiss Army Knife that is curl which is built into most Unix OS, including macOS.

So here's me accessing the same REST API: -

curl -i -k -u wasadmin:passw0rd -X GET https://bpm857.novalocal:8443/rest/bpm/wle/v1/process/currentlyExecuting 

which returns: -

HTTP/1.1 200 OK
Date: Thu, 13 Apr 2017 09:23:34 GMT
X-Powered-By: Servlet/3.0
BPM_GENERIC_HEADER: SERVED
Cache-Control: no-cache, no-store, max-age=0
Set-Cookie: LtpaToken2=cxzAh/CU/jv6oBp37tplPmD7DS7toa92E2Pt5OJ0RyjtdymQ7gGeoBMuXpuf4yUTeXBAdtOzo+TCVWRFUxwJN2MF/yVnmHDawFK+L1kOvCz/3d5oe6WJ63IyVHm8j5esGreaWBQoWol0io2tRHvJxDrPb40YZhx/xcxO8YouHWud3B2BzBjvcRzKAhE0kFHKJ691BZZ6N3vQl+KDNFABB7aegqf98QlC7zTD6lj9SGy2WqEmm+TULisRfG+hmF19toU5gEjTIZ1Yxd7InefsOL4AsRLZnb6Bk8mfRFnofyP06+YAHSHkB8t5Vbvtm5F+ozDk/lMTYlyROBcSZVbepImrScgYCDZYFuHIffvHYSGdPT/CoGdODFOHOApqOTnIMVg5jTkHetiGpBFHG7DzjpxfdwMxc+Lg+31vOexpDPnRcO+KvHuyzKbpYiZcg1c5ozfIGvT+dW0zPeA/SZVXJgLypzA0QgF/MTzaNyvoON4SW2LlIicTnhcYcxj99h409m8LVb8MMIF0vL10UW3jJ3RIHjSfITalICa9faLgz1xAfdqVvMCRUdg1B8BdD6K28QEs8avWEXjYuDsYzl1ZUiMK18olxqV+qPK8+DcXIjW0NDWMW2iZDxahHJgpOQ4srIS3X248/GJaNeYeLu5wTp25/m/tksGpQFQA79fZeYg=; Path=/; HttpOnly
Set-Cookie: JSESSIONID=0000NWjcOUgFHUo5Oq2o6OuKtuS:1bb38qov8; Path=/; HttpOnly
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Transfer-Encoding: chunked
Content-Type: application/json
Content-Language: en-US

{"status":"200","data":{"instanceIDs":null}}

which is rather lovely.

Of course, BPM has a built-in REST client: -


which also is rather useful.


WebSphere Application Server - manageprofiles.sh and the missing Java security policies

We saw a problem the other day, whilst creating a new IBM BPM Deployment Environment via the BPMConfig.sh script.

When we dug into the problem further, it was apparent that the underlying manageprofiles.sh script was failing.

Having resolved the problem ( more later ), I replicated it on a clean VM this morning.

So, to start with, I attempt to create a new WAS profile: -

/opt/ibm/WebSphere/AppServer/bin/manageprofiles.sh -create -templatePath /opt/ibm/WebSphere/AppServer/profileTemplates/managed -profileName AppSrv02 -nodeName Node1

This fails with: -

INSTCONFFAILED: The profile could not be created.  For more information, consult the /opt/ibm/WebSphere/AppServer/logs/manageprofiles/AppSrv02_create.log file.

When one digs into the logs: -

view /opt/ibm/WebSphere/AppServer/logs/manageprofiles/AppSrv02_create.log 

there are a fair number of failures: -

    <message>Task stopped for: fail - FAILURE</message>
    <message>Target stopped for: failIfError - FAILURE</message>


and exceptions: -

    <message>Exception was thrown, type of exception is: class org.apache.tools.ant.BuildException</message>

but there is also this: -

    <date>2017-04-13T07:41:42</date>
    <millis>1492065702583</millis>
    <sequence>2363</sequence>
    <logger>com.ibm.ws.install.configmanager.actionengine.ant.utils.ANTLogToCmtLogAdapter</logger>
    <level>WARNING</level>
    <class>com.ibm.ws.install.configmanager.logging.LogUtils</class>
    <method>logException</method>
    <thread>0</thread>
    <message>/opt/ibm/WebSphere/AppServer/profileTemplates/managed/actions/scripts/importExternalLogs.xml:30: Failure occured while attempting to Setting the security settings in the default security template.
        at org.apache.tools.ant.taskdefs.Exit.execute(Exit.java:139)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)
        at org.apache.tools.ant.Task.perform(Task.java:364)
        at org.apache.tools.ant.Target.execute(Target.java:341)
        at org.apache.tools.ant.Target.performTasks(Target.java:369)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216)


which was the thing that led me to root cause.

Applying the First Rule of Problem Determination - WHAT HAS CHANGED - I realised that the last-but-one thing that we had done was to switch the Java SDK Policy Files from restricted to unrestricted, in order to support AES key lengths greater than 256 bits.

This is documented in way more detail here: -

By default, the IBM® SDK, on all platforms, provides strong but limited jurisdiction policy files. To use unlimited jurisdiction policy files by default, place the US_export_policy.jar and the local_policy.jar in the jre/lib/security/ directory of the SDK.


When I traced back, I realised that, as part of this change, we had backed out the old policy files: -

cd /opt/ibm/WebSphere/AppServer/java_1.7.1_64/jre/lib/security/
mv US_export_policy.jar US_export_policy.RAJ
mv local_policy.jar local_policy.RAJ

*BUT* not unpacked the replacement unrestricted policy files :-(

So this is what we had: -

ls -al

total 144
drwxr-xr-x  2 wasadmin wasadmins   4096 Apr 13 07:40 .
drwxr-xr-x 16 wasadmin wasadmins   4096 Mar 29 15:36 ..
-rwxr-xr-x  1 wasadmin wasadmins   4054 Jul 20  2016 blacklist
-rwxr-xr-x  1 wasadmin wasadmins 103822 Mar 24  2014 cacerts
-rwxr-xr-x  1 wasadmin wasadmins   2532 Mar 24  2014 java.policy
-rwxr-xr-x  1 wasadmin wasadmins  10560 Mar 24  2014 java.security
-rwxr-xr-x  1 wasadmin wasadmins     98 Jul 20  2016 javaws.policy
-rwxr-xr-x  1 wasadmin wasadmins   2640 Jul 20  2016 local_policy.RAJ
-rwxr-xr-x  1 wasadmin wasadmins      0 Jul 20  2016 trusted.libraries
-rwxr-xr-x  1 wasadmin wasadmins   2175 Jul 20  2016 US_export_policy.RAJ

In other words, the Java SDK ( JRE ) couldn't find the actual local_policy.jar and US_export_policy.jar files :-(

Once we put the the unrestricted policy files in place: -

unzip ~/unrestrictedpolicyfiles.zip 
Archive:  /home/wasadmin/unrestrictedpolicyfiles.zip
  inflating: US_export_policy.jar    
  inflating: local_policy.jar        

ls -al

total 152
drwxr-xr-x  2 wasadmin wasadmins   4096 Apr 13 07:56 .
drwxr-xr-x 16 wasadmin wasadmins   4096 Mar 29 15:36 ..
-rwxr-xr-x  1 wasadmin wasadmins   4054 Jul 20  2016 blacklist
-rwxr-xr-x  1 wasadmin wasadmins 103822 Mar 24  2014 cacerts
-rwxr-xr-x  1 wasadmin wasadmins   2532 Mar 24  2014 java.policy
-rwxr-xr-x  1 wasadmin wasadmins  10560 Mar 24  2014 java.security
-rwxr-xr-x  1 wasadmin wasadmins     98 Jul 20  2016 javaws.policy
-r--r--r--  1 wasadmin wasadmins   2253 Oct 12  2012 local_policy.jar
-rwxr-xr-x  1 wasadmin wasadmins   2640 Jul 20  2016 local_policy.RAJ
-rwxr-xr-x  1 wasadmin wasadmins      0 Jul 20  2016 trusted.libraries
-r--r--r--  1 wasadmin wasadmins   2240 Oct 12  2012 US_export_policy.jar
-rwxr-xr-x  1 wasadmin wasadmins   2175 Jul 20  2016 US_export_policy.RAJ

the manageprofiles.sh script just bloomin' worked: -

/opt/ibm/WebSphere/AppServer/bin/manageprofiles.sh -create -templatePath /opt/ibm/WebSphere/AppServer/profileTemplates/managed -profileName AppSrv02 -nodeName Node1

INSTCONFSUCCESS: Success: Profile AppSrv02 now exists. Please consult /opt/ibm/WebSphere/AppServer/profiles/AppSrv02/logs/AboutThisProfile.txt for more information about this profile.

although it was necessary to clean up the profile path from the previous failed run: -

rm -Rf /opt/ibm/WebSphere/AppServer/profiles/AppSrv02/

to avoid this: -

The following validation errors were present with the command line arguments: 
profilePath: The profile path is not valid.


So, in conclusion, REMEMBER WHAT YOU LAST DID ( aka What Has Changed )

IBM Operational Decision Manager - Where's my Decision Center Business Console gone ?

This is a new build of IBM ODM Advanced 8.8.1, and I'm trying to log into, and use, the Decision Center Business Console: -


Having logged in, with a valid user, I get this: -

and, in the logs: -

tail -f /opt/ibm/WebSphere/AppServer/profiles/AppSrv01/logs/Node1-DCServer/SystemOut.log

[13/04/17 07:21:27:130 BST] 000000ac ServletWrappe I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [teamserver] [/decisioncenter] [/WEB-INF/views/login.jsp]: Initialization successful.
[13/04/17 07:22:48:326 BST] 000000b0 authz         I   CWWIM2000I Initialization of the authorization component completed successfully.
[13/04/17 07:22:53:306 BST] 000000b1 InternalGener I   DSRA8225I: DataSource JNDI name : jdbc/ilogDataSource
[13/04/17 07:22:53:309 BST] 000000b1 InternalGener I   DSRA8203I: Database product name : DB2/LINUXX8664
[13/04/17 07:22:53:311 BST] 000000b1 InternalGener I   DSRA8204I: Database product version : SQL10058
[13/04/17 07:22:53:312 BST] 000000b1 InternalGener I   DSRA8205I: JDBC driver name  : IBM DB2 JDBC Universal Driver Architecture
[13/04/17 07:22:53:313 BST] 000000b1 InternalGener I   DSRA8206I: JDBC driver version  : 3.61.65
[13/04/17 07:22:53:313 BST] 000000b1 InternalGener I   DSRA8218I: JDBC driver specification level  : 3.0
[13/04/17 07:22:53:314 BST] 000000b1 InternalDB2Un I   DSRA8212I: DataStoreHelper name is: com.ibm.websphere.rsadapter.DB2UniversalDataStoreHelper@456a0905.
[13/04/17 07:22:53:315 BST] 000000b1 WSRdbDataSour I   DSRA8208I: JDBC driver type  : 4
[13/04/17 07:22:53:636 BST] 000000b1 HandlerMethod E   An error has occurred in trying to access data source &#39;jdbc/ilogDataSource&#39;: Not initialized. Check that the data source exists on the application server or contact your administrator.
                                 com.ibm.rules.decisioncenter.web.core.ConnectionException: An error has occurred in trying to access data source 'jdbc/ilogDataSource': Not initialized. Check that the data source exists on the application server or contact your administrator.
at com.ibm.rules.decisioncenter.web.core.ApplicationInterceptor.throwDataSourceException(ApplicationInterceptor.java:319)
at com.ibm.rules.decisioncenter.web.core.ApplicationInterceptor.preHandle(ApplicationInterceptor.java:157)
at org.springframework.web.servlet.HandlerExecutionChain.applyPreHandle(HandlerExecutionChain.java:134)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:913)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:851)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:953)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:844)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:575)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:829)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1232)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:781)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:480)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:97)
at com.ibm.rules.decisioncenter.web.core.filters.SecurityCheckPointFilter.doFilter(SecurityCheckPointFilter.java:95)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.rules.decisioncenter.web.core.filters.RemoteSessionFilter.doFilterInternal(RemoteSessionFilter.java:79)
at com.ibm.rules.decisioncenter.web.core.filters.RemoteSessionFilter.doFilter(RemoteSessionFilter.java:59)
at com.ibm.rules.decisioncenter.web.core.filters.SessionFilter.access$001(SessionFilter.java:32)
at com.ibm.rules.decisioncenter.web.core.filters.SessionFilter$1.doFilter(SessionFilter.java:73)
at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at com.ibm.rules.decisioncenter.web.core.filters.SessionFilter.doFilter(SessionFilter.java:70)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.rules.decisioncenter.web.core.filters.HttpPUTRequestFilter.doFilterInternal(HttpPUTRequestFilter.java:65)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:106)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:195)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:91)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:967)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1107)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:87)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:947)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1817)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:463)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:530)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:316)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:88)
at com.ibm.ws.ssl.channel.impl.SSLReadServiceContext$SSLReadCompletedCallback.complete(SSLReadServiceContext.java:1820)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1892)

[13/04/17 07:22:53:668 BST] 000000b1 ServletWrappe I com.ibm.ws.webcontainer.servlet.ServletWrapper init SRVE0242I: [teamserver] [/decisioncenter] [/WEB-INF/views/error.jsp]: Initialization successful.

I can, however, log into the Decision Center per se : -



At this point, I realised that I had *NOT* completed the setup: -


<sigh>

Once I did this, including the database setup, it just simply worked.

<sigh>

Wednesday, 5 April 2017

IBM Business Process Manager 8.5.7 Cumulative Fix (CF) 2017-03 - Out on Friday 31 March

From this: -

IBM BPM 8.5.7 CF2017.03 will be available on 31 March 2017

IBM Business Process Manager (BPM) updates are now released as quarterly cumulative fixes to enable you to get the latest fixes and product enhancements with a simple in-place upgrade. IBM BPM 8.5.7 Cumulative Fix 2017.03 is now available for you to download and upgrade today. Key highlights are outlined below. See Knowledge Center for full details.

and this: -


...
This 2017.03 cumulative fix comes with many and large security improvements:

• HTTPS enforcement for (almost) all web modules
• Security hardening configuration on by default
• Configuration options for group membership synchronization at login - with significant performance improvements by default
• A new JS API for deleting internal groups
• Support for ECCiphers configuration help
• A Trust Association Interceptor that avoids the basic authentication browser dialog in WebPD upon LTPA timeout
• and, of course, vulnerability fixes.
...

Definitely worth a read and a download ….