Skip to Content
Technical Articles
Author's profile photo Mio Yasutake

Transporting role collections between BTP subaccounts Part2 : Standard approach

Introduction

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%20Structure

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.

$XSAPPNAME(<service-plan>,<xsappname>).<role-template-name>

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

Landscape

 

3. Configure CI/CD

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

Job%20setting

Job setting

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

Build

Build

Upload%20to%20Cloud%20Transport%20Management

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%20result

Build result

4. Import to DEV with TM

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

Dev%20node

Import to Dev node

 

The role collection will be created in the DEV subaccount.

Master_Admin%20in%20DEV%20subaccount

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%20to%20QA%20node

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.

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

 

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.

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.