This discussion is meant to kick-start new developers in using onePortal™ on their external applications revealing their own protected APIs. The general term used for such application is a Resource Server, or RS for short.

Current state, group-to-role mapping

In addition to being OpenID Provider, or OP for short, onePortal™ has its own integrated Resource Server, RS. Things are little different in that case, but not much. The image below should clarify the arrangement in the case of external Resource Server.

The important break-out from identified user account to the external Resource Server deciding if that user account may for example do a certain task in the line-of-business applications is the group membership. Basically for each role in the application, there is similarly named group in the namespace in onePortal. It is actually recommended to use same name for group and the associated role.

We focus on the group membership next. The group membership is available in different ways:

1. The external application queries from onePortal™ Resource Server REST API (Management API) this information. This option also allows for the external application to manage (create, modify, remove) both user accounts, groups, and group memberships.
2. Signed-in user account may normally query the OpenID Connect Userinfo end-point for group membership. This is read-only information. This may be a good option for some specific types of applications and user interfaces.

For those cases when the external application manages the user accounts and groups, it is beneficial do some caching. How much caching is done, is a matter of business decision more than a technical one.

All this applies whether the external application is implemented as a stateless clustered microservice, or a more monolithic traditional application. Also, it does not matter where the external application database resides. It may even not have a separate database at all, and it only uses the Cloud DB in onePortal™.

Future custom scopes

We are adding the possibility to add custom scopes. Those scopes are basically just strings. onePortal™ does not care, nor understand the meaning of those scopes.  External applications may use those scopes for fine-grained permission management.

More details will be provided here when this feature has moved to testing.