Transporting role collections between BTP subaccounts Part2 : Standard approach

I’ve been exploring ways to transport role collections between BTP subaccounts. In my previous blog, I introduced a custom tool for achieving the same. In this blog, I’m going to use standard services such as  SAP Continuous Integration and Delivery (CI/CD) and SAP Cloud Transport Management (TM).
What makes this possible is that xs-security.json can carry role collections as described in the following blog post by Martin Blust.

Creating Role Collections in SAP BTP Using the New ‘role-collections’ Property

A few things to note about defining role collections in xs-security.json

  • Role collections created from xs-security.json cannot be maintained manually in the BTP cockpit
  • Role collections created manually cannot be updated with xs-security.json

There are two MTA applications that have separate xs-security.json definitions. I’m going to define a role collection consisting of roles from those xs-security.json, and transport the role collection to another subaccount called QA.


1. Create a MTA project for carrying role collections

For testing, I have created a project with the following structure. In the “parent” MTA, I’ve defined a role collection consisting of roles from “child1” and “child2” MTAs.


Project structure


{ "xsappname": "xsuaachild1", "tenant-mode": "dedicated", "scopes": [ { "name": "$XSAPPNAME.Admin", "description": "Admin" } ], "attributes": [], "role-templates": [ { "name": "Admin", "description": "Admin", "scope-references": [ "$XSAPPNAME.Admin" ], "attribute-references": [] } ]


{ "xsappname": "xsuaachild2", "tenant-mode": "dedicated", "scopes": [ { "name": "$XSAPPNAME.Admin", "description": "Admin" } ], "attributes": [], "role-templates": [ { "name": "Admin", "description": "Admin", "scope-references": [ "$XSAPPNAME.Admin" ], "attribute-references": [] } ]


{ "xsappname": "xsuaaparent", "tenant-mode": "dedicated", "role-collections": [ { "name": "Master_Admin", "description": "Master Admin user", "role-template-references": [ "$XSAPPNAME(application,xsuaachild1).Admin", "$XSAPPNAME(application,xsuaachild2).Admin" ] } ]

To reference a foreign role template, below syntax is used.


Note: xsappname must not contain underscores. Otherwise, deployment will fail.

parant/mta.yaml contains xsuaa resource only.

_schema-version: "3.2"
ID: parent
version: 0.0.1 resources: - name: xsuaaparent type: org.cloudfoundry.managed-service parameters: path: ./xs-security.json service: xsuaa service-plan: application 

After the setting is complete, push the parent MTA to GitHub.

2. Configure TM

I have created two nodes: DEV and QA. For instruction on how to configure TM, refer to this document.



3. Configure CI/CD

Here I used “SAP Cloud Application Programming Model” pipeline.


Job setting

In the stages, “Build” and “Upload to Cloud Transport Management” are enabled.




Upload to Cloud Transport Management

4. Start CI/CD Job

Start the pipeline and the MTA will be imported to DEV subaccount by TM.

Note: Before starting the job, make sure that the child MTAs have been deployed to the DEV subaccount.


Build result

4. Import to DEV with TM

Go to DEV node in TM and import the transport request created by CI/CD.


Import to Dev node

The role collection will be created in the DEV subaccount.


Master_Admin in DEV subaccount

5. Transport to QA

Move to QA node in TM and import the transport request.

Note: Before importing the MTA to QA node, make sure that the child MTAs have been deployed to the QA subaccount.


Import to QA node

The role collection will be created in the QA subaccount.

In the example above, I had to take care of the order of transport, because the parent MTA had dependency on child MTAs. Let’s consider other options of defining roles and role collections to see if there’s a better way.

Option 1: Define role collections in the same xsuaa instance as the roles that compose them

Option 2: Define role collections in a separate xsuaa instance from the roles (described in the previous section)

Option 3: Define roles and role collections in a single xsuaa instance and share that instance among multiple applications


Here are use cases, pros and cons of each option.

Option Use case Pros Cons
1 Bundling roles from different xsuaas to a single role is not required No dependency between xsuaa instances The number of role collections may increase, making role collection assignment to users more complex
2 You want to bundle multiple roles from different xsuaas into one role collection Role collection assignment is simpler You have to take care of the dependencies and align the transport order accordingly
3 Multiple apps share the same authorization requirements and sharing a single xsuaa makes sense No dependency between xsuaa instances You have to take care of the  dependency between the xsuaa instance and the apps using it

There seems no one-size-fits-all solution, so I’d like to hear your opinions. How do you define role collections and what is the reason for choosing that option? Please leave a comment in the section below 😀 .

In this series of blog posts, I have been seeking for ways to transport role collections.

In part1, I have introduced a custom tool for transporting role collections. Such tool may be useful when there are many role collections created manually.

In part2, I have demonstrated how to transport role collections using standard services such as CI/CD and TM.

As these two methods are not compatible each other (you cannot modify role collections created by xs-security.json and vice-versa), you have to decide on which way to go at the beginning of a development project on BTP. My personal view is the second way is preferrable because you don’t have to repeat creating role collections in each subaccount or resort to a custom transport tool.