Many thanks to Tufin for awarding AERAsec at the Annual Partner Summit as
Tufin 2022 Best SDP+ Partner of the Year for the EMEA region
After more than 15 years of successful cooperation with Tufin, the AERAsec team is proud to receive this award.
When working with Workflows in Tufin SecureChange, it's sometimes useful to skip a specific step. To configure this for a step in the Workflow, go to "Assignments" and select the option "Skip this step if:" Several conditions can be added and combined with AND or OR. A mixture is not possible (e.g. (a AND b) or c).
The example above has a Skip Condition with combined parameters. The step will be skipped if
This condition works perfectly for a single Access Request.
BUT
If there is more than one Access Request in a ticket, the Skip Condition is evaluated for each Access Request. The suggested behavior has been that if each Access Request fulfills the Skip Condition, the step is skipped - and vice versa: If any Access Request does not fulfill the condition, the skip will not be skipped. This is wrong (!)
Lesson Learned
Tufin Support has clarified the behavior: "For tickets containing multiple access requests, the step will be skipped if the condition is met in any one of them unless the condition selected specifically states that it applies to all access requests."
So if only one Access Request within the ticket fulfills the Skip Condition, the step will be skipped - regardless of all other Access Requests.
The condition applies to all Access Requests only for "Risk Status", "Target", "Destination", "Verification Status". So only for these four conditions the behavior is as expected above.
SecureTrack has two kinds of users: "Administrator" and "User".
An "Administrator" has access to every part of SecureTrack, also to SecureTrack Topology. The permissions of this user cannot be restricted.
In TOS Classic a "User" had the possibility to access SecureTrack Topology. The requirement was that this user has permission to view "all devices". In this case, Topolgy has been shown and could be used. For sure, when a new device has been added, the permission of the user needed to be updated (because otherwise the requirement for accessing the Topology was not fulfilled).
The access to the Topology for users has been classified by Tufin as a "security flaw". Therefore, in TOS Aurora there is no possibility for a "User" to access the Topology. If this access is needed, the permissions need to be extended to "Administrator" (with all consequences). If only some information is needed, a user is able to use the API for calling specific information from the Topology. Examples of this API access are shown here:
https://forum.tufin.com/support/kc/rest-api/R22-2P/securetrack/apidoc/#!/Network_Topology/getPathCalc
https://forum.tufin.com/support/kc/rest-api/R22-2P/securetrack/apidoc/#!/Network_Topology/getPathCalcImage
A very useful feature of Tufin SecureChange is the possibility to have an automatic target selection in Access Request workflows. Quite often, the first step of an Access Request ticket doesn't require the requester to fill in the necessary targets. Just Source and Destination as well as Service are needed for opening a ticket. In the next step, the corresponding targets are often calculated automatically for further use, e.g. by the Designer or Verifier. These tools rely on the results of the values configured in "Targets" - independently if they are filled in manually or by Automatic Target selection.
The automatic selection works perfectly for Access Requests with one Source and one Destination.
AR with one Source and one Destination - working path
For the first request below a target can be found because the path can be found in the SecureTrack Topology. This behavior is as expected.
AR with one Source and one Destination - not working path
The second request is not in SecureTrack Topology, therefore neither a path nor a target can be found. This behavior is also as expected.
AR with a "mixed condition" for Source and Destination
If now both cases are mixed within one Access Request, Tufin only finds the targets of the first example, not pointing out that for the second option, no Targets have been found. Only the found Targets are filled into the field - without any hint that not all connections have been found within SecureTrack Topology. 
Conclusion
Following Tufin Support, this behavior is "as designed" - "an "Access Request that has partial targets, i.e. some targets are found, but not all” is expected by the product design to only show what is possible and not indicate what paths failed"
There are (manual) workarounds possible, but currently, no out-of-the-box solution for Automatic Target Selection is available.
Esp. if there are complex Access Requests (as they occur in real life), this fact needs to be considered.
If you need further information, please contact us by E-Mail: tufin-support at aerasec dot de.
Update 2023-07-04
This issue is resolved in R23-1 GA. A new flag can be enabled via configuration. It generates a notification in the "target suggestion phase".
The flag is called "TOPOLOGY_SHALL_CALCULATE_UNROUTED_TRAFFIC" and it has three levels:
- 'enabled' - calculate and display unrouted elements in path API and path finder(Map)
- 'enabled_restrict' - calculate and display unrouted elements in path API, path finder(Map) and suggest target failure
- 'disabled' - don't calculate unrouted elements in any tool
Since TOS Aurora 22-1, there is an option to use a Single Sign On (SSO) for SecureTrack and SecureChange / SecureApp. In new installations, this feature is enabled by default, but in upgraded installations, this feature needs to be enabled manually. This is quite easy, following Tufin Knowledge Base. If SSO is turned on, there is no additional authentication required if a user changes from e.g. SecureTrack to SecureChange.
Enable SSO
To activate SSO access to the command line is necessary. Additionally, administrative permissions are needed (e.g. root or the use of sudo). This command enables SSO:
[Tufin]$ sudo tos config set -p tos.sso.enabled=true
After this action, SSO is active and the login screen shows "Tufin Orchestration Suite".
Sometimes it's useful, to disable SSO (see below).
Disable SSO
Disabling the optional SSO is done using this command with administrative permissions at the CLI (e.g. root or the use of sudo):
[Tufin]$ sudo tos config set -p tos.sso.enabled=false
After this command, a separate login screen is shown for SecureTrack and/or SecureChange - as it has been before for many years.
Items to consider when using SSO for SecureTrack and SecureChange
Sometimes it's necessary to provide a disclaimer on the login page. So legal aspects are considered.
When using "Single Sign On" (SSO) in TOS Aurora, only one page for access to SecureTrack, as well as SecureChange, is shown. This page refers to SecureTrack. If a separate disclaimer needs to be shown for SecureChange, SSO needs to be turned off. The same is required if a user is configured for SecureChange only.
SecureTrack (or SSO enabled)
There are two options to configure a disclaimer on this page. If the disclaimer consists of a single sentence and it doesn't need to be formatted, it can be added with this command:
[root@TufinOS ~]# kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r set_disclaimer --content "Access restricted"
This results in
If formatting is required, the disclaimer itself needs to be written into an HTML file. Please find an example below:
[root@TufinOS ~]# ll disclaimer.html
-rw-r----- 1 root root 110 Jan 12 18:03 disclaimer.html
[root@TufinOS ~]# cat disclaimer.html
<!DOCTYPE html>
<html><body>
<h1>Disclaimer</h1>
Please regard - <b>Access restricted</b>
</body></html>
[root@TufinOS ~]#
Regarding the documentation delivered by Tufin, the command listed ccurrently there leads to an error.
The correct procedure is shown below.
Find the correct name of the pod running keycloak
[root@TufinOS ~]# kubectl get pods | grep keycloak
keycloak-service-85559fc884-tlpqp 1/1 Running 0 29d
[root@TufinOS ~]#
Then copy the disclaimer file into the (correct) pod and make it active
[root@TufinOS ~]# cat disclaimer.html | kubectl exec -i keycloak-service-85559fc884-tlpqp -c keycloak-service -- sh -c "cat > /tmp/disclaimer.html"
[root@TufinOS ~]# kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r set_disclaimer -f /tmp/disclaimer.html
The result looks like this
If you want to delete any disclaimer in SecureTrack, use this command:
# kubectl exec -it deploy/keycloak-service -c keycloak-service -- manage_keycloak -r set_disclaimer --content ""
SecureChange
Customizing SecureChange is easier than it is for SecureTrack. The menu to customize SecureChange can be reached via Menu > Settings > Customization.
Having navigated to this page, the lower part called "Disclaimer" allows adding the text shown during the login. Basic formatting of the text is possible, too. When finished, press "Publish" - so the text will be shown during login. 
Please be aware, that this disclaimer will be shown only if Single Sign On (SSO) is turned off (!)
