Throughout the development life-cycle of your platform and product applications, you’ll have multiple environments. Common ones include Production and Staging, although there can be many more. This article answers the question of how best to architect your Authress account to manage having these different environments.
The optimal solution encourages having only a single Authress account. There are many reasons for this:
Having multiple Authress accounts is supported, but not recommended. Where possible the Authress development team wants to enable a single Authress account to work for your use case. If for some reason it won’t work, please let us know.
With multiple environments integrating with and operating in the same Authress account the following aspects need to be explicitly considered:
The Authress recommendation is to create separate service clients for every environment. This provides two benefits:
Overall, the same roles that work in one environment, will work for all environments. This is because roles are a collection of permissions (See Permissions and Roles for more information on this.) Permissions are scoped usually to a type of resource, and are of the form resource-type:action
such as documents:read
. There is no environment included in the permission or role, so roles can be reused.
If we place an environment identifier in the resource path, for instance prod:tenants/{tenantId}
, then throughout your application your environment identifier must present. This is brittle. A more reliable solution is for every resource ID that is generated to be unique to the relevant environment. For instance tenants
could be generated with a tst_
prefix in non production environments, although in general, simple uuid
s will almost guarantee that there are no conflicts and avoids this extra and unnecessary complexity. Some platforms prefix the type of resource as part of the guid. Adding an extra character for the environment can be a great pattern to understand what the type of resource is just by looking at the id string. doc_tst_0123
versus com_prd_a1
immediately tell us a document created in the test environment as compared to a comment created in the production environment.
These aren’t required, but we have found common solutions that make it easy to solve most problems and get up and running with even very complex platforms.
service:prod:resources/{rId}
is a bad idea. However, putting the environment in the IDs themselves, should not cause a problem.Admin (*)
to service:resources/*
for each type of resource that the service will control.recordId
after generation.If the staging
and production
service clients both have Admin (*)
access to all the services’ resources, isn’t this a security concern?
Generally, no. The reason is that even though they both have Admin
access, the resources they have access to are only the ones that the service itself owns. The only service that checks access to these resources is itself. Concretely:
Admin
access to all the production resources.So even though the Staging service will check the same permissions as the Production service version, it can’t and won’t return the production version of the resources because it doesn’t have them in the database.
To further avoid issues here, it is common to generate an access record with the id Tenant:{TenantID}:ResourceType:{ResourceID}
. This will cause a 409 if the other version of the service attempts to create that access record even though it already exists.
Didn't find what you were looking for?
You can ask your questions in our community:
Or send us an email at support@authress.io