DisallowUserInstantiation property on Application to prevent manual instantiation of instances

[martinothamar]

Description

We need configuration to block "manual instantiation" by users, for applications where service owner
create and prefill instances and then let users fill in the rest.

Changes

• InstantiationConfig.ManualInstantiationDisabled to disable manual instantiation (not by service owner)
• Docs improvements on PartyTypesAllowed
• EditorConfig fixes as it seems all files have LF line endings and not CRLF (my editor was trying to correct line endings all the time)

Lib PR: Altinn/app-lib-dotnet#671

Related Issue(s)

• Prevent service from being manually instantiated app-lib-dotnet#361

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)

[martinothamar]

This PR (currently) is just for exploring options, so no need to review specifics of the code just yet. Location, semantics, overlap with existing config etc is the stuff where I don't have enough context to know what's a good idea or not, updating the description

[HauklandJ]

This PR (currently) is just for exploring options, so no need to review specifics of the code just yet. Location, semantics, overlap with existing config etc is the stuff where I don't have enough context to know what's a good idea or not, updating the description

As instantiation is not a party type, but rather the context in which a party type exists, it may be confusing to expand PartyTypesAllowed. Maybe it could be renamed to something that makes sense, but I fail to find an umbrella term thats easy to interpret as encompassing parties, instantiation and copy instantiation (the latter of which I do not fully understand what is represented with).

With this in mind, I vote to keep it as seperate config.

[martinothamar]

Updated the PR commit and description with what we agreed yesterday

[martinothamar]

@altinnadmin it would be nice if you could review this as well from a domain/naming POV 😄

[HauklandJ]

lgtm

[altinnadmin]

• "Manual instantiation" is not a concept, and I don´t think its wise to introduce it
• Instantiation is an action in XACML and API in the app, and the app owner currently configures who is allowed to trigger an instantiation. If only the app owner should be allowed to instantiate, it should be configured as an authorization rule.
• If a user should be allowed to instantiate only when creating a copy, I guess the "clean" way to do that is to introduce a new copy-action to be used in XACML, since these are different concepts that needs different authorization rules?

[martinothamar]

This was our reasoning as well initally - we discussed this with @TheTechArch and ended up deciding against extending the XACML setup in this case. Should I setup a meeting to revisit? That seems like a good idea since others have raised the same question as well

[martinothamar]

We discussesd this again - XACML based config for this is decided against for practical reasons - changes needed to accomodate this would affect different services such as - authorization, storage, backend/lib. There may also be more dimensions/config to this in future versions

Updated proposal for applicationmetadata:

        /// <summary>
        /// Gets or sets the list of allowed instantiators for this app, and limits it to orgs/service owners.
        /// The "urn:altinn:org" claim of the current identity must match one of the values in this list.
        /// If the list is null, any org/service owner or user can instantiate.
        /// </summary>
        [JsonProperty(PropertyName = "instantiationAllowedBy")]
        public List<string> InstantiationAllowedBy { get; set; }

[martinothamar]

Since XACML already does auth on which orgs can instantiate, I've made the configuration parameter a simple bool again

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud