Enabling HTTPS access to the Akana Administration Console

Learn how to configure the container system.properties file to enable HTTPS access to the Akana Administration Console.

Introduction
Configuration
1. Step 1: Add HTTPS listener in properties file
2. Step 2: Optional additional configuration to restrict Akana Administration Console access to ports defined in the system.properties file
Troubleshooting

Introduction

You can set up HTTPS access to the Akana Administration Console by enabling an HTTPS port.

All you need to do is define the HTTPS listener in the system.properties file for the container.

Configuration

There is one basic configuration step, and one additional step you can take to further restrict assess:

Step 1: Add HTTPS listener in properties file
Step 2: Optional additional configuration to restrict Akana Administration Console access to ports defined in the system.properties file

Step 1: Add HTTPS listener in properties file

To enable an HTTPS listener, you must update the system.properties file in the {release_directory}/instances/{containername} folder, as shown below. In this example, we use port 9446.

With the settings below, access to the Akana Administration Console is limited to the specified HTTPS listener.

To modify the system.properties file to enable an HTTPS listener

Open the {release_directory}/instances/{containername}/system.properties file in a text editor. An example is shown below.
Remove the following settings:
- org.osgi.service.http.port=9000
- com.soa.http.bind.all=true
Add the following settings:
- org.osgi.service.http.port.secure=9446
- com.soa.http.bind.all.secure=true
Save changes.
Restart the container.

Step 2: Optional additional configuration to restrict Akana Administration Console access to ports defined in the system.properties file

When you've modified the properties in the system.properties file as covered in Step 1 above, the Akana Administration Console is accessible:

To the port you defined in the system.properties file.
To any other ports defined for that container in Policy Manager.

If you want to further restrict access to the Akana Administration Console, so that it is only accessible via the port defined in the system.properties file, there is an additional configuration step you can take. By modifying a specific configuration property in the Akana Administration Console, it will not be available to additional ports defined for the container in Policy Manager.

To do this, follow the steps below.

To restrict Akana Administration Console access to ports defined in the system.properties file

When the container is up and running, log in to the Akana Administration Console (https://localhost:{port}/admin/).
Go to Configuration > Configuration Categories and choose the com.soa.admin.console category as shown below.
Change the admin.console.access.restricted property from false (the default) to true.
For details about this property, see admin.console.access.restricted property settings below.
Save changes.

admin.console.access.restricted property settings

The admin.console.access.restricted setting has two possible values:

False (the default) means you can access the Akana Administration Console:
- Through the port defined in the system.properties file.
- Through the listeners defined in the Policy Manager workbench (see About Listeners in the Policy Manager help).
True (more secure) means you can access the Akana Administration Console:
- Only through the port defined in the system.properties file.
  If you try to access the Akana Administration Console using any port not defined in the system.properties file, the response will be a 404 error.

Troubleshooting

If everything appears to be configured correctly and you are still seeing 404 errors when you try to launch the Akana Administration Console, review the following steps to attempt to troubleshoot the problem.

Step 1: Inspect Log

Inspect the container logs in the {release_directory}\instances\{containername}\logs folder and search for the following errors near the startup:

Caused by: java.net.BindException: Address already in use
  at java.net.PlainSocketImpl.socketBind(Native Method)
  at java.net.PlainSocketImpl.bind(Unknown Source)
  at java.net.ServerSocket.bind(Unknown Source)
  at java.net.ServerSocket.<init>(Unknown Source)

These errors mean that the container is trying to start its listener, but something is already listening on the port assigned in the system.properties file.

Step 2: Resolve

Stop the container and check to make sure that nothing is running on the port that the container is configured to run on. If nothing is running, it means that the container is trying to start TWO listeners on the same port.
Check system.properties in the container directory. It will specify listeners that the container uses on initial startup. For example:
```
com.soa.http.host=hostname
org.osgi.service.http.port.secure=9446
com.soa.http.bind.all.secure=true
```
Compare the host, port, and bind settings above with the actual Policy Manager listeners defined in the Policy Manager Management Console. If the ports specified in the system.properties file are different from the ports specified in Policy Manager, the problem must exist elsewhere. If the port numbers match, then ONE of the following must occur:
- com.soa.http.bind.all.secure in the system.properties file AND the Bind to All Interfaces option for the HTTPS container listener in the Policy Manager Management Console must both be set.
- The com.soa.http.host value in the system.properties file and the hostname in the Policy Manager Management Console must match.
The reason is that when Policy Manager starts its listener, it tries to determine whether one already exists on the same port and host. If it finds one already running, it uses that port. If the host names are different, or if they are not running on all interfaces, Policy Manager might not be able to find the listener already running, and might therefore try to start a new one on the same port.