Managing identity for multi-tenancy

As noted previously, when a user identity is authenticated for a multi-tenant database connection, it assumes the regular or super tenancy that is configured for the user's domain in that particular database. For a different multi-tenant database, the user's tenant or super tenant can have a different name, as specified by the domain configuration in that database.

Because an ABL application and its databases can be configured to use a single session domain registry for all database connections, the domain registry does not contain tenancy information for every database that a user might access. Instead, ABL reads the database domain configuration for each new database connection that is authenticated for a given user identity in order to identify the user's tenancy. However, ABL also caches this database tenancy information in the user's client-principal object. This allows the user to assert the same tenancy for additional connections to the database in other ABL sessions or for another connection to the same database that has been disconnected in the current ABL session, all without having to lookup the tenant identity in the database each additional time. The user thus gets consistent tenant access across the login session because the tenant ID in the client-principal is used for all SSO operations that set the user identity.

This cached tenancy information includes three components, the:

These three components help to ensure that the tenancy information for a given user identity is unique for all likely databases, even if two different databases have the same logical name. ABL maintains this cache of tenancy information in a given client-principal object for every database connection for which the object has been used to authenticate the connection identity. The client-principal object maintains this cache whether or not the database is still connected or is connected in the same ABL session where the connection was originally authenticated. The information in this cache is only removed when the client-principal object is deleted from a session.

Generally, OpenEdge identity management enables tenancy to be transparent so your code works the same whether it is running against a multi-tenant or non-multi-tenant database. However, if you have a need (perhaps to retrieve other tenancy information as a super-tenant), you can access the current database tenancy information that is cached in a client-principal object using the following attribute and methods: