onedevatlasBeta
Browse the atlas
AllBTPCAPUI5ABAP
SampleSampletypeA worked example you read or clone. Evidence: it demonstrates, it never provides.See every one →What this type is →independently maintainedindependently maintainedoriginPublished by one person or a small company outside SAP. Says nothing about quality; the readings say that.See every one →Reference

auth-transport2

Three MTA projects that declare a role collection in one xs-security.json out of role templates owned by the other two, so it can be transported rather than recreated in each subaccount.

parent/xs-security.json declares the role collection Master_Admin and reaches the Admin role template of each child through the $XSAPPNAME(application,xsuaachild1).Admin form, which is how a role collection references a role template in another xsuaa instance. child1 and child2 each declare that Admin template over an $XSAPPNAME.Admin scope of their own, and each of the three mta.yaml files carries nothing but the xsuaa resource that deploys its own xs-security.json. Mio Yasutake's second post on transporting role collections lists these same files and moves the parent through SAP Continuous Integration and Delivery and SAP Cloud Transport Management into a second subaccount, which puts an order on it: the child MTAs have to be deployed in a subaccount before the parent is imported there. Two conditions come with the route: a role collection created from xs-security.json cannot be maintained by hand in the BTP cockpit, and one maintained by hand cannot be updated from xs-security.json. An xsappname containing an underscore fails the deployment.

GitHub0 ★

Facts

Last push

Where it sits

Lives in
BTP/BAIP
Demonstrates
Account provisioningBTPAccount provisioningcapabilitySetting up cloud accounts, their organisational structure, resource entitlements, subscriptions and access assignments so the setup can be repeated from code. [Deployment](capability:deployment) puts an application onto a runtime that this account structure makes available.AuthorizationBTPAuthorizationcapabilityDeciding who may read or change what, at service, entity and instance level — role checks, forwarded user context, and restrictions evaluated as query filters rather than after the fact.
Requires
SAP Authorization and Trust Management serviceSAP Authorization and Trust Management serviceartifactEach of the three projects deploys its own xs-security.json as an xsuaa service instance; the role collection exists because the parent's instance declares it, and the role templates because the children's do.

Who is behind it

Mio YasutakeMio YasutakePersonMaintains this
In the atlas: maintains 47, contributes to 47, wrote 10@miyasutamaintainer

Before choosing this

Signals

LicenceNo licenseNeither the package manifest nor the repository tree declares a licence

Without a licence the default is all rights reserved. Ask the maintainer, or check for terms stated elsewhere, before depending on it.

What it declares

Every artifact

Type
Sample
Origin
Independently maintained
Use as
A reference

As a sample

Form
does not say

Connections4

Others providing

Declared alternative
  1. auth-transportUI5 app and CAP service copying role collections between subaccounts

Details

Sources2
GitHub organisations and accountsdiscovered here, miyasutachecked
github.com/miyasuta/auth-transport2tree, pushes, contributors, CIchecked

Sources are graph entities: the same page may back several entries, and an unreachable source flags every row that rests on it.

Compatibility and provenance
discovered viaGitHub organisations and accounts · miyasuta
first seen in the atlas
ecosystem and domainbtp, operations-and-runtime
History in the atlas1
  1. First seen.
For your agent
Ref
artifact:miyasuta-auth-transport2
JSON
/artifacts/miyasuta-auth-transport2.json
MCP
Connecting an agent