I’ve been exploring ways to transport role collections between BTP subaccounts. In my previous blog post, 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

Scenario

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.

Scenario

Steps

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

child1/xs-security.json

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

child2/xs-security.json

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

parent/xs-security.json

{
    "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.

Landscape

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.

Build

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.

Some thoughts about dependency

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

Options

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

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 😀 .

Conclusion

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.