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

Transporting role collections between BTP subaccounts Part1 : Custom tool

Introduction

In this blog, I’m going to introduce a tool which I developed for transporting role collections between BTP subaccounts. Keep in mind that this is just a PoC and not intended for productive use.
The code is available at GitHub.

While writing this blog post, I learned that it is possible to transport role collections with xs-security.json even if the roles used are not from the same xsuaa service instance.
Anyway, I’m sharing this content to introduce what I’ve developed. Also, I’ve decided to write another blog post for demonstrating how transporting role collections can be achieved by standard approach.

 

The tool

Idea

The idea is to use Authorization and Trust management Service API to create and update role collections in a target subaccount. Based on the role collection settings of the source subaccount, the tool will create or update a role collection with the same settings in the target subaccount.

Architecture

The diagram blow shows the architecture of this tool.

  • UI5 app and CAP are running behind a standalone approuter
  • Destinations pointing to Authorization and Trust Management API in source and target subaccounts are registered
  • CAP calls
    • the API in the source subaccount to extract the definition of role collections to be transported
    • the API in the target subaccount to create or update role collections there

Solution%20Architecture

Solution architecture

Prerequisites

  • All the roles included in role collections to be transported have to be in the target subaccount.
  • Role collections in the source subaccount have to be maintained manually.
  • HANA Cloud instance has been created in the source subaccount. (tutorial link)

 

Initial Setup

1. Clone the code from GitHub, build and deploy to Cloud Foundry

You will find the approuter in subaccont space.

Approuter

Approuter

2.  Create xsuaa service instances with plan “apiaccess” in source and target subaccounts

cf create-service xsuaa apiaccess <access_name>

 

3. Create service keys for the service instances you just created

cf create-service-key <access_name> <key_name>

 

4. Create destinations pointing to Authorization and Trust Management API referencing the service keys

Property Value
Name Destination Name (Any)
Type HTTP
URL “apiurl” in the service key
Proxy Type Internet
Client ID “clientid” in the service key
Client Secret “clientsecret” in the service key
Token Service URL “url” int the service key + /oautn/token

 

Destination

Destination

5. Check application identifier suffix in each subaccount

You can see the suffix in any role registered in the subaccount. The suffix starts with “!” and varies by subaccount.

Suffix

Suffix

 

How to use

Now the initial setup is done, let’s start using the tool!

1. Open the approuter URL
You will see below screen.

Home%20screen

Home screen

 

2. Maintain destinations

Go to Settings>Maintain Destinations. Here you register combinations of destination and suffix.

Maintain%20destinations

Maintain destinations

3. Start Transport

Go to Transport>Role Collections.

First, select source and target destinations.

Select%20destinations

Select destinations

 

Second, specify role collections you want to transport. You can input multiple role collections separated by line breaks.

Input%20role%20collections

Input role collections

Finally, confirm the role collections and press “transport”.

Confirm

Confirm

The following screen will be displayed. Transport may take a few minutes.

Transport%20in%20progress

Transport in progress

When the transport is complete, you will see below message.

Transport%20success

Transport success

 

What the tool does

Let me explain what the tool does behind the scenes. I’m using Postman to show how APIs are called.

1. Extract definition of the role collection to be transported from the source subaccount.

Roe%20collection%20in%20the%20source%20subaccount

Extract role collection definition from the source subaccount

 

2. Replace the suffix in the definition with the suffix of the target subaccount.

As roles get suffix which is unique to the subaccount, we have to replace it with that of the target subaccount before sending the definition to the target subaccount.

Replace%20Suffix

Replace suffix

 

3. Post the role collection to the target subaccount.

Post%20Role%20Collection

Post role collection

If the role collection already exists in the target subaccount, the tool updates it according to the definition in the source subaccount.

Rooms for improvement

The current status of the tool is a Minimum Viable Product (MVP) and there is much room for improvement. The following is a list of those that come to mind.

  • Keeping transport logs
  • Adding authentication and authorization checks
  • Validation of destinations
    • check if they exist in the source subaccount
  • Validation of roles when role collections are entered
    • check if roles included in the role collections exist in the target subaccount
  • Selecting role collections from a list

Conclusion

In this blog post, I’ve introduced a custom tool for transporting role collections.
In the upcoming blog post, I will demonstrate how to transport role collections with MTA and Cloud Transport Management Service.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Yogananda Muthaiah
      Yogananda Muthaiah

      Well articulated Mio Yasutake !!

      Author's profile photo Mio Yasutake
      Mio Yasutake
      Blog Post Author

      Thank you Yogananda Muthaiah for reading and leaving a comment!