[2.7] Redesign Job-level Authorization Example

[holgerroth]

Fixes # .

Description

Redesign job-level-authorization example to utilize Recipe and ProdEnv.

Types of changes

• Non-breaking change (fix or new feature that would not break existing functionality).
• Breaking change (fix or new feature that would cause existing functionality to change).
• New tests added to cover the changes.
• Quick tests passed locally by running ./runtest.sh.
• In-line docstrings updated.
• Documentation updated.

[holgerroth]

/build

[greptile-apps]

Greptile Overview

Greptile Summary

This PR successfully redesigns the job-level-authorization example to use the modern Recipe API with ProdEnv instead of the older admin console approach. The changes modernize the example for NVFlare 2.7.

Key changes:

• Replaced manual job submission via admin console with programmatic submission using NumpyFedAvgRecipe and ProdEnv
• Added new Python scripts (job1.py, job2.py, client.py) that demonstrate the Recipe API
• Removed old job metadata files (jobs/job1/meta.json, jobs/job2/meta.json) as they're now generated by the Recipe API
• Updated the blocked job name from "FL Demo Job1" to "FL-Demo-Job2" for consistency
• Improved error messages in CustomSecurityHandler to be more descriptive
• Added process_launcher component to resources.json (required for client process execution)
• Updated comprehensive README.md with new workflow instructions
• Simplified setup.sh by removing job folder copying (jobs now submitted programmatically)
• Updated nvflare dependency from ~=2.5.0rc to ~=2.7.2rc

The example still demonstrates the same authorization concept where site_a's CustomSecurityHandler blocks specific job names while site_b accepts all jobs, but now uses the modern NVFlare 2.7 API patterns.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The PR is a well-structured example refactoring that modernizes the job-level-authorization demo to use NVFlare 2.7 APIs. All changes are contained within example code, properly documented, and follow consistent patterns. The security handler logic remains sound, and the new Recipe API approach is cleaner than the previous manual submission method.
• No files require special attention

Important Files Changed

Filename	Overview
examples/advanced/job-level-authorization/README.md	Updated documentation to reflect Recipe API and ProdEnv usage instead of admin console
examples/advanced/job-level-authorization/client.py	New client-side training script using nvflare.client API with mock train/evaluate functions
examples/advanced/job-level-authorization/job1.py	New script to submit allowed job using ProdEnv and NumpyFedAvgRecipe
examples/advanced/job-level-authorization/job2.py	New script to submit blocked job using ProdEnv and NumpyFedAvgRecipe
examples/advanced/job-level-authorization/security/site_a/custom/security_handler.py	Updated blocked job name from "FL Demo Job1" to "FL-Demo-Job2" with improved error message

Sequence Diagram

sequenceDiagram
    participant User
    participant JobScript as job1.py/job2.py
    participant ProdEnv
    participant Server as NVFlare Server
    participant SiteA as site_a
    participant SiteB as site_b
    participant SecHandler as CustomSecurityHandler

    User->>JobScript: Execute python job1.py or job2.py
    JobScript->>JobScript: Create NumpyFedAvgRecipe with job name
    JobScript->>ProdEnv: Initialize ProdEnv with startup kit
    JobScript->>ProdEnv: recipe.execute(env)
    ProdEnv->>Server: Submit job via Flare API
    Server->>SiteA: Deploy job and check_resources command
    SiteA->>SecHandler: AUTHORIZE_COMMAND_CHECK event
    SecHandler->>SecHandler: Check job name == "FL-Demo-Job2"
    alt Job name is "FL-Demo-Job2"
        SecHandler->>SiteA: Return False with error message
        SiteA->>Server: Authorization failed
        Server->>ProdEnv: Job rejected by site_a
    else Job name is NOT "FL-Demo-Job2"
        SecHandler->>SiteA: Return True
        SiteA->>Server: Authorization success
        SiteA->>SiteA: Execute training (client.py)
    end
    Server->>SiteB: Deploy job and check_resources command
    SiteB->>SiteB: No security handler, allow all jobs
    SiteB->>SiteB: Execute training (client.py)
    SiteB->>Server: Training results
    Server->>ProdEnv: Job status and results
    ProdEnv->>JobScript: Return run object
    JobScript->>User: Display job status and results

Loading

[greptile-apps]

_{5 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[holgerroth]

/build

[greptile-apps]

_{5 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[holgerroth]

/build

[greptile-apps]

_{5 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[holgerroth]

/build

[greptile-apps]

_{5 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[chesterxgchen]

not sure why do we need a process launcher component at site system level

[holgerroth]

/build

[greptile-apps]

_{5 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[chesterxgchen]

LGTM