◇ OpenCyber Academy
Engineering · Chapter 14 · English

Chapter 14 — Software engineering

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 14 — Software engineering

Lesson map

Lesson 14 published. Map, example, EX040.

flowchart TD
  N0["Learning outcomes"]
  N1["14.1 Configuration as code"]
  N2["14.2 Review"]
  N3["14.3 Testing"]
  N4["14.4 Staged deployment"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX040"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["14.1 Configuration as code"]
  N2["14.2 Review"]
  N3["14.3 Testing"]
  N4["14.4 Staged deployment"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX040"]

[Learning outcomes]
    |
    v
[14.1 Configuration as code]
    |
    v
[14.2 Review]
    |
    v
[14.3 Testing]
    |
    v
[14.4 Staged deployment]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX040]

Learning outcomes

You will (1) manage identity configuration as code; (2) review and test integration changes; (3) deploy safely in stages.

14.1 Configuration as code

Identity provider settings, application integrations, group rules and access policies can be kept as text files in version control rather than edited by hand in an administration console. Every change then records who made it, when and why, and earlier versions can be restored. Sana uses templates for application integrations, so each new application follows the same secure defaults, such as the code flow with PKCE and short token lifetimes. Consistency across 140 applications is only realistic when configuration is generated, not typed.

14.2 Review

Every proposed identity change is reviewed by a second engineer before it is applied. The reviewer checks that the change does what its description says, that it does not grant broader access than intended, that redirect addresses are exact rather than wildcards and that a rollback exists. Review comments stay with the change record, documenting reasoning for later engineers. Sana finds that the most common review finding is an over-broad group assignment, which would have given whole departments access meant for a single team.

14.3 Testing

Identity changes can be tested before deployment. Syntax checks confirm the configuration is valid. Policy tests confirm that representative synthetic users get the access expected and are refused access they should not have, using a table of expected outcomes. Integration tests in a test tenant confirm that sign-in works end to end. Sana runs these automatically on every proposed change, so a mistake that would lock out a department is found in minutes in the test environment rather than by staff on a Monday morning.

14.4 Staged deployment

Approved changes are deployed in stages: first to a test tenant, then to a pilot group of volunteers, then to everyone. At each stage Sana checks sign-in success rates and service desk calls before continuing. Each stage has a defined rollback, and the deployment record notes the exact configuration version. Automating deployment from version control removes manual retyping in consoles, which is a common source of errors, and guarantees that what runs in production is exactly what was reviewed and tested.

Worked example

A proposed change assigning the whole finance department to a payroll application is caught in review; the corrected change targets the payroll team group and passes policy tests.

Synthetic case. Changes, groups and tests are synthetic.

Errors and limits

Wildcard redirect addresses in application integrations can let tokens be sent to unintended destinations.

Exercises

Synthesis

Version-controlled, reviewed, tested and staged identity changes are safer than console edits.

Continue studying — chapter 14 of 50

← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →