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 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
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.
| 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.
- SAP Managed Tags:
3 Comments
