Rollout of delegated management

In order to be able to delegate to one or more internal or external organisational units, you open so-called units in eIAM, which represent these organisational units. The units are therefore a structuring of your eIAM access client. For each unit, you invite at least one delegated manager, also in the aforementioned web user interface. The delegated manager can now independently invite and authorise "his" users within his unit. The properties of the unit, i.e. which roles and attributes can be assigned to which target applications in it, are set by you as the unit opener, as well as whether the delegated managers themselves can open and delegate sub-units.

The central feature of delegated management is the aforementioned invitations, i.e. the invitation of delegated managers and the invitation of users by the delegated managers. The invitation procedure has the advantage that users can be created and also authorised before their electronic identity is known. The users receive an onboarding code, e.g. by e-mail, which they will redeem with an adequate electronic identity of their choice; at the moment of redemption, the electronic identity is linked to the user record prepared in the delegated management.

Which electronic identities are adequate is defined by the integration of the controlled target application. If users who cannot be equipped with smartcards from the Federal Administration are the target audience, CH-LOGIN offers the self-regulated, unenlightened variant with one or two login factors (mTAN and Authenticator App) and a verified variant, the latter with a hard crypto token (FIDO security key, Mobile ID) and video identification (VIPS) or the Vasco token as a second factor.

For the use of unverified (self-registered) as well as verified (certified identities) electronic identities in dealings with the Federal Administration, BYOI will become more common in the future, also within the framework of the delegated management of eIAM.

Preparation

Procedure

Project phases of the delegated management rollout

• Project Management
• In a consultation meeting based on an eIAM dossier, the service provider and the service recipient jointly verify whether the delegated management is suitable for the Office's use cases
• During the verification, the electronic eIAM dossier is jointly completed online and/or, if necessary, jointly supplemented and corrected
• Organisational Management
• It must be verified which offices will be involved in a possible rollout of the delegated management. This also includes contact persons in third circles (e.g. companies and cantons)
• Technical management
• It must be verified which contact persons must be involved in the rollout from a technical point of view on the part of the Federal Office applications and with regard to any interface adaptation and migration. This also includes persons at third party suppliers of Federal Office applications
• Functional management
• It has to be verified which persons responsible for Federal Office applications as well as which operating organisations (level 1 to level 3) have to be involved and trained within the framework of the rollout
• It must be verified who must be involved in the rollout planning with regard to end-user training

• Project management
• Due to the manifold tasks and co-ordinations, a project framework is needed which coordinates the whole project of the rollout of the delegated management. The corresponding project structure is to be set up and defined by the Office
• The introduction of delegated management needs a precise timetable depending on the various activities. Depending on whether interfaces are adapted and/or migration aspects are taken into account, the rollout may take weeks to months (e.g. Swissmedic as a pilot took 9 months)
• The project is responsible for ensuring that the technical starting position in terms of business processes is taken into account to an appropriate degree. These can change fundamentally through delegated management and must be documented accordingly. (Example Swissmedic: access with verification and document exchange took 3 days. Through decentralisation with delegated management, the user can be onboarded within 30 minutes without document exchange)
• Organisational management
• The office must define the unit structure and can be guided by your business processes. Both technical and organisational aspects must be taken into account. In principle, there is a master unit for each of the delegated management units, which has the same name as the client
• Due to the client structure of eIAM as a technical framework, dependencies may have to be made beyond a mere application view. In the process, office-wide holistic consolidations can also be envisaged in the project. This should be seen as an opportunity to consolidate heterogeneously grown structures. However, it is also important to define the structure in such a way that it can withstand future requirements and is scalable
• Through delegated management, responsibilities between the office and third parties who take over the delegated management may have to be redefined. It is advisable to consult the respective legal services of the offices within the framework of the project and to have them draw up any contractual adjustments
• Early communication to all stakeholders is a key activity for the success of the project. Due to the broad impact of delegated management, it makes sense to plan communication to all stakeholders throughout the project phase
• Technical management
• The delegated management requires a clean role concept, which defines exactly who needs which authorisations for the delegated management and its support. This role concept must be created. If one already exists, it must be checked for suitability for delegated management and adapted if necessary. It is advisable to examine the possibility of creating business roles as part of the role concept. These can simplify the assignment of roles, as a function-specific bundling can take place. In particular, future new roles are easier to roll out this way, as they can be integrated into standing sets
• For roles with attributes, there are technical interfaces for their delivery, if these do not want to be maintained manually (example Swissmedic with over 3000 medicines). Furthermore, the Federal Office application must be adapted so that it can query and evaluate the information received from eIAM regarding these attributes. Such interfaces are currently not included in the standard offer for delegated management and must always be commissioned and developed separately and as required
• The delegated management is based on the use of CH-LOGIN accounts in the eGov area and Federal Accounts. Offices with existing professional community clients must include in the project a migration of these accounts to CH-LOGIN accounts. The migration steps must be analysed and planned in the project
• Subject management
• The role set is not only based on technical aspects, but also on functional aspects. Therefore, when defining the role concept, close coordination with the functional managers is needed so that a meaningful role structure can be defined. When using attributes on roles, the aspect of data spaces must also be taken into account. This extended dimension of authorisation must be coordinated with the underlying, technical requirements from the business processes
• The training needs of the various stakeholders must be verified and recorded in a training concept. The training courses must be geared to the needs of the office with its specific use cases. Existing training materials can be reused and adapted to the needs of the office
  
• The technical rollout of the delegated management must be planned in detail so that all involved stakeholders have the required level of knowledge for their daily work in good time. A staggered approach makes sense, as does the establishment of a training and/or demo infrastructure on pre-production systems, if necessary

• Project management
• Organisational, technical and functional rollout needs close coordination, which can only be guaranteed by an adequate project organisation
• All aspects must adequately take into account possible delays and other challenges. In particular, additional interface and migration aspects need to be carefully managed
• Organisational management
• When delegating management to third parties (e.g. companies and cantons), it is advisable to clearly regulate tasks, competencies and responsibilities in terms of rights and obligations between the contracting parties in writing. The development of the necessary contractual basis for this is the responsibility of the Office on the basis of the business processes
• It is advisable to communicate through several channels (mailings (newsletters), letters, information events, online publications, etc.). Communication must be recipient-specific. For example, support organisations and delegated managers require different information than the end users and pure users who may be affected by the changeover due to migration steps. The communication must be set up specifically according to the needs of the office and your customers
• Technical management
• Based on the developed unit structures and the role concept, the corresponding data is created in eIAM (IDM) during the implementation phase. Depending on the complexity (greenfield approach, migration, consolidation, etc.), this is done manually or script-based. Staging via the pre-production environments, such as reference and acceptance, allows experience to be gained during the course of the project and minor adaptations and corrections to be made before the go-live in production
• Interfaces must be commissioned to the respective development teams on the part of the business application and eIAM. Sufficient phases for integration and testing must be planned here
• Migrations are usually script-based and are based on the developed migration concept that takes into account the specific features of the office's application integrations
• Functional management
• The initial role assignment according to the role concept can be done manually as well as script-based. For demo and test purposes, manual handling is simple and supports a pragmatic, agile approach. For the final initialisation with roles, an exclusively script-based approach should be chosen to avoid errors
• Existing documentation can be used and adapted for the training. In particular, it is not advisable to create office-specific documentation for handling the CH-LOGIN account, as otherwise the office will have to carry out time-consuming documentation updates in the event of release changes. Only the Federal Office application-specific aspects should be specifically geared to the office. Thus, aspects such as entry point for the Federal Office application or explanation of roles of the Federal Office application and their significance for the delegated managers
• Implement the training in time so that the stakeholders are not hindered in their daily business by the changeover

• Project Management
• It is recommended to organise a feedback session after the rollout has been completed
• The lessons learned are to be recorded and suitable improvement measures for future conversions are to be defined by the BIT. In this way, the Confederation can benefit holistically from the experience gained
• KAIZEN, in the sense of the continuous improvement process, is to be established on the basis of the experiences in daily business. In particular, the support organisations are to be supported in solving problems themselves with a high degree of autonomy
• End-user input should be fed into the release backlog in the form of change requests and improvements, so that continuous improvement of functionality based on customer feedback is possible
• Organisational management
• It is advisable to provide final information after completion of the rollout in the sense of "Do good and talk about it"
• The project has to hand over the performance mandate to the implementing organisations and transfer the tasks to regular operation
• Technical management
• For any technical implementation, such as interfaces and integrations, an official technical acceptance must be given by the service recipient to the service provider. This records the go-live and any subsequent change requests and corrections can only be carried out via corresponding additional orders
• Functional management
• The technical operationalisation ensures that all stakeholders are documented in sufficient form to enable them to manage their daily work
• Responsibilities between service provider and service recipient are clearly defined. This concerns in particular the clear delineation of the tasks of the different support organisations

Initial technical setup

• the initial provision / clean-up of the unit structure
• the initial provisioning / clean-up of the role structure

Initial provision / clean-up of the role structure

Preparation of functional roles

Initial role allocation
Specific roles of delegated management

In order for the delegated administrators to be able to use the functionalities, they must first be assigned the appropriate IDM roles in their user profile.

IDM Roles: Edit Data Space

Once the IDM base roles for Delegated Management have been assigned, they must be configured to the data room to be used.

The defined sample roles that the designated user can/should inherit must be entered here.

On the IDM role 'DelegatedManager_User' it must also be ensured that the captured department (unit) on the profile matches the captured department in the assigned IDM role.