FW change request changes via SecureChange - phase 2 tasks

[tpurschke]

@tpurschke

• [ ] customer decision: how to deal with duplicate network object names (fails at least when they are used within the same rule)
  • prevent duplicates (db constraint, ui check)
  • artificially add uniqueness to name
  • leave it to users to prevent duplicate names
• [ ] test performance: how long does the analysis phase take when we have 50 connections and 50 ARs?
• [ ] to clarify: bundling of access requests also for same connection on different managements? Ask Tufin support. Solution probably: create one access request per management using the objects of the respective management.

@abarz722

• [ ] create tickets on behalf of the user who clicks the button (using SC API calls to get the SC user id of the user) - best to make this an option configurable via external workflow settings
  1. get user id

     curl --request GET \
     --url 'https://sc-host/securechangeworkflow/api/securechange/users.json?user_name=xv884qb' \
     --header 'Authorization: Basic xxx' \
     --header 'Content-Type: application/json' 

     returns

     {
     "users": {
     "user": [
     {
     "@xsi.type": "user",
     "id": 55,
     "type": "user",
     "name": "XV884QB",

  2. add the following line to all SC tickets (user-id is the short id without any ldap path)

     {
         "ticket": {
             "subject": "test123",
             "priority": "Normal",
             "domain_name": "",
             "requester_id":  55,

• [x] also request common services (needs to be tested)
• [x] ticket status in modelling - lacks completion date (to be written in WF module)
• [ ] certain re-rendering/subscription improvements (ticket status, analysis pop-up)
• [ ] Test basic functionality via FWO API: modify AR (add new app server), initiate requesting this change via SC (probably not possible yet)
  • input: internal ticket create API call
  • output: SC API call which modifies AR
• [x] add firewall request sending to history log
• [x] enhance monitoring (e.g. status of external requests, tickets, ...); statistics on open tickets
• [ ] also handle access requests which contain host objects instead of groups
• [x] NAs should be requested in the same way as ARs (not necessary as NAs should always exist)
• [ ] if objects (e.g. NAs) do not exist any more - set connection status to "incomplete"
• [x] if more than 100 connections exist, we need to split the requesting into multiple SC tickets
• [ ] Plan app-server change handling: Name change vs. IP change - how can an app server move from manually added to being imported?
• [ ] try to break down tickets per changed connection to enable requesting additional changes for the same app
• [ ] display SC ticket status - display the actual ticket step
• [x] add single new app servers on all managements (currently only working for single mgmt)
• [ ] still got a timing issue (imports only once a day) when someone only modifies groups and makes two of these changes on the same day, current customer prod import time: 10 min; also relevant when we allow AR changes via API; remediation: increase import frequency (loop with 40s pause only?)
• [ ] also request ip ranges

@SolidProgramming

• [ ] #2597