[RFC] From Identity to Ownership

[freben]

Status: Closed for comments

This RFC takes a higher level view on how we should go from the identity of the logged in user, to showing the correct list of entities that they own in the Backstage interface. This involves a number of actors and interactions.

Need

The concept of ownership plays a key role in the Backstage system.

Backstage users expect to be able to clearly see what entities that they themselves are responsible for, collected nicely with their current statuses in the interface. Users also expect to be able to go to the page for another user or group, to learn about their responsibilities. They also want to be able to search for an entity such as for example a malfunctioning service, and to see who is responsible for that service to help fix it.

We also expect that these ownership concepts will be relevant outside of the Backstage website. For example, monitoring systems that integrate with the Backstage catalog may want to perform lookups based on a service ID and send automated alerts to the relevant owner team when things go wrong.

Actors

The following moving pieces are potentially involved in a solution:

System	Purpose	Responsibility in the scope of this RFC
Sign-in (Authentication)	Allows users to sign in to Backstage.	To negotiate an identity inside an external system, and to somehow translate that identity into an identity reference that makes sense inside Backstage.
Authorization	Allows users to authorize actions in other systems, by negotiating access tokens.	Not used currently, but could be used similarly to the authentication, to translate the external system identity into an identity that makes sense inside Backstage.
Entity Descriptor Files	Where users create YAML entity descriptor files by hand, or with the help of automation plugins.	To let the user write some form of explicit reference to an owner.
File Ingesting Processors	Processors whose purpose it is to populate the catalog with entities, most commonly based on entity descriptor files.	To automate the mirroring of entity descriptor files into the catalog.
Org Ingesting Processors	Processors that mirror organizational data out of sources such as LDAP, and store them as User and Group entities.	To produce User/Group entities whose metadata is rich enough to be used for lookups by other systems.
Enriching Processors	Processors that fill in gaps in the entity data, for example by reading CODEOWNERS files and setting ownership based on them.	To fill in owner references in entity descriptors where missing, in a way that aligns with the org ingested entities.
Extracting Processors	Processors that analyze entities and generate entity relations based on them.	To take the stored owner string in the entity, and translate it to a full relation reference to an actual User or Group entity.
Backstage Frontend	To present ownership in a cohesive way.	To read the catalog and, with as little logic as possible, deduce ownership across entities.

Meet John

Let's look at what John's setup looks like.

• John signs in to Backstage using Google as an auth provider, which internally leads to a JWT pointing to his GSuite identity john.knowles@example.com.
• He also makes use of some public GitHub features, so his Backstage usually holds an OAuth2 access token issued to his GitHub user johnHaxxesBezt (don't judge, he made it before joining the company). He does some open source work there.
• Their internal systems actually use LDAP as the source of truth, and his userid there is just plain john since he was one of the early founders. He's a member of the InfraNinjas team, which is infra-ninjas in LDAP and can be reached on infra-ninjas-team@example.com because that's the naming standard.
• The company uses GitHub Enterprise as the main development platform. They sync their GHE teams and users with LDAP, but it's an ad hoc process where users set the teams up where necessary and have to check the box to sync with LDAP. There are a lot of non-LDAP teams too, like system-blah-maintainers. Well at least he's just plain john as his user on GHE.
• They are heavy users of CODEOWNERS to facilitate distributed development in their monorepos.

John is setting up Backstage and wants to know what settings to use. The docs say that he should want to end up with entities that have ownership relations to other entities, and that his sign-in should somehow map to the users and groups.

But it's not clear how things relate to each other:

• The sign-in results in his public Google email address.
• He has some components in public GitHub and some in GitHub Enterprise, whose team/user setups aren't the same to each other, and don't map 1:1 to LDAP either way
• He knows there is a processor that can ingest GitHub teams/users, but should he be mirroring both GitHub and GHE, and what would that look like?
• He knows there is a processor that can ingest LDAP groups/users, but these don't seem to have an obvious way to relate to the GitHub/GHE ones.
• There are a lot of pre-existing CODEOWNERS files he wants to leverage, but they are expressed in terms of the team structure in GHE, and the processor seems to write those IDs down verbatim into the entities.

Current State

The AuthResponse type as returned when logging in currently has the following shape:

backstageIdentity:
  id: "freben"
  idToken: "ey..."
profile:
  displayName: "Fredrik Adelöw"
  picture: "https://avatars2.githubusercontent.com/u/..."
providerInfo:
  accessToken: "e411..."
  scope: "read:user"

This is what the auth backend supplies to the frontend, based on the response from the auth provider. This is also the input data that the frontend has to work with in order to deduce ownership. Currently, we look for a User entity with metadata.namespace equal to "default", and metadata.name equal to backstageIdentity.id. However, the profile may have been extracted from the auth provider data, not from the catalog.

The way that the ID is chosen, also varies. The Google provider searches for a catalog user that has a Google specific annotation matching the email. The Microsoft provider just grabs the first part of the email address and returns that. The GitHub provider just uses the GitHub username verbatim.

The problem is that this creates a strong coupling between the behaviours of each provider in the auth-backend, to catalog shape and the behaviours and config of org ingestion catalog plugins. The IDs chosen are often essentially keys in foreign spaces, not clearly mapped to catalog users. It becomes very hard to, for example, use Google for login but LDAP for org data.

The org ingestion plugins aren't particularly flexible; for example, the GitHub one doesn't let you set a specific namespace at the time of writing, so there may be collisions if you try to import more than one thing.

The CODEOWNERS processor just takes the entries in the lines of its file as-is and writes them down in the spec. This forces the operator to make sure that there are User/Group entries in the catalog that match those particular strings.

The processors system is pretty flexible. You can correct for some level of mismatch by making an "adjusting" processor that tweaks the entities to fit the bill before storing them. But that's not the best adopter experience to have to do, and it only has the ability to solve part of the problem.

Proposal

Phase One

In the first phase, we focus on the following:

• Expect there to be just one org hierarchy if any, which is from the most authoritative source available. For John, this would be LDAP. The users and groups are typically in the default namespace.
• Still support running Backstage with no org data ingested in the catalog, and logging in as an identity that does not match any catalog User at all.
• Expect the logged in identity to match one or zero users, no particular support for matching more than one
• Do not focus on codeowners. This use case is still functional, but may fit best for those that get org data from their SCM provider. For others, some amount of adjustment can be done with a custom processor.

The proposed changes:

• Task the auth backend with explicitly linking the auth provider response with a catalog user where possible. This involves making it possible to give a custom callback to the provider code, that can make requests to the catalog.
• As part of this callback, we also gain the ability to reject the login by throwing an exception - for example, to ensure that the email was a work email rather than a personal/unrelated one.
• Extend the AuthResponse to contain either the entire User entity, or at least the full kind + namespace + name triplet. The latter, or at most some subset of the user, may be preferable to an entire entity, to better support the case where there actually was no matching User entity and instead some "mocked" data is returned.
• Make the auth backend use the catalog User as a source for profile data, where available.

We will update the way that the auth providers are initialized, so that the backend can pass in these custom callbacks.

// Current packages/backend/src/plugins/auth.ts
return await createRouter({ logger, config, database, discovery });

You can supply a providerFactories argument here to customize the set of supported providers, but these factories may need to be amended and changed around a bit to make room for this callback to be supplied.

// Hypothetical future packages/backend/src/plugins/auth.ts
const providerFactories: ProviderFactories = {
  google: googleProviderFactory({
    // At this point, the authResponse can actually be typed and distinct for the
    // provider at hand, where applicable
    async onLogin({ authResponse, catalogClient, identity }) {
      // reject the response entirely by throwing, otherwise try to find a
      // matching user using the catalog client
      identity.setProfile(...);
      identity.setUserRef(...);
    }
  });
};

return await createRouter({ logger, config, database, discovery, providerFactories });

Phase Two

In a second phase, the following focus areas could be added:

• Multiple current org hierarchies in the catalog
• Ability to match an identity to multiple users

The proposed changes and effects:

• Let users ingest more than one org hierarchy into the catalog, for example John might want to have both GitHub and LDAP reflected. They may be stored in their respective namespaces to keep them separate.
• Let the logged-in identity match more than one user. This would mean that after login, John would be clearly associated both with his GitHub and LDAP users and their respective groups. This could mean slightly more work in the backend auth setup code.
• The above will also make the codeowners situation much clearer. The codeowners processor can be given the same namespace parameter as the GitHub org ingestion, so that the system-blah-maintainers team lines up with the groups that correspond to those teams.

Alternatives

One type of alternative that we discussed, was to use a standard shape of metadata.labels that are used for selecting users that match a certain identity.

For example, in John's case the login implies that the identity, specifically in the scope of Google, is "john@example.com". This could be used to search for catalog entities that have a label identity.backstage.io/google: john@example.com, where google is the ID of the provider. If he instead logged in with their GHE, his identity, in the scope of GitHub Enterprise, is "john". Then we search for users that are labeled identity.backstage.io/ghe: john. Interestingly, this label could be on any number of users from any number of org ingestions in any namespace, without any coupling to those ingestions.

However, the caveat here is that the ingestions must now instead be pluggable in a sense, to populate all users and groups with the right set of labels. A GitHub org ingestion can fairly easily tag a GitHub user with its own identity label without customization, but it has no current way of knowing what Google identity label that it corresponds to - if any. So the need of matching across domains is not necessarily addressed by this. There currently exists no GSuite org ingestor - what will John do when he logs in using Google? How will Backstage know that his Google identity actually happens to match with the john user in GHE?

One way of addressing the latter case, could be to for example make it possible to only ingest the LDAP org, and to extract the email attribute of each user entry into the identity.backstage.io/google label because we know that that's how this particular org works. And then for those users that happen to have the custom attribute gitUserName set, map that to an identity.backstage.io/ghe label. This would need to somehow be driven either by configuration or by injection of custom code, in the LDAP org processor. But that only works out if such a gitUserName attribute exists; if it goes the other way instead and the GHE users are bound to LDAP, we'd want to instead make a reverse lookup, and that's not something that exists currently.

Risks

There is a risk of not getting the balance of flexibility at the right level.

This RFC also does not cover how this identity-to-ownership mapping would translate outside of the Backstage backend. In server-to-server scenarios, where you for example make requests to the catalog backend to list users, groups, or entities, it will not be clear from the data itself how ownership maps.

[Rugvip]

Before reading it all, I'm liking the alternative of identity.backstage.io/<authProviderId> since each auth provider has a known mapping. It provides some proper namespacing of the different providers, something that e.g. a github.com/login label couldn't do.

[GoWind]

My initial opinions with modeling Identity and Ownership is that Backstage need not step on this area of responsibility,
atleast at this stage.
Modeling users, accounts and most importantly, the connection between accounts is very messy. A lot of organizations use perhaps multiple different account sources (Google, LDAP, GHE) to name a few and there is no simple, UNIFORM way to reason about them.

Rather than attempting to model this in Backstage, we should allow users to build this connection by themselves.

1. Ownership information is ingested via Processors. In the case of using custom Processors , or existing ones, The users of Backstage know exactly what is the source of Identity/Ownership information is encoded in the Entity definition (that is , users know if the owner, group etc present in the Entity definition, come from LDAP, GHE, Google etc)

2. The contract of the Login Process is very clear. AuthResponse contains a ProviderInfo with certain "claims" and an id and possibly an idToken.

Mapping this information in AuthResponse to that in the catalog is, in my opinion, the realm of the specific backstage app's implementation.

For example, we have a custom plugin providing CI/CD features that uses the access Token present in the ProviderInfo, to request user/team details for our internal LDAP facade and then use it to fetch information about pipelines from an existing CI/CD service. This translation is done by our plugin's frontend and the backend.

Similarly, for the catalog service, we were thinking of writing a wrapper on top of the Catalog backend's endpoints to do do some of the lookups, before issuing the right query to the backend's API.

The reason for this is , we are still not sure how to model group and ownership information and if and when we should. Although my team would like to model the LDAP groups and users within Backstage, it still need organization approval and other technical limitations that we cannot discuss now. Therefore if backstage prematurely decides to model this in the Catalog , we will have to spend a lot of time addressing and working around it.

To me a simpler solution might be to let users override the ProviderInfo in the frontend, such that after authentication, it can contain the information about all the different user profiles for the user. For example, once a user logins in with SSO, a custom AuthProvider implementation can wrap Google SSO, so that it then uses the signed-in user's Tokens to further request info from an LDAP server, source code server etc and fill in the user's session with that information. Plugins can then use this information in the ProviderInfo as they see fit and pass on the relevant information to the backends and the Catalog.

[backjo]

I'm also a fan of the label-based approach for resolving identities from multiple IdPs to a single identity in backstage, rather than having multiple users in discrete namespaces. As you point out, It introduces more complexity on the catalog processors - but IMO it encapsulates that complexity fairly well, so that consumers of the catalog API don't need to understand how the same user relates across multiple IdPs

[erikxiv]

From a newbies perspective (w/o understanding how processors work): I believe users would expect to be "the same user" regardless of which login provider is used. E.g. regardless if I log in via Github or Google, I would still expect the system to show me "my" services. It might also be that my company does not allow me to login to our top-secret Backstage via github.com credentials, but we still want to utilize my github.com account for client-to-server activities to facilitate authorization and auditability. As such, a made-up nomenclature might be:

• user - each actor/person using Backstage is mapped to a single user
• login - a user may be authenticated using multiple login providers. Every login is mapped to a single user.
• authorization - a user may utilize multiple authorization providers in a single session to authorize against external systems

With the above in place, groups become less sensitive as a user would be easily mappable to groups from different providers using the login-to-user mapping. It might still be beneficial to "merge" groups from different providers for various reasons, but backstage would probably be able to show a list of all users that own an entity without it. Some companies use CODEOWNERS, some LDAP, most use a combination of multiple sources.

If we accept the premise above, the problem of merging multiple sources into a coherent single source of truth moves into the master data problem domain. As @GoWind mentions, there will be no clean model that works for everyone. The best backstage can do is provide a strategy and helpers where adopters can supply their own mappings between only-somewhat-similar identities across systems. (One can also make life simpler by using a single auth provider/source of users/groups if that suffices)

[GoWind]

login - a user may be authenticated using multiple login providers. Every login is mapped to a single user.
authorization - a user may utilize multiple authorization providers in a single session to authorize against external systems.

Login and authorization, I believe are one and the same. Each authorization provides a Login. A single user, theoretically might be able login via multiple authorizations simultaneously (LDAP, Github, SSO) at the same time, but they will still be mapped to One specific Backstage User.

Let us consider the usecases for the Catalog.

I am making points from the perspective of my organization, but I think, they are general enough and apply to many organizations across the globe (and interstellar, in case aliens are listening :)).

1. Authoritative source of Entities
2. Viewing Entities
3. Performing actions on Entities

For example, we already have existing catalogs for various software entities as the source of truth. This will not likely change for the forthcoming few years so 1) is ruled out. The catalog will serve mostly as an aggregation of existing sources, fed by ingestions.

2. Viewing Entities:
   2a. Viewing a Logged in User's entities - This is where ownership information helps as it helps figure out which entities are owned by the loggin in User , across domains and displays them. To me THIS is the direct usecase where modeling all of the existing owners and groups , across login/authorization domains, in the catalog, helps.

   2b. Viewing any entity - User queries exactly for an entity or a set of entities. In this case, you are mostly fetching based on a Primary Key(of sorts) or against a set of constraints. Unless your organization has compliance rules, such as NOT displaying sensitive entities to un-authorized users (Example: PCI Compliance), you will not need the ownership information at all to decide on anything.

3. Performing actions on Entities- Plugins in Backstage can use use ownership information on Entities to decide whether a user can perform an action or not (Delete entity, modify it, Deploy entity, etc). Unless the Catalog is the authoritative source of information , this will not be solved by modeling groups and users.
   For example, even if I do represent my team's public Github repos in our Backstage, it is ultimately, Github that will take a look at my access tokens and decide if it should delete the resource or not. Even if I attempt to delete an other team's repo, the request will be denied, as Github and the information stored in it remotely are the sources of authority and truth and not Backstage/Service Catalog.

In this case , Catalog is merely a facade that shows a unified view of all entities across multiple login/authorization domains. While it might be nice to make connections, I do not think that it should make any inherent assumptions because it will most likely, at this stage , not be the source of truth in any larger system. Rather as @erikxiv suggests, it is better to let the organizations/teams implementing Backstage to draw the connections and decide what actions to be allowed (via plugins, interfaces etc).

[GoWind]

Cross-linking a comment because I think it is relevant here

#3867 (comment)

[freben]

From a newbies perspective (w/o understanding how processors work): I believe users would expect to be "the same user" regardless of which login provider is used. E.g. regardless if I log in via Github or Google, I would still expect the system to show me "my" services.

Glad you brought this up, because I think it's worth clarifying, that this is not meant to be in scope for this RFC!

The normal, overwhelmingly most common situation will be that you have one sign-in provider; the company picks one or more likely already has one picked because it's what a lot of their other web based products use (maybe the intranet, the onsite jira, your teamcity, or whatnot). Keep it simple and familiar.

It may even be that that sign-in provider is outsourced to an external reverse proxy, and the first thing your "sign in page" does is to just leverage the headers passed down by that proxy, so there's no real sign in page ever rendered by Backstage itself at all. This is how we do it internally. We just get a certifiably trustworthy claim that the current user has the email address so-and-so, and then we get the rest out of our central IAM backend.

We then want that use case to be great; you can perform your duties as an employee effectively and see your things - as seen from the company's perspective, as attached to your day-to-day work. We think that for most, this will be a great baseline. We need to figure out how that single sign-in identity maps to your entities and their owner fields, which is what this RFC is about.

Then as a next step, farther down the line, you feel that hey, we also want to track these other things over here, that I actually develop using a different identity. Like my public GitHub persona which is different from my internal Spotify persona.

So then comes the question, what do we do then?

We could ingest a whole parallel org tree from that other source, and label my user identity.backstage.io/github: freben. Then the sign-in part has to tell Backstage that "ok this sign-in identity Fredrik, now it wants to match on TWO labels instead of one". That means that the sign-in system would have to somehow know that "in GitHub, this guy happens to be known as freben". Where do we source this from, is one of the concerns. Well it'll likely be company specific, and has to be pluggable.

The benefit of having the parallel org hierarchy, is that we then have actual tangible entities, that have Backstage views of their own, where you can see how they relate and own things and belong in a bigger picture. And this second hierarchy doesn't have to map to the first one in any way at all! It's just that my sign-in persona now matches both the entity user:companyname-org/fredrik, and the entity user:github-org/freben in their separate "org clouds", which are are attached to their own separate group trees etc. So when an entity is registered from github, that has a codeowners entry saying that it is owned by blah that only makes sense in the GitHub world, then that's fine, because the user user:github/freben has a relation saying that it is memberOf group:github/blah.

Well OK, let's shift to another perspective: we could make the sign-in system supply all of your user and group relations directly instead. So after sign-in, that part of Backstage already has the ability to say that you are member of the group group:github/blah, whether it exists in the catalog or not. So then that could be matched against that exact owner field of a GitHub entity, without going through user/group entities. OK but now how will the sign-in system source all of THAT information, and does it make sense for it to have that responsibility? Maybe, for some?

And if I understand @GoWind correctly, the argument is that maybe even that can be too much to be forced to adapt to. Maybe instead the sign-in system should just give out some token and opaque ID like today, and then it is up to the app to have to supply the piece of code that takes those two as parameters, and returns the things you own, somehow, in your org specific way. And my general feeling is that while I appreciate that that sounds flexible and non-committal, it also leaves out some of the benefits that a more opinionated system could have. For example we cannot leverage any org knowledge from the outside. API consumers of the catalog will be basically helpless to stitch things together. Third party plugins written by others may have a hard time making sense of the structures. Everything except ownership stays unsolved, like for example it won't help you be able to visit the team-a entity page and see what they own and what their cost profile is and who are members of it and how it fits in the org hierarchy and how to contact them by mail and what their slack address is and who the design owner is and what their PagerDuty rotation is like so we know who to contact and where to click to wake them up with an alert and ... well, I'll stop there. There's a massive amount of functionality to be had on top of org entities, and we make extensive use of them internally, and we hope that if we make it easy for others to get their org data into Backstage, they'll find that the total value of the system increases massively.

But maybe there's a middle ground where the barrier of entry is not overwhelming to anybody, while still providing as much value as possible out of the box.

It might also be that my company does not allow me to login to our top-secret Backstage via github.com credentials, but we still want to utilize my github.com account for client-to-server activities to facilitate authorization and auditability.

Yes, and it will probably make sense to keep signing in using the same flow as always, but using the separate mechanism of OAuth access tokens to perform operations in external systems, and then to have your things ingested easily and automatically into the catalog for visibility and searchability etc.

As such, a made-up nomenclature might be:

• user - each actor/person using Backstage is mapped to a single user
• login - a user may be authenticated using multiple login providers. Every login is mapped to a single user.
• authorization - a user may utilize multiple authorization providers in a single session to authorize against external systems

With the above in place, groups become less sensitive as a user would be easily mappable to groups from different providers using the login-to-user mapping. It might still be beneficial to "merge" groups from different providers for various reasons, but backstage would probably be able to show a list of all users that own an entity without it. Some companies use CODEOWNERS, some LDAP, most use a combination of multiple sources.

I think this aligns with the idea above that as long as the sign-in process can tell you a list of all groups that you belong to in different contexts, we're golden. Right?

If we accept the premise above, the problem of merging multiple sources into a coherent single source of truth moves into the master data problem domain. As @GoWind mentions, there will be no clean model that works for everyone. The best backstage can do is provide a strategy and helpers where adopters can supply their own mappings between only-somewhat-similar identities across systems. (One can also make life simpler by using a single auth provider/source of users/groups if that suffices)

Yeah I want to avoid the merging part if possible. The different domains will likely turn out to be too heterogenous to be able to reconcile them. It's probably better if the sign-in persona can be cleanly mapped to all of the users (and groups, directly or indirectly) that they are part of.

[freben]

just coding out loud

//
// Part of sign-in core code
//

const catalogApi = useApi(catalogApiRef);

// These are all optional and you may supply them any way you like or not at all
const userLabelMatcher: KeyValue | undefined = signInResult.userLabelMatcher;
const catalogUser: EntityName | undefined = signInResult.catalogUser;
const catalogGroups: EntityName[] = signInResult.catalogGroups || [];

// That way we can source the data directly out of whatever the sign-in says, OR
// out of the catalog if you have the org data in there
if (userLabelMatcher) {
  const users: Entity[] = await catalogApi.getEntitiesByLabel(userLabelMatcher);
  for (const user of users) {
    if (user?.relations) {
      catalogGroups.push(...user.relations.filter(r => r.type === 'memberOf'))
    }
  }
}
if (catalogUser) {
  const user: Entity | undefined = await catalogApi.getEntityByName(catalogUser);
  if (user?.relations) {
    catalogGroups.push(...user.relations.filter(r => r.type === 'memberOf'))
  }
}

//
// Later deducing what entities you own
//

const identityApi = useApi(identityApiRef);
const catalogApi = useApi(catalogApiRef);

const groups: EntityName[] = identityApi.memberOfCatalogGroups();
const owned = catalogApi.getEntities()
  .filter(e => (e as any).spec?.owner <is in groups>);

[freben]

Updated the above to fit both label matching and direct matching

[GoWind]

Cross linking my comment about idTokens, as they should be able to provide the same groups info, without having to query the catalog
#3867 (comment)

[GoWind]

We could ingest a whole parallel org tree from that other source, and label my user identity.backstage.io/github: freben. Then the sign-in part has to tell Backstage that "ok this sign-in identity Fredrik, now it wants to match on TWO labels instead of one". That means that the sign-in system would have to somehow know that "in GitHub, this guy happens to be known as freben". Where do we source this from, is one of the concerns. Well it'll likely be company specific, and has to be pluggable.

The benefit of having the parallel org hierarchy, is that we then have actual tangible entities, that have Backstage views of their own, where you can see how they relate and own things and belong in a bigger picture. And this second hierarchy doesn't have to map to the first one in any way at all! It's just that my sign-in persona now matches both the entity user:companyname-org/fredrik, and the entity user:github-org/freben in their separate "org clouds", which are are attached to their own separate group trees etc. So when an entity is registered from github, that has a codeowners entry saying that it is owned by blah that only makes sense in the GitHub world, then that's fine, because the user user:github/freben has a relation saying that it is memberOf group:github/blah.

So the actually problem, that you want to address is NOT having or ingesting multiple org hierarchies or catalogs, BUT how does one Signed-In Identity have access to multiple personas IN DIFFERENT namespaces, simultaneously?

This is tricky and might not be feasible. The Sign In provider MIGHT provide me a mapping of my Org persona to my Git persona, but that DOESN'T necessarily mean that I am logged into Github and can view the entities tagged with my Git persona.
I believe that you have to be atleast authorized by each respective namespace before you can view your entities in that domain , and there can be only be only one authorized namespace at any moment in time.

Third party plugins written by others may have a hard time making sense of the structures. Everything except ownership stays unsolved, like for example it won't help you be able to visit the team-a entity page and see what they own and what their cost profile is and who are members of it and how it fits in the org hierarchy and how to contact them by mail and what their slack address is and who the design owner is and what their PagerDuty rotation is like so we know who to contact and where to click to wake them up with an alert and ... well, I'll stop there.

This territory is organization specific, sadly. Currently , we allow users to view another organization's information, for example , including cost reports, etc, but they are not authorized to make changes on behalf of another team. But, although it curtials the ability of Backstage to provide some rich features, this should be opt-in , rather than opt-out. I would definitely try making it easy for organizations to opt-in to provide such transparency and features, though.