We want to prepare the responsible person(s) for what to expect
Already during the project planning and conception of a new IT solution, it is very important to deal with the topic of identity and authorisation management in depth. For this purpose, the project usually creates a user and authorisation concept (IAM concept). This concept deals with a variety of questions such as:
Who are the users of my application and in which different roles do they use it?
Are they employees (internal/external) of the Federal Administration? From my own administrative unit or also from other administrative units in the enterprise context?
Are they employees of cantonal administrations in the G2G context?
Are they partners in the G2B context?
Are they citizens in the G2C context?
How is information about users' identities and master data used in my application? Does my application need to have information about users only at the time when that user is using the system or also outside?
Does it need to have information about users in the G2B context?
Does master data about users need to be updated in my application if, for example, a user's name changes and how is this done?
How is the administration of identities and authorisations organised? Through a central organisation as close as possible to the application or decentralised as close as possible to the user and their organisation?
What is the life cycle of identities, their master data and their authorisations for the different user groups in my system?
Should any interested user be able to use the application (public service) or is the application only available to users who fulfil special requirements?
Should a user be able to request access to the application on his own initiative? What does the application, verification, authorisation and rights allocation process look like?
Is there already a base of existing users who will use my application and therefore a migration has to take place?
How complex is the structure of the permissions?
What is the protection requirement?
How should the data in my application be protected with regard to confidentiality and data protection?
Where should the system be operated (on prem, in a cloud)?
In which network zone should my application be operated so that the protection requirements are met?
In the case of a zone for increased protection requirements, how can I ensure that authorised accesses can be made to this zone, but that unauthorised users do not have access to the zone?
Are users accessing the application in their own personal interest or as a representative of an organisation and this representative can change at any time?
and many other issues more...
Identities in eIAM
An authenticating identity points to exactly one federated identity (1:1).
A federated identity points to exactly one identity reference in an access client (1:1).
A federated identity can point to identity references in 0-n access clients (0:n).
An identity reference can have 0-n profiles per Access client (0:n).
A profile can have 0-n roles assigned (0:n).
Through integration with eIAM
The integration of your application with the service eIAM of the IKT-SD IAM V2 of the Federal Administration relieves you as the person responsible in many respects.
Users can use their already existing electronic identities and their means of identity proofing to access your application with them.
Can your application benefit from already existing, secure and user-convenient processes for creating and maintaining their electronic identities. It does not need to implement these itself.
Can your application securely authenticate users via standardised tokens issued by eIAM to recognise the identity of the accessing subject. It does not need to implement a variety of complex authentication procedures itself.
Can your organisation use existing processes for onboarding electronic identities for its application.
Can your organisation use the existing, highly available and professionally operated IAM infrastructure for the maintenance of users and their authorisations.
Can a Reverse Proxy Policy Enforcement Point (RP-PEP) from eIAM provide policy compliant access to their application if required by the zone's policy (e.g. if the application needs to operate in an SZ+ zone for heightened protection needs).
