EAM API: Add missing AppProvider

[gainsley]

What type of PR is this?

• correction

What this PR does / why we need it:

Adds the missing AppProvider to the AppManifest model.

Which issue(s) this PR fixes:

Fixes #251

Special notes for reviewers:

Changelog input

Add AppProvider field to AppManifest

Additional documentation

[github-actions]

🦙 MegaLinter status: ✅ SUCCESS

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ ACTION	actionlint	2		0	0.03s
✅ JSON	eslint-plugin-jsonc	1	0	0	1.33s
✅ JSON	jsonlint	1		0	0.18s
✅ JSON	prettier	1	1	0	1.28s
✅ JSON	v8r	1		0	2.54s
✅ OPENAPI	spectral	3		0	6.46s
✅ REPOSITORY	git_diff	yes		no	0.55s
✅ REPOSITORY	secretlint	yes		no	5.11s
✅ YAML	yamllint	3		0	0.7s

See detailed report in MegaLinter reports

MegaLinter is graciously provided by

[javierlozallu]

@gainsley, for this API an ID parameter to identify an App Provider may not be useful as the API implements 3-Legs Token so the App Provider will be known by this method.

[gainsley]

Hi @javierlozallu, I'm not super-clear on what information will be in the authentication token, but typically a user can have permissions for multiple app providers (or all app providers, in the case of an admin). I would expect the auth token may provide for which data the user is allowed to access, but not which specific data (or AppProvider in this case) is being used in the context of the current API call. So I think the AppProvider field is still needed in the API call. Also tokens are typically valid for some time and can be used for multiple API calls before they expire, and the user may want to use different AppProviders for different API calls if they have permissions to do so, all while using the same auth token.

[ThomasEdgeXR]

@javierlozallu i think we still need to solve this - as Jon said the authentication does not solve for knowing the AppProvider: as defined in https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/Edge%20terminology/edge_terminology.md the AppProvider is the entity owning the application backend (i.e. the "developer organization" or "ISV" if you will). So it's not an individual account but a logical entity to which multiple users can belong. It is necessary to add this to the model so it is clear to which AppProvider this belongs. A workload belongs to one AppProvider, but one AppProvider may be linked with multiple user accounts.