[Spec bug] Microsoft.Security JitNetworkAccessPolicyInitiatePort: endTimeUtc marked required but service also accepts 'duration'

[GalGoldi72]

Summary

The JitNetworkAccessPolicyInitiatePort schema in specification/security/resource-manager/Microsoft.Security/Security/stable/2020-01-01/security-SecuritySolutions.json (and its TypeSpec counterpart at Security/SecuritySolutions/models.tsp:518) has a two-way mismatch with actual service behavior that has been present since the API's introduction in 2019.

Current spec contract

model JitNetworkAccessPolicyInitiatePort {
  @minValue(0) @maxValue(65535) number: int32;
  allowedSourceAddressPrefix?: string;
  endTimeUtc: utcDateTime;   // marked required
  // duration: NOT defined
}

Actual service behavior (empirical)

Tested against POST /subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Security/locations/{loc}/jitNetworkAccessPolicies/{name}/initiate?api-version=2020-01-01 using a non-existent policy so body validation fires before policy lookup:

Test body	Result
only duration (no endTimeUtc)	body validation PASSED (got 404 PolicyNotFound)
only endTimeUtc (no duration)	body validation PASSED (got 404 PolicyNotFound)
neither	400 InvalidInitiateInput: "Only one of fields 'EndTimeUtc' and 'Duration' can be set."

So the actual contract is:

• endTimeUtc is optional
• duration is also a valid field (and is what the existing example uses)
• Exactly one of the two must be provided (mutually exclusive)

Evidence the example has been right all along

InitiateJitNetworkAccessPolicy_example.json request body uses "duration": "PT1H" with no endTimeUtc. The service accepts this, but the schema rejects it.

Where this was first surfaced

Azure/azure-sdk-for-js#38484 — the JS TypeSpec emitter generates compilable TypeScript samples from spec examples; the existing example failed compilation because duration isn't a known field on the generated type and endTimeUtc is required but absent. Older codegens (Python/Java/Go) didn't catch this and have shipped releases with the incorrect contract for years.

Proposed fix (NOT to be done by the JS migration team)

A small, backward-compatible spec PR by the current JIT Network Access feature owner:

1. Mark endTimeUtc as optional (?)
2. Add a new optional duration: duration field
3. Document the mutual-exclusivity constraint (e.g., via doc comment or unionized type)

Note this is purely additive:

• required → optional is non-breaking
• Adding an optional field is non-breaking
• No existing caller breaks

Why this isn't being fixed by the JS migration team

The TypeSpec migration (#41888) is a faithful 1:1 port from swagger and explicitly does not change wire contracts. The migration team (MDfC) does not own the JIT Network Access feature; the original spec authors (@dandanwang0320, @avamitay) have moved on from this area, and a current feature owner could not be identified.

Filing this issue to ensure the discrepancy is tracked and can be addressed by the JIT owner when they are identified, rather than being silently fixed by an adjacent team without proper sign-off.

Context

• API: Microsoft.Security/jitNetworkAccessPolicies/{name}/{initiateType}
• Affected API versions: stable/2020-01-01 (and all later versions that don't redefine this model)
• Affected SDKs (all currently published): Python azure-mgmt-security, Java azure-resourcemanager-security, Go armsecurity, .NET Azure.ResourceManager.SecurityCenter — all expose endTimeUtc as required and lack duration
• First introduced: PR #5889 (2019-05-08) by @dandanwang0320
• Last meaningfully touched: 2020-03-22 (PR #8799) by @avamitay

cc: @amih90 @akrabi (active Microsoft.Security spec contributors who may know the current JIT owner)