azuma doa

azuma doa consists of the following important components

• Identity Provider: Full service identity provider with SSO, self-service flows and MFA/2FA authentication support
• Tenant Management: Integrated multi-tenancy support to implement one user account across multiple organizational domains
• Roles & Permissions System: Integrated roles & permissions setup applied on top of the tenant management solution including customer application roles & permissions
• Health industries specialization: Domain specific implementation of the IDP/IAM requirements for the health industries including account validation (automatic) and verification (manual)

Identity and tenant management

azuma doa implements a full identity provider/management system that can be easily integrated in your application. Unlike known IDP systems on the market, the idea is not for you to manage the identities, but rather to integrate into and benefit from a setup and operational IDP system, where the actual tenants are managed by the users.

Roles & permissions

azuma doa provides pre-defined roles & permissions that can be extended by adding application roles / permission.

The following pre-defined roles are implemented:

• doa: Admin
• doa: Contributor
• doa: Reader
• doa: External

See the assigned permissions in .

Predefined Scopes: Authorization Code

Scope	Flow	Description
opendid	authorization_code	Returns the sub claim (unique id of the user) as well as default openid claims.
profile	authorization_code	Returns the basic profile information, including name, family_name, given_name, middle_name, language. See tokens for more details.
email	authorization_code	Returns the email and the email_verified claim. The email_verified is set to true if the email has been verified.
offline_access	authorization_code	See - oAuth2 specification.
offline	authorization_code	Synonym for offline_access.
tenant_ids	authorization_code	Adds tenant_ids to access token and tenant_ids/root_tenant_ids/default_tenant_id to id token. For tenant_ids all tenants (Root + Departments) are included. For root_tenant_ids only Root tenants are included. See tokens for more details.
tenants	authorization_code	Adds tenants to id token. This includes the tenant hierarchy (but only tenants the user has access to). See tokens for more details.
permissions_core	authorization_code	Adds core permissions as permissions_core to id token. See tokens for more details.
permissions_app	authorization_code	Adds permissions of your application to access token and id token as permissions_app. See tokens for more details.
licenses	authorization_code	Adds licenses to access token and id token.

Predefined Scopes: Client Credentials

| tenant_idadmin | client_credentials | allows to access the API for tenant relevant operations via client. Example for scope with tenant ID '192f01b3-eee4-4eeb-9854-11303eaa4890': 192f01b3-eee4-4eeb-9854-11303eaa4890_admin | | application_short_keyadmin | client_credentials | allows to access the API for application relevant operations via client. Example for scope with application short key 'tstapp': tstapp_admin |

The Health Industries IDP

azuma doa brings along several features that were developed specifically for solutions in digital health. More features are already in planned. (see roadmap)

Multi-tenancy with overarching hierarchies

Users may belong to several different organizational units with different roles& permissions.

Example

Dr. med. Erich Mustermann may fill out the admin role in his own practice while also working in another clinic/hospital where he has a rolewith limited permissions. Erich may also be a patient in a different context without ever having to change his account.

End-user profiles with profession specific data & verification

azuma doa brings along several profiles for health professions like practitioning doctors, nurses and other health professions. Once they register their account with azuma doa they are asked to fill out their profile with profession specific data. Solutions that integrate *azuma doa can then ask the users to share part of their data that they need to provide their services. Additionally it is planned to implement verification processes that allow users to verify their profession/degree.

Example

Dr. med Erich Mustermann is asked to fill in his LANR (Lebenslange Arztnummer) after registering his account as a medical doctor. When using azuma doa to use an E-Rezept app that is also integrated with azuma doa he can approve that app to access his professional data and does not have to enter any data twice.

Vision

Our vision for azuma doa is to become a service that end users will take with them to gain access to a flourishing eco system of digital health solutions. Removing barriers of entry for solution providers and end users alike.

Integration

To start integrating with azuma doa, check out the Gettings Started pages.

Integration concept: Applications

Applications are used to organize the different products that are integrated with azuma doa. Each Development-Tenant can have as many applications as needed.

Each application has

• a name and
• a short key

and defines a set of

• clients,
• roles and
• permissions.

The short key is important to identify the application as well as for the definition of application roles, permissions and scopes. Each application role/permission/scope needs to be prefixed with the short key (lowercase) to create a unique identifier.

caution

The short key is globally unique and can not be modified after the application is created.

Integration concept: Application roles & permissions

Most apps/use cases require a certain set of roles & permissions. azuma doa allows the definition of those roles & permissions within an application.

permission defines an atomic unit identifying an ability to execute a certain functionality. Individual permissions can not be assigned to a user within azuma doa.

role is used to bundle permissions and is assigned to users. A permission can be used within multiple different roles.