Web access management (WAM)

Traditionally WAM was handled either via proprietary agent software installed on each target node or via a reverse proxy architecture. Nevis uses the latter approach.

Proxy access to Google.com

1. Authenticate to Nevis. You are presented with a welcome screen directing you to create or import a fresh project. However, we will first introduce you to the default inventory.
2. Select the “Infrastructure” tab. Observe that a default inventory called “NEVIS” was created as part of the installation.
3. Observe that:
4. The “schemaType” is set to “Kubernetes”.
5. The “consts” (constants) section specifies some values that can be re-used in multiple variables - this can make configuration more efficient whereby changing a single constant can then automatically update multiple variables.
6. The “services” section is remarked out (as in a Kubernetes deployment, there is no need to define the services).
7. The “vars” (variables) section provides some sample variables that apply to the entire inventory and can make project configuration more efficient.
8. The “deployment-repository” section contains the configuration to connect to the Git deployment repository. Generated service configurations are transferred to Kubernetes via this repository.
9. The “kubernetes-cluster” section contains the configuration to connect to the Kubernetes cluster for the deployment. As this nevisAdmin4 is also running within Kubernetes, it is only necessary to specify the namespace that the nevis components will be deployed into.
10. Highlight and copy the “deployment-repository url” to your buffer. It should be “ssh://[email protected]/azuregitea/deploy.git” (We will need this in a moment.).
11. As we haven’t changed any config at this point, there should be no need to select the “Save changes” button.
12. Return to the “Configuration” tab.
13. We will be building a project from scratch, so beneath the Welcome message, select “Create project”.
14. Enter your custom “Project key”. In our example, we named the project “Workshop”.
15. Tick the option “Enable GIT”
16. Paste your buffer contents (from step 4) into the “Git repository field”.

info

This URL is specifically for the deploy repository that Admin4 uses when deploying the configuration. However, as a best practice we should use different repositories for deployments, projects and inventories. The bundled gitea instance now comes with 3 repositories setup:

• deploy.git
• project.git
• inventory.git

12. As we want to use the “project.git”, adjust the Git repository URL so that it is now “ssh://[email protected]/azuregitea/project.git”.
13. Select the refresh icon within the input field. This will contact git and populate the Branch information (“master”).
14. Leave other fields unchanged.
15. Click “Create”.
16. Observe that your new project will be selected (converted to uppercase) and that there is a warning status, as it is currently blank.
17. Click the “+” symbol to add a pattern.
18. Use the search window to find the “nevisProxy Instance” pattern and add it.
19. Note the default name that is assigned. Click on the name and change it to remove the “New” part i.e. a sensible name to use is simply “nevisProxy Instance”.
20. Within the “Basic Settings” tab, for “Deployment Target”, enter the name “proxy” (With a classic deployment, that name would also have to be specified in the inventory, so that there is a match. But with a Kubernetes deployment, that is not required, so you could use any name you wish.).
21. Save changes. Note that the status will still be red at this point.
22. Click the “+” symbol to add a pattern.
23. This time, search for and select the “Virtual Host” pattern.
24. Change the name to “Virtual Host”.
25. Within the “Basic Settings” tab, for the nevisProxy value, select the previously-created “nevisProxy Instance”.
26. For the Frontend Addresses, we will use a variable that was automatically specified by the deployment within the default inventory. The variable name is “domain”. In this way, IF you had multiple stages (e.g. Prod and Test) which had their own specific inventories, then that variable would be assigned the relevant stage-specific value. You will need both the variable name and a sample value (for validation). Probably the easiest way to do this is to switch to the “Infrastructure>>NEVIS” view (save changes first, if prompted) and copy the contents of the “azure-domain” constant value into your buffer (e.g. https://xxx.yyy.cloudapp.azure.com”).
27. Back in “Configuration” >> “Patterns” view, click on the “var” icon next to the Frontend Addresses tag. Replace the suggested variable name with “domain”. Also, paste your buffer into the “Sample value” field.
28. Click “Set variable”.
29. Save changes.
30. Note that the status of the WORKSHOP project is now green.

At this point, we have specified an instance of the proxy and a logical virtual host assigned to it. The config has a front-end listener but we now need to tell nevisProxy where to proxy requests to. At this stage we will proxy to just one service - Google, for illustrative purposes. Of course, in most deployments a single virtual host / nevisProxy Instance combination will handle multiple target proxied sites (multi-homing).

30. Click the “+” symbol to add a pattern.
31. This time, search for and select the “Web Application” pattern.
32. Change the name to “Google Web App”.
33. Within the “Basic Settings” tab, for “Virtual Hosts”, select the “Virtual Host” pattern you created earlier.
34. For “Frontend Path(s)” enter “/” - which means all requests to our frontend will be forwarded via this particular pattern (unless patterns with more specific paths are added at a later point).
35. Select the “Backend Connection” tab.
36. For “Backend addresses”, enter “https://www.google.com”.

OWASP ModSecurity Core Rule Set (CRS)

nevisProxy implements web application firewall functionality (WAF) that includes enforcing the OWASP ModSecurity Core Rule Set (CRS) which is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls. These can lead to some false positives such that the settings may need to be adjusted. However, due to time constraints, we won’t be addressing ModSecurity in detail in this course and so we will simply disable such checks.

37. From the “Security” tab, set “Request Validation (ModSecurity)” to “off”.
38. Save changes.

Testing

1. After the changes have been saved, deploy your project.
2. Within the pop-up window, make sure the “WORKSHOP” project, “NEVIS” inventory and “Primary” Deploy as options are selected. Then click “Validate deployment”.
3. Assuming validation is successful, select “Preview deployment”.
4. Expand and view the preview items and observe some of the details.
5. When you’re ready, click “Deploy now”.
6. After perhaps 30 secs or so observe successful completion. You can click on “Close wizard”.
7. Back on your test browser tab, hit refresh - you should now observe the Google homepage (most likely with Google’s cookie statement).
8. If you have access, return to the Azure Portal and within your “Kubernetes service” object, under the “Kubernetes resources” section, select “Services and ingresses” and see that the "proxy" ingress have been added.
9. It is good practice to keep the config in GIT uptodate (so that you can recover from erroneous changes in future), from the Configuration tab, select the action to “Publish to Git”.
10. Observe the config changes and modify the “Publish comment” if you wish, to reflect the exercise completed.
11. Select the “Publish” button.
12. Select the “OK, Return” button in the pop-up to acknowledge the result and return to the “Patterns” view.
13. Select the “Revert” option and observe the dropdown list of previously stored revisions. This is a very useful capability to recover to a known good state. We will publish to git after completion of each subsequent lab exercise where the project is updated.
14. Select “Cancel” as we don’t need to revert any configuration at this point.

note

This publishing to Git only relates to the configuration and its patterns. It does not include the inventory we are using from the infrastructure tab. We will now also connect your inventory to the GIT repository called “inventory” that is present by default with an Azure deployment. Although there is no “Revert” to a specific previous configuration with inventories, there IS the option to “Clear local changes” which will restore the configuration to the last published configuration which is useful in case an accidental misconfiguration is made.

15. Select the “Settings” option on the “Infrastructure” tab.
16. On the right-hand side, select the “Connect to Git”. Browser autofill will probably suggest your previous value. Modify it to reflect the “inventory.git” repository i.e. “ssh://[email protected]/azuregitea/inventory.git”.
17. Select the refresh icon within the input field. This will contact git and populate the Branch information (“master”).
18. Leave the Directory field unchanged.
19. Click “Connect”.
20. Select “Publish to Git”.
21. Observe the config changes and modify the “Publish comment” if you wish, to reflect the exercise completed.
22. Select the “Publish” button.
23. Select the “OK, Return” button in the pop-up to acknowledge the result.

Adding Local Authentication

In this exercise we will build out a series of patterns that together will permit user authentication based upon initial default credentials held within the nevisIDM component.

1. From the “Patterns” view, add a new pattern of type “nevisAuth Database” and change the name to “nevisAuth Database”.
2. Within the “Basic Settings” tab, for “Database Type”, select “PostgreSQL”.
3. For “Database Host”, click the “var” icon. Replace the suggested variable name with “auth-db-host” and click “Set variable”.
4. Click the “Save changes” button.
5. Select the Infrastructure tab and ensure the “NEVIS” inventory is selected. Within the main window, locate and copy the PostgreSQL endpoint via the “database-host” constant. It will look something like “postgrese861ce37.postgres.database.azure.com”. Copy it into your buffer.
6. From Configuration >> Variables view, locate the new variable and paste in the contents of your buffer as the “Sample value”.
7. Save changes.

Database Host

For “Database Host”, we will use a variable to reference the specific PostgreSQL instance used in your cluster. Recall that in the real world, this will allow you to have a unique value per stage/environment which uses a common variable name in the configuration. In this case, your default NEVIS inventory already has a variable defined as a result of the OneClick installation. It is called “auth-db-host”. However, the variable name has not yet been added to this new Project and so must be referenced AND also, for validation purposes, the variable must be assigned a sample name (we will use the real name for your instance for clarity).

3. Back in the “nevisAuth Database” pattern, within the “Basic Settings” tab, for “Root Credential”, click the “var” icon.
4. For “Variable name”, replace the suggested name with “k8s-root-credential” (which was specified in the default inventory) and click “Set variable”.
5. Save changes.
6. From the “Patterns” view, add a new pattern of type “nevisAuth Instance” and change the name to “nevisAuth Instance”.
7. Within the “Basic Settings” tab, for “Deployment Target”, enter “auth” (With a classic deployment, that name would also have to be specified in the inventory so that there is a match. But with a Kubernetes deployment, that is not required, so you could use any name you wish.).
8. For “Database”, select the “nevisAuth Database” pattern you created above.
9. Click the “Save changes” button.
10. From the “Patterns” view, add a new pattern of type “NEVIS SecToken” and change the name to “NEVIS SecToken”.
11. Select the “Content” tab and observe the default attributes that will be added to any created SecT okens - this is what will be passed to the nevisIDM Administration GUI (which we will be creating in a moment) for authentication purposes.
12. Save changes.
13. From the Patterns view, add a new pattern of type “nevisIDM Database” and change the name to “nevisIDM Database”.
14. Within the “Basic Settings” tab, for “Database Type”, select “PostgreSQL”.
15. For “Database Host”, click the “var” icon. Replace the suggested variable name with “idm-db-host” and click “Set variable”.
16. Save changes.

Database Host

For “Database Host”, as with the nevisAuth database, we will use a variable that is already defined in your default NEVIS inventory (“idm-db-host” ) to reference the specific PostgreSQL instance used in your cluster. As all the databases used in this training are provided from a single PostgreSQL service, we could use the same variable name as for the nevisAuth database, but we will follow the default inventory convention and specify unique variable names. As before, the variable name has not yet been added to this new Project and so must be referenced AND also, for validation purposes, the variable must be assigned a sample name (we will use the real name for your instance for clarity).

7. Select the Infrastructure tab and ensure the “NEVIS” inventory is selected. Within the main window, locate and copy the PostgreSQL endpoint via the “database-host” constant. It will look something like “postgrese861ce37.postgres.database.azure.com”. Copy it into your buffer.

8. From Configuration >> Variables view, locate the new variable and paste in the contents of your buffer as the “Sample value”.

9. Click the “Save changes” button.

10. Back in the “nevisIDM Database” pattern, within the “Basic Settings” tab, for “Root Credential”, click the “var” icon.

11. For “Variable name”, select the existing “k8s-root-credential” (which was specified in the default inventory) and click “Set variable”.

12. Click “Save changes”.

13. From the Patterns view, add a new “nevisIDM Instance” pattern.

14. Within the “Basic Settings” tab, for “Deployment Target”, enter “idm”. (With a classic deployment, that name would also have to be specified in the inventory so that there is a match. But with a Kubernetes deployment, that is not required, so you could use any name you wish.)

15. Scroll down and for “Database”, select the “nevisIDM Database” pattern you created above.

16. For “Encryption Key”, click the “var” icon. We can accept the default variable name (“nevisidm-instance-encryption-key”). Click “Set variable”.

17. Save changes.

    Encryption Key

    For “Encryption Key” we basically need a random string of characters in Base64 format that is either 8,16, or 24 bytes in length. If you have OpenSSL handly, the recommended way to generate the string is to use “openssl rand -base64 16”. If not, for this workshop we can simply use an example key in the correct format (NOT FOR PRODUCTION USE) - HCI0iyMAEgQli+Z0gQdAyA==. If you wish to copy and paste this string then you will find an electronic version of this document in pdf format from the “SupportingMaterials.zip” file you downloaded in Exercise A. Additionally, the pattern wants to encourage best practice and so also suggests using a variable. Furthermore, the key itself will be inserted into the config as a secret and so not be directly readable within the configuration.

18. Select the “variables” tab and note that the variable name has been added.

19. Select the "Infrastructure" tab and ensure the “NEVIS” inventory is selected. Within the main window, add a new line in the “vars” section (spacing is critical, so ensure that the variable is preceded by 2 spaces - NOT a tab). Paste in the variable name followed by a colon and space. e.g. “nevisidm-instance-encryption-key:”.

20. Click the padlock symbol at the bottom which has the tooltip label of “Insert secret” and within the pop-up enter your Base64 random string (at least 18 bytes long - use “HCI0iyMAEgQli+Z0gQdAyA==” if you don’t have your own) and click “Insert secret”. It should look something like:

21. Click “Insert secret”.

22. Save changes.

23. Return to the “Configuration” >> “Patterns” view.

24. From the “Patterns” view, add a new “nevisIDM Password Login” pattern.

25. Within the “Basic Settings” tab, for “nevisIDM”, select the “nevisIDM Instance” pattern you created above.

26. Save changes.

27. From the Patterns view, add a new “nevisLogrend Instance” pattern.

28. Within the “Basic Settings” tab, for “Deployment T arget”, enter “login”. (With a classic deployment, that name would also have to be specified in the inventory so that there is a match. But with a Kubernetes deployment, that is not required, so you could use any name you wish.)

29. Save changes.

30. From the “Patterns” view, add a new “Authentication Realm” pattern and call it “Password Realm”.

31. Within the “Basic Settings” tab, for “Initial Authentication Flow”, select the “nevisIDM Password Login” pattern you created above.

32. For “Application Access Tokens”, select the “NEVIS SecToken” pattern you created above.

33. On the “nevisAuth Connection” tab, for “nevisAuth”, select the “nevisAuth Instance” pattern you created above.

34. On the “GUI Rendering” tab (you may have to scroll across), for “Login renderer” select the “nevisLogrend Instance” pattern you created above.

35. Save changes.

The final configuration step is to actually apply the new authentication configuration to the Google Web Application:

14. Select the “Google Web App” pattern.
15. For “Authentication Realm”, select the “Password Realm” that you created above.
16. Save changes.
17. Deploy your project.
18. Within the pop-up window, make sure the “WORKSHOP” project, “NEVIS” inventory and “Primary” Deploy as options are selected. Then click “Validate deployment”.
19. Assuming validation is successful, select “Preview deployment”.
20. Expand and view the preview items and observe some of the details.
21. When you’re ready, click “Deploy now”.
22. After a couple of minutes, observe successful completion. You can click on “Close wizard”.

Testing

Enable access to the nevisIDM Administration GUI

1. From the “Patterns” view, add a new “nevisIDM Administration GUI” pattern
2. Within the “Basic Settings” tab, for “Virtual Hosts”, select the “Virtual Host” pattern you created in Exercise B.
3. For “nevisIDM”, select the “nevisIDM Instance” pattern you created in "Adding a Local Authentication".
4. For “Authentication Realm”, select the “Password Realm” pattern you created in "Adding a Local Authentication".
5. For “Application Access Token, select the “Nevis SecToken” pattern you created in "Adding a Local Authentication".
6. Click “Save changes”.
7. Deploy your “WORKSHOP” project to the “NEVIS” inventory as “Primary”.
8. If you want to see a summary of the endpoints that are actually protected, select the “Overview” option on the left-hand side.
9. Select the “Applications” tab and observe the paths
10. Select the “Reports” tab from the left-hand navigation.
11. Select the “Application Mapping Report”.
12. Ensure that the “NEVIS” inventory is selected from the dropdown and then press “Generate”. This shows a little more information than the project overview - in particular the backend address/path information.

Create test user

1. From the tab used in step 14, return to “/nevisidm/admin” and click “Create user” from the left-hand navigation.
2. Provide the following information:
3. Login ID - testuser
4. Last name - User
5. First name - Test
6. Email - [email protected]
7. Phone number - 0123456789
8. Mobile phone - +44123456789
9. Leave all other values at default (either blank or pre-set)
10. Click “Save”.
11. Under “User credentials”, click “New”.
12. Click on the “Type” dropdown and observe the different supported mechanisms. We will be using the default “Password” type in this exercise.
13. Attempt to save a password of “password” in both the “New value” and “Confirmation” fields.
14. Observe that you are not permitted, as it does not comply with the default policy. This gives you an idea of the control you have over the password policy.
15. Provide your desired (compliant) initial password in both the “New value” and “Confirmation” fields.
16. Click on the dropdown next to the “Boot Strap” user account in the top right corner.
17. Click the “logout” link and observe that you are taken to a page with “?logout” appended. In other words, selecting the nevisIDM logout option will also terminate the nevisProxy session.
18. Click “Continue”.
19. Try to login with your new “testuser” account using the password you set in step 8.
20. Observe that again, due to the default password policy, you will be prompted to change the password on first access (after an admin-driven change of password).
21. After changing your password, observe that you are taken to the nevisIDM selfadmin page (as the testuser has no rights to the actual “admin” page.

You can set up a different nevisIDM password policy which does not require the password to be changed on 1st access if you wish.

Completing a real-world deployment

This final WAM exercise is to introduce additional patterns which would typically also be deployed in the real world. This diagram illustrates the four new patterns to add:

As the 4 suggested patterns are all leaf patterns, rather than creating them in isolation first, select the existing relevant patterns (see diagram above) and start configuration from those patterns.

![Here the training uses this section as a challenge lab, and so no detailed instruction is provided. That is fine for training purposes, but for DOCS, this section must be as detailed as the rest.]

1. For the three log patterns, setup is straightforward, the UI highlights the mandatory fields in red that need to be set.
2. For the database-related pattern, you need to specify the database host. Although the same database service is used here, that may not always be the case.
3. For the nevisProxy Remote/Hybrid Session Store create a new variable called “proxy-db-host” (which will match the inventory).
4. You can set a meaningful “Sample value” for validation purposes, but as the variable will be populated with the value specified in the inventory you can simply use a value of “x” which will satisfy the UI validation requirement.
5. Make sure to set the “Database Type” to “PostgreSQL”.
6. You also need to specify the Root Credential - you can use the same variable that you originally defined in "Adding Local Authentication".
7. Publish to Git.