btpsa-v1.2.0

[lechnerc77]

v1.2.0 (2022-12-07) 🎄

New Features and Enhancements 🚀

• [#319] and - [#342] - Support of custom IdPs in role assignment (incl. CF roles)
• [#329] - Support of labels for resources
• [#338] - Cf api endpoint hardening
• [#340] - Make accountMetadata available as env variables
• [#343] - Subaccount enable beta features
• [#330] and [#345] - Support of parameters when subscribing to applications
• [#347] - Enhance fetching of remote parameters and usecase files

Bug Fixes 🐞

• [#327] - remove deletion of apps that are only entitled
• [#346] and [#351] - Fix the wrong role collection assignment

Other Changes

• Regular update of btpsa-usecase.json and automated documentation due to updates in the service metadata
• Bump of dependency updates (see overview)
• Cleanup of code base [#353]

Community Contributions

@pirnz

---

This discussion was created from the release btpsa-v1.2.0.

[lechnerc77]

Detail on "Support of custom IdPs in role assignment (incl. CF roles)"

You can now add your custom IdP to be assigned to your users. There are two spots where you can make this setting:

1. In the parameters.json you can specify your default IdP via the filed "defaultIdp". This value will be taken for the role collections in the use case file for the role collections.
2. In the usecase.json you can specifiy an IdP per role collection via the field "idp". This will then be taken exclusively for this role collection.

If you do not specify an IdP the behavior is the same as in previous releases.

[lechnerc77]

Details on "Support of labels for resources"

You can now specify labels for the resources in BTP that support a labeling. Be aware that not all resources covered by the BTP CLI and the Cloud Foundry CLI support labels.

You can specify the labels via the corresponding attributes in the parameters.json and usecase..json e.g., "directorylabels" to label a directory.

Be aware that the labels targeting resources addressed by the BTP CLI and the CF CLI must adhere to the following formatting:

"subaccountname": "test-labels",
  "subaccountlabels": {
    "costcenter": ["org-123"],
    "appowner": ["somebody"]
  },

[lechnerc77]

Details on "Subaccount enable beta features"

You can now activate beta features for subaccounts via the parameter "subaccountenablebeta" in the parameters.json file.

[lechnerc77]

Details on "Enhance fetching of remote parameters and usecase files"

Until this release you could reference the parameters and use case file in the command line via links to e.g., repositories, specifying the corresponding URL. However, the URL had to be publicly visible and no authentication to private repositories was possible.

With this released we enhanced this functionality, and you can now access these files even if you need to authenticate. We currently support the option to use basic authentication and token-based authentication. A call of the btps-setup-automator command would look like this:

btpssa -parameterfile "https://raw.githubusercontent.com/<USER ID>/test-btpsa-remote-private/main/parameters.json" \ 
-externalConfigAuthMethod "token" \
-externalConfigToken "<YOUR TOKEN>"

The same authentication method is used for the parameters.json and the referenced usecase.json files.

The new parameters that are available are:

Parameter	Type	Valid values	Comment
externalConfigAuthMethod	string	token, basicAuthentication	-
externalConfigUserName	string	-	needed for basic authentication
externalConfigPassword	string	-	needed for basic authentication
externalConfigToken	string	-	needed for token-based authentication

If you do not specify any parameters, the behavior is the same as in previous releases.

[lechnerc77]

Details on "Fix the wrong role collection assignment"

The flow of the assignment of role collections especially for the subaccount admin was slightly changed to fix a bug and stay consistent with the option to specify a custom IdP:

1. When the subaccount is created, the authenticated user from the parameters.json files is registered as subaccount admin.
2. When the assignment of role collections is processed, the remaining users assigned as subaccount admins are added to the subaccount's user assignment

This is reflected in the log files, that might look different in the new version, the functionality remains unchanged.