Host Environment
Update hosts file
Update the hosts file of the VM host with entries used to connect to the LMI config page and web reverse proxy:
127.0.0.2 config.docker-isva.ibm.com
127.0.0.3 www.docker-isva.ibm.com
Certificate files
Generate database and SSL certificate files
Generate postgres certificate:
$ mkdir -p ./certs/postgresql
$ openssl req -x509 -newkey rsa:4096 -keyout ./certs/postgresql/postgres.key -out ./certs/postgresql/postgres.crt -days 3650 -subj "/CN=postgresql/O=ibm/C=us" -nodes -addext "subjectAltName = DNS:postgresql"
Generating a 4096 bit RSA private key
.......................++++
........................................................................................................................++++
writing new private key to './certs/postgresql/postgres.key'
-----
$ cat ./certs/postgresql/postgres.crt ./certs/postgresql/postgres.key > ./certs/postgresql/postgres.pem
Generate SSL certificate: (see included file: openssl-docker-isva.cnf)
$ mkdir -p ./certs/ssl
$ openssl req -x509 -newkey rsa:4096 -keyout ./certs/ssl/docker-isva-key.pem -out ./certs/ssl/docker-isva-cert.pem -days 3650 -nodes -config ./openssl-docker-isva.cnf
Generating a 4096 bit RSA private key
...................................................................................................++++
......................................................................................................++++
writing new private key to './certs/ssl/dockermmfa-key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AU
State or Province Name (full name) [Some-State]:QLD
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:IBM Security
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:www.docker-isva.ibm.com
Email Address []:
$ openssl pkcs12 -export -out ./certs/ssl/docker-isva-keystore.p12 -inkey ./certs/ssl/docker-isva-key.pem -in ./certs/ssl/docker-isva-cert.pem
Enter Export Password: Passw0rd
Verifying - Enter Export Password: Passw0rd
We should now have the following certificate and key files:
$ tree certs/
certs/
├── postgresql
│ ├── postgres.crt
│ ├── postgres.key
│ └── postgres.pem
└── ssl
├── docker-isva-cert.pem
├── docker-isva-key.pem
└── docker-isva-keystore.p12
Import and trust browser certificate
Import the SSL certificate for your host OS and set it as trusted.
Starting containers
Postgres container
First, we need to start the database container using the latest verify-access-postgresql image from the IBM Container Registry (ICR).
We need to include the pgdata volume mount for persisting data, as well as mounting the postgresql certificate directory.
We supply the postgres username postgres and use the password Passw0rd.
We need to point to the postgres SSL keystore (using the mounted directory path), which will be at /var/local/postgres.pem.
We specify the database name isva and point to the server certificate we created earlier.
Lastly, we set the name and hostname of the container to postgresql, and specify to use the isva docker network.
$ docker run -t -d --restart always -v pgdata:/var/lib/postgresql/data -v ./certs/postgresql:/var/local -e POSTGRES_USER=postgres -e POSTGRES_PASSWORD=Passw0rd -e POSTGRES_DB=isva -e POSTGRES_SSL_KEYDB=/var/local/postgres.pem --hostname postgresql --name postgresql --network isva icr.io/isva/verify-access-postgresql:10.0.8.0
ISVA configuration container
Next, we need to start the ISVA configuration container using the verify-access-config image from ICR.
We need to include the isvaconfig volume mount for persisting data, which will be shared with the runtime and web reverse proxy containers.
We supply the admin user password Passw0rd.
We publish the local port to the bind address: 127.0.0.2:443 which will allow us to connect to the local management interface (LMI).
Lastly, we set the name and hostname of the container to isvaconfig, and specify to use the isva docker network.
$ docker run -t -d --restart always -v isvaconfig:/var/shared -e CONTAINER_TIMEZONE=Europe/London -e ADMIN_PWD=Passw0rd -p 127.0.0.2:443:9443 --hostname isvaconfig --name isvaconfig --network isva icr.io/isva/verify-access-config:10.0.8.0
ISVA web reverse proxy container
We can start the ISVA web reverse proxy container, though it won't be ready until we complete the required configuration steps.
This container uses the verify-access-wrp image from ICR.
We need to include the isvaconfig volume mount which will contain the configuration data.
We publish the local port to the bind address: 127.0.0.3:443 which will allow us to connect to the web reverse proxy.
We must specify the reverse proxy instance name, which must match the value we configure in later steps.
Lastly, we set the name and hostname of the container to isvawrp, and specify to use the isva docker network.
$ docker run -t -d --restart always -v isvaconfig:/var/shared -e CONTAINER_TIMEZONE=Europe/London -p 127.0.0.3:443:9443 -e INSTANCE=default --hostname isvawrp --name isvawrp --network isva icr.io/isva/verify-access-wrp:10.0.8.0
ISVA runtime container
We can start the ISVA runtime container, though it won't be ready until we complete the required configuration steps.
This container uses the verify-access-runtime image from ICR.
Again, we need to include the isvaconfig volume mount, which will contain the configuration data.
Lastly, we set the name and hostname of the container to isvaruntime, and specify to use the isva docker network.
$ docker run -t -d --restart always -v isvaconfig:/var/shared -e CONTAINER_TIMEZONE=Europe/London --hostname isvaruntime --name isvaruntime --network isva icr.io/isva/verify-access-runtime:10.0.8.0
Check running containers
We can see the status of the running containers with the docker ls command:
$ docker ls
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
529a8f9c09eb icr.io/isva/verify-access-runtime:10.0.8.0 "/sbin/bootstrap.sh" 2 minutes ago Up 2 minutes (unhealthy) 9080/tcp, 9443/tcp isvaruntime
d2f65f58957c icr.io/isva/verify-access-wrp:10.0.8.0 "/sbin/bootstrap.sh" 2 minutes ago Up 2 minutes (unhealthy) 9080/tcp, 127.0.0.3:443->9443/tcp isvawrp
f71996e3749e icr.io/isva/verify-access:10.0.8.0 "/sbin/bootstrap.sh" 2 minutes ago Up 2 minutes (healthy) 443/tcp, 127.0.0.2:443->9443/tcp isvaconfig
0fd238cf042e icr.io/isva/verify-access-postgresql:10.0.8.0 "/sbin/bootstrap.sh" 2 minutes ago Up 2 minutes 5432/tcp postgresql
Note the "unhealthy" status of the runtime and web reverse proxy containers can be ignored until we have completed the required configuration steps.
Configuring the environment
First steps
Now the configuration container is started, we can connect to the LMI: https://config.docker-isva.ibm.com/
Login as the admin user:
- Username: admin
- Password: Passw0rd
To complete the First Steps wizard, we must first agree to the Software License Agreement.
On the second page we have the option of changing the admin password. We will skip this and keep our initial password.
Once the setup is completed, we can reload the LMI. The dashboard should now be shown.
Configure the runtime
Before configuring the runtime database, we need to import the postgresql certificate so the verify access containers can communicate with the database.
First, use the menu at the top of the screen to navigate to: System > SSL Certificates
Select the lmi_trust_store certificate database and import the signer certificate:
- Certificate file: ./dockerkeys/postgresql/postgres.crt
- Label: postgres
Next, select the rt_profile_keys certificate database and import the signer certificate:
- Certificate file: ./dockerkeys/postgresql/postgres.crt
- Label: postgres
After updating both certificate databases, deploy and publish the pending changes.
Now we have loaded the required certificate, we can configure the runtime database.
Navigate to: System > Database Configuration
Switch to the Runtime Database tab.
Configure the runtime database using the parameters we provided when starting the containers.
We can use the postgresql hostname, which docker networking should resolve to the correct address.
The username, password and database name were all provided when starting the postgresql container.
- Type: PostgreSQL
- Address: postgresql
- Port: 5432
- Secure: true
- Username: postgres
- Password: Passw0rd
- DB Name: isva
Once configured, deploy and publish the pending changes.
Now, we can complete the Runtime configuration.
Navigate to: Web > Runtime Component
We will use the local LDAP server in this environment, so we just need to set the admin password.
- User Registry: LDAP Local
- Admin Password: Passw0rd
Once configured, deploy and publish the pending changes.
Finally, we need to activate the Base, AAC and FIM modules.
Navigate to: System > Activated Modules.
Import each of the license files, saving the configuration after uploading each file.
Once imported, deploy and publish the pending changes.
After activating the required modules, we must restart the config container:
$ docker stop isvaconfig && docker start isvaconfig
The environment is now configured with a local policy server and a local user registry.
Configure the web reverse proxy
Now we have the runtime configred, we can set up the web reverse proxy.
First we need to import the SSL certificate used when connecting to the reverse proxy.
Navigate to: System > SSL Certificates
Select the pdsrv certificate database and import the personal certificate:
- Type: PKCS12
- Certificate file: ./dockerkeys/ssl/docker-isva-keystore.p12
- Password: Passw0rd
After updating the certificate database, deploy and publish the pending changes, then restart the runtime container:
$ docker stop isvaruntime && docker start isvaruntime
Now we can configure the reverse proxy instance.
Navigate to: Web > Reverse Proxy
Configure a new Reverse Proxy instance:
- Instance name: default
- Host name: isvawrp
- Administrator password: Passw0rd
The remaining parameters can be left to their default values.
Once configured, deploy and publish the pending changes.
Next, we need to update the reverse proxy configuration to make use of our SSL certificate.
Select the new default instance and click the Edit button to show the reverse proxy configuration screen.
Switch to the SSL tab and update the SSL Server Certificate to use the www.docker-isva.ibm.com certificate.
Save the configuration update, deploy and publish the pending changes.
After publishing the new configuration, we can restart the wrp container:
$ docker stop isvawrp && docker start isvawrp
Create the test user
Before we can confirm the current configuration, we will need a test user to test basic username password authentication to the web reverse proxy.
Navigate to: Web > Policy Administration
Login as the sec_master user:
- Username: sec_master
- Password: Passw0rd
From the side menu, expand the User section and navigate to the Create User screen.
Create the test user with the following details:
- User ID: testuser
- Common name: testuser
- Surname: user
- Password: Passw0rd
- Registry UID:
cn=testuser,dc=iswga
- Account valid: yes
- Password valid: yes
- GSO User: no
- No Password Policy: no
Create the user, then navigate back to the LMI dashboard. You should see a pending change notification.
Deploy and publish the pending changes.
Restart the wrp and runtime containers:
$ docker stop isvawrp && docker stop isvaruntime && docker start isvaruntime && docker start isvawrp
Test the reverse proxy configuration
Now we have the reverse proxy configured, we can try to authenticate with our test user to confirm everything is working as expected.
Connect to the reverse proxy: https://www.docker-isva.ibm.com/
You should see the Application Gateway login screen.
Attempt to authenticate with the test username and password we just created:
- Username: testuser
- Password: Passw0rd
You should see a black screen with "IBM Security Verify Access" shown.
Configure the FIDO2 PAIR Scenario
Now we have our reverse proxy instance, we can configure it for use with our contex based access and authentication services.
Navigate to: Web > Reverse Proxy
Select the default instance and use the Manage dropdown to select: AAC and Federation Configuration > Authentication and Context Based Access Configuration
Complete the Authentication and Context Based Access Configuration wizard with the following settings: (note the easuser password differs from our existing admin passwords)
- AAC Runtime:
- Hostname: isvaruntime
- Port: 9443
- Username: easuser
- Password: passw0rd
- Load certificate: yes
- Junction: /mga
- FIDO2 PAIR:
- Configure Remember Me for FIDO2 PAIR: yes
- Remember Me Encryption Key Label: (www.docker-isva.ibm.com certificate label)
- Configure FIDO2 PAIR login template: yes
- Reuse Options:
- Reuse certificates: yes
- Reuse ACLs: yes
After completing the configuration wizard, deploy and publish the pending changes, then restart the runtime and wrp container:
$ docker stop isvawrp && docker stop isvaruntime && docker start isvaruntime && docker start isvawrp
Next, we need to configure a FIDO2 Relying Party.
Navigate to: AAC > FIDO2 Configuration
Add a new relying party with the following settings:
Save the new relying party configuration, deploy and publish the pending changes, then restart the runtime container:
$ docker stop isvaruntime && docker start isvaruntime
The IFA authentication scenario will make use of several authentication policies.
All of our authentication policies are disabled by default, so we will need to enable them before we continue.
Navigate to: AAC > Authentication
Use the dropdown menu to enable all authentication policies.
Once enabled, deploy and publish the pending changes, then restart the runtime container:
$ docker stop isvaruntime && docker start isvaruntime
Next, we need to configure the FIDO2 PAIR authentication scenario.
Navigate to: AAC > Authentication
Switch to the Scenarios tab, then open the Configure FIDO2 PAIR scenario wizard.
Complete the configuration with the following details: (note the LDAP Bind password differs from our existing admin passwords)
- FIDO2 PAIR:
- Username Password:
- LDAP Hostname: 127.0.0.1
- LDAP Port: 6389
- LDAP Bind DN: cn=root,secAuthority=Default
- LDAP Bind Password: passw0rd
- SSL: no
Deploy and publish the pending changes, then restart the runtime container:
$ docker stop isvaruntime && docker start isvaruntime
Finally, we can configure the IFA authentication scenario.
For this scenario, we will offer the user the choice of username/password or Passkey authentication.
Navigate to: AAC > Authentication
Switch to the Scenarios tab, then open the Configure Identifier First Authentication scenario wizard.
Configure the IFA scenario with the following settings: (note the LDAP settings should already be populated)
- IFA:
- FIDO2: yes
- MMFA: no
- Redirect: no
- FIDO2PAIR: yes
- Allow discovery: yes
- FIDO2:
- Username Password:
- LDAP Hostname: 127.0.0.1
- LDAP Port: 6389
- Bind DN: cn=root,secAuthority=Default
- Bind Pass: passw0rd
- SSL: false
Save the configuration, deploy and publish pending changes, then restart the runtime container:
$ docker stop isvaruntime && docker start isvaruntime
Test the IFA policy
Now we have completed the configuration, we can test the IFA policy with our test user to confirm everything is working as expected.
Connect to the reverse proxy and trigger the IFA scenario: https://www.docker-isva.ibm.com/mga/sps/authsvc/policy/ifa
You should see the Welcome screen with a Username input.
We start by entering the username for our test user:
After clicking Continue, we are shown the Username Password screen, as we have not yet registered a Passkey.
Complete the login with the testuser details:
- Username: testuser
- Password: Passw0rd
After clicking the Sign In button and successfully authenticating, we are shown the Sign In Faster screen where we can now register our device.
Click the Yes button to start the device registration process.
Click the Let's Go button, which will prompt you to register your passkey device.
After completing the passkey registration, we are shown the Success page to indicate the registration was successful.
Now we can logout to unauthenticate before testing our Passkey login.
First, logout by navigating to the url: https://www.docker-isva.ibm.com/pkmslogout
Next, retrigger the IFA scenario: https://www.docker-isva.ibm.com/mga/sps/authsvc/policy/ifa
We are presented with the Welcome screen where we can again enter our test user's username.
This time, we are shown the Sign In Options screen where we are given the option of signing in using either our passkey device or password.
We can select the Security Key / Touch ID option and are prompted to authenticate with our passkey device.
After completing the sign in process, we are shown a screen confirming our login was successful.
This confirms our environment is configured correctly and the IFA scenario is working as expected.
Environment Cleanup
To clean up our environment, first stop and remove the running containers:
$ docker rm -fv isvawrp
$ docker rm -fv isvaruntime
$ docker rm -fv isvaconfig
$ docker rm -fv postgresql
Next, remove the Docker persistent volumes:
$ docker volume rm isvaconfig
$ docker volume rm pgdata
Finally, remove the Docker network:
$ docker network rm isva