First-time use of the application for new users

Variants of the access request:

1. Access request automated without interaction (silent mode)
   In the best case, you will not notice the access request at all. This is the case if the roles of the application are assigned automatically and the setup is configured in such a way that the so-called "silent mode" comes into play. This means that the roles are assigned in the background, just in time, without any interaction with a third party. → UseCase: No authorisation is provided for access to the public area of the application. 

   

   Application access is controlled via the coarse- or fine-granular roles. If no roles are defined in the application, the coarse-granular role "ALLOW" is recorded for application access.



2. Access request with subsequent release process (User Access Request -> BVA)
   In the case of an access request followed by a release process, the roles are not assigned automatically. The request is sent to a person responsible for authorisation, who either already has the necessary information for granting authorisation or makes the necessary verifications and, if necessary, contacts the applicant. → UseCase: First-time access to the application is released via the authorisation process.

   

   The application access must be made via a user access request to the responsible BVA (user administrator application).

    
   IDM Roles & Access Assignments


3. Invitation centrally under the responsibility of the office (BVA -> User Onboarding-Code)
   After central registration by a BVA, the user is automatically sent a one-time usable code (onboarding-code) via eIAM by e-mail or manually via another dispatch channel. Login (or self-registration if no electronic identity yet exists) with subsequent entry of the onboarding code will result in immediate access to the target application. The invitations are generated via delegated management. → UseCase: Targeted users can be authorised in advance and invited via an onboarding link. Individual authorisations can thus be set per user.
Delegated Management

Onboarding can also be reset in the admin portal for users who are already onboarded.




Feature: reset onboarding



4. Invitation decentralised in the responsibility of organisational units/companies outside the office.
   Delegated management is basically about the fact that it is not the person responsible for authorisations in an office who issues BVA authorisations, but someone else (see eIAM Service 6 and eIAM-Video at minute 11). The following user onboarding options are available:
   
   • Onboarding code: eIAM sends the invited person an e-mail with an invitation text and an onboarding code. The invited person redeems the onboarding code once using an adequate electronic identity of his or her choice, thus this electronic identity is connected to the target application via eIAM.
   • People Picker: With the People Picker, existing eIAM identities can be searched in the enterprise context, onboarded directly in the access client and then authorised by the delegated manager. Without the need for an invitation process.
     
   • Bulk Onboarding: Possibility to perform a bulk onboarding of users including the assignment of DelegAdmin IDM roles for the management of authorisations, units and users.
   • Strict-Onboarding: If "Strict-Onboarding" is configured in the portal properties of the Access Client, the user MUST enter a mobile phone number during onboarding.

Delegated Management
5. Invitation automatically triggered by process in the business application via the eIAM-RDM interface
   eIAM-RDM allows users to be invited to eIAM via a REST (Representational State Transfer) API. RDM stands for Remote Delegated Management. Delegated management is basically about someone else granting BVA permissions rather than the person in charge of permissions in an office (see eIAM Performance 6: and eIAM-Video at minute 11). When using RDM, it is not a human who triggers the invitation in eIAM, but a machine (process in the business application). eIAM sends the invited person an email with an invitation text and an onboarding code. The invited person redeems the onboarding code once using an adequate electronic identity of their choice, thus this electronic identity is connected to the target application via eIAM.

   

   Application access is via an automated mail dispatch with a one-time onboarding code to the user.

   API eIAM-RDM


6. Autoprovisioning
   Autoprovisioning, like "Silent Mode" (Item 1), enables a seamless login for the user into the application, i.e. without an access request. The advantage of this prestaging method is that a target group of users can be created in advance in the Access Client and assigned the necessary roles. There is no uncontrollable allocation of authorisations for an application, but the authorisations are provided and maintained for the defined target group and this without an access request during login! The group of users who receive access and rights can thus be defined in advance. → UseCase: All employees get read access in application X or all employees from department X - Auto provisioning will create the accounts and assign the roles.
   Autoprovisioning

7. Combinations of above variants 1&2 or 3/4/5/6
   The different procedures for authorisations can be combined in any way. The prerequisite is the clear delimitation in user groups so that no overlapping of the procedures for users can occur. e.g. an account should be automatically created in Access Client X for employees and provided with roles. For other users who use e.g. CH-LOGIN, an Access Request with confirmation process should be triggered. Instead of the Access Request, the OnboardingProcess can also be used in combination. Other possibilities are conceivable, i.e. the user groups and their delimitation must be clear, as well as the desired processes for authorisation. Once these points are clear, an optimal combination of access and provision of the required authorisations can be configured. The consulting team will be happy to provide further advice.


8. Authentication Only
   As the name suggests, the "Authentication Only" pattern involves the application obtaining pure identity and authentication information. With "Authentication Only", the application does without any kind of authorisation and identity management in eIAM. This is because the application does not need any authorisation at all, or manages authorisation completely itself (outside of eIAM).

   The pattern is suitable for integrations that only require authentication by eIAM but no basic authorisation and no management of identities in an eIAM access client.

   Following the successful authentication of the accessing subject, eIAM delivers the eIAM composite identity of the subject in the token as a persistent identifier. This is in contrast to integrations with authorisation service, where the userExtId of the identity reference in the access client is used as the persistent identifier. This difference must be taken into account in the event that applications are to exchange data with each other via the subject. In this case, the "Authentication Only" pattern should not be used because of the different identifiers.

   

   With this form of integration, only the authentication service is offered.

   
   The integration pattern "Authentication Only" is available for electronic identities of the following Identity Providers (IdP):
   • CH-LOGIN (including BYOI Bundle)
   • FED-LOGIN