Erstmalige Verwendung der Applikation für neue User

Im Rahmen des Zugriffsantrags kann ein Nutzer für eine dedizierte Identität den Zugriff auf eine Fachapplikation beantragen. Sofern diese Identität im entsprechenden Accessmandanten noch nicht vorhanden ist, wird diese Identität dort angelegt und auf die Identität im entsprechenden IdP referenziert. Im Rahmen des Zugriffsantrags werden der Identität die für seine Arbeit in der Applikation benötigten Rollen zugewiesen.

Varianten des Zugriffantrages:

Zugriffsantrag automatisiert ohne Interaktion (Silent Mode)
Im besten Fall merken Sie vom Zugriffsantrag gar nichts. Dann nämlich, wenn die Rollen der Applikation automatisiert vergeben werden und der Setup so konfiguriert ist, dass der sogenannte «Silent Mode» zum Zug kommt. Damit werden die Rollen im Hintergrund ohne Interaktion mit Ihnen, just in Time vergeben. → UseCase: Keine Autorisierung ist für den Zugang zum öffentlichen Bereich der Applikation vorgesehen.

Die Steuerung der Applikationszugriffe erfolgt dabei über die grob- oder feingranularen Rollen. Wenn in der Applikation keine Rollen definiert werden, wird die grobgranulare Rolle "ALLOW" für den Applikationszugriff erfasst.

Zugriffsantrag mit anschliessendem Freigabeprozess (Benutzer Zugriffsantrag -> BVA)
Bei Zugriffsantrag mit anschliessendem Freigabeprozess werden die Rollen nicht automatisiert vergeben. Der Antrag wird an einen Berechtigungsverantwortlichen gesandt, welcher entweder die notwendigen Informationen zur Berechtigungsvergabe bereits hat oder die dazu notwendigen Abklärungen macht und sich ggf. mit dem Antragsteller in Verbindung setzt. → UseCase: Erstmaliger Zugang zu der Applikation wird über den Berechtigungsprozess freigegeben.

Der Applikationszugriff muss dabei über einen Benutzer Zugriffsantrag an den zuständigen BVA (Benutzerverwalter Applikation) erfolgen.

IDM Rollen & Zugriffsvergaben IDM ist das . . .

Einladung zentral in der Verantwortung des Fachs (BVA -> Benutzer Onboarding-Code)
Dem Benutzer wird nach der zentralen Erfassung durch einen BVA automatisch via eIAM per E-Mail oder manuell über einen anderen Versandkanal ein einmalig verwendbarer Code (sogenannter Onboarding-Code) zugestellt. Login (oder Selbstregistrierung, falls noch keine elektronische Identität vorhanden) mit anschliessender Eingabe des Onboardingcodes; daraus folgt die sofortige Verfügbarkeit der Zielapplikation. Die Einladungen werden über das delegierte Management generiert. → UseCase: Gezielte Benutzer können im Voraus berechtigt werden und über einen Onboarding Link eingeladen werden. Individuelle Berechtigungen können damit pro Benutzer gesetzt werden.

Delegiertes Management Sollten Sie Fragen oder Anliegen . . .

Das Zurücksetzen des Onboardings, für bereits onboardete Benutzer, kann ebenfalls im Admin-Portal durchgeführt werden.

: Feature: reset onboarding

Einladung dezentral in der Verantwortung von Organisationseinheiten/Firmen ausserhalb des Fachs
Beim delegierten Management geht es prinzipiell darum, dass nicht der Berechtigungsverantwortliche eines Amtes BVA Berechtigungen vergibt, sondern jemand anderes (vgl. dazu eIAM Leistung 6 und das eIAM-Video bei Minute 11). Dabei stehen Ihnen folgende Benutzer Onboarding Möglichkeiten zur Verfügung:
- Onboarding-Code: eIAM sendet der eingeladenen Person eine E-Mail mit einem Einladungstext und Onboardingcode. Die eingeladene Person löst den Onboarding-Code unter Verwendung einer adäquaten elektronischen Identität ihrer Wahl einmalig ein, somit ist diese elektronische Identität über eIAM mit der Zielapplikation verbunden.
- People Picker: Mit dem People Picker können bereits bestehende eIAM Identitäten im Enterprise Kontext gesucht, direkt im Access Mandant onboarded und anschliessend durch den delegierten Manager autorisiert werden. Ohne dass dafür ein Einladungsprozess notwendig ist.
- Bulk-Onboarding: Möglichkeit ein Massen-Onboarding der Benutzer durchzuführen inkl. Vergabe der DelegAdmin IDM-Rollen für die Verwaltung der Berechtigungen, Units und der Benutzer.
- Strict-Onboarding: Wenn in den Portal Properties des Access Mandanten "Strict-Onboarding" konfiguriert ist, MUSS der Benutzer beim Onboarding eine mobile Telefonnummer erfassen.
Delegiertes Management Sollten Sie Fragen oder Anliegen . . .
Einladung automatisch ausgelöst durch Prozess in der Fachapplikation über die eIAM-RDM Schnittstelle
eIAM-RDM ermöglicht das Einladen von Benutzern in eIAM mittels einer REST (Representational State Transfer) API. RDM steht für Remote Delegated Management. Beim Delegierten Management geht es prinzipiell darum, dass nicht der Berechtigungsverantwortliche eines Amtes BVA Berechtigungen vergibt, sondern jemand anderes (vgl. dazu eIAM Leistung 6 und das eIAM-Video bei Minute 11). Bei der Verwendung von RDM löst nicht ein Mensch die Einladung in eIAM aus, sondern eine Maschine (Prozess in der Fachapplikation). eIAM sendet der eingeladenen Person eine E-Mail mit einem Einladungstext und Onboardingcode. Die eingeladene Person löst den Onboardingcode unter Verwendung einer adäquaten elektronischen Identität ihrer Wahl einmalig ein, somit ist diese elektronische Identität über eIAM mit der Zielapplikation verbunden.

Der Applikationszugriff erfolgt über einen automatisierten Mailversand mit einmaligem Onboarding-Code an den Benutzer.

API eIAM-RDM eIAM-RDM ermöglicht das Einladen von . . .

Autoprovisioning
Autoprovisioning ermöglicht wie "Silent Mode" (Punkt 1) ein seamless Login für den Benutzer in die Applikation, heisst ohne Access Request. Der Vorteil dieser prestaging Methode ist, dass eine Zielgruppe von Benutzern im Voraus im Access Client erstellt und mit den nötigen Rollen bestückt werden kann. Es erfolgt keine unkontrollierbare Berechtigungsvergabe für eine Applikation, sondern die Berechtigungen werden für die definierte Zielgruppe bereitgestellt und nachgepflegt und dies ohne Access Request während des Logins! Die Gruppe der Benutzer, welche Zugang und Rechte erhalten ist so im Voraus definierbar. → UseCase: Alle Mitarbeiter bekommen Lese Zugriff in Applikation X oder alle Mitarbeiter aus Abteilung X - Auto provisioning wird die Accounts erstellen und die Rollen zuweisen.
Autoprovisioning Ziel des Autoprovisioning ist, dass eine . . .
Kombinationen der oben genannten Varianten 1&2 oder 3/4/5/6
Die verschiedenen Verfahren für die Berechtigungen können beliebig kombiniert werden. Voraussetzung ist die klare Abgrenzung in Benutzergruppen, damit keine Überlappungen der Verfahren für Benutzer entstehen können. z.B. Soll für Mitarbeiter automatisch ein Account im Access Client X erstellt und mit Rollen versehen werden. Für weitere Benutzer welche z.B. CH-LOGIN verwenden, soll die Access Requests mit Bestätigungsprozess angestossen werden. Anstatt den Access Request, kann man hier auch gut den Onboarding Prozess in Kombination verwenden. Weitere Möglichkeiten sind vorstellbar, heisst die Benutzergruppen und deren Abgrenzung muss klar sein, sowie die gewünschten Prozesse für die Berechtigung. Sind diese Punkte klar, kann eine optimale Kombination von Zugriffs-und Bereitstellung der benötigten Berechtigungen konfiguriert werden. Das Consulting Team wird hier gerne weiter beraten.

Authentication Only
Wie der Name schon sagt, handelt es sich beim Pattern "Authentication Only" um den Bezug von reinen Identitäts- und Authentifizierungsinformationen durch die Applikation. Die Applikation verzichtet bei "Authentication Only" auf jegliche Art von Autorisierung und Identitätsbewirtschaftung in eIAM. Dies weil die Applikation gar keine Autorisierung benötigt, oder die Autorisierung komplett selbst (ausserhalb von eIAM) regelt.
Das Pattern bietet sich an für Integrationen, welche nur Authentifizierung durch eIAM benötigen jedoch keine Grobautorisierung und keine Bewirtschaftung von Identitäten in einem eIAM Access Mandanten.
eIAM liefert im Anschluss an die erfolgreiche Authentifizierung des zugreifenden Subjekts als persistenten Identifier die eIAM Verbundidentität des Subjekts im Token. Dies im Gegensatz zu Integrationen mit Autorisierungsleistung, wo als persistenter Identifier die userExtId der Identitätsreferenz im Access Mandant verwendet wird. Dieser Unterschied ist zu beachten für den Fall, dass Applikationen untereinander Daten über das Subjekt austauschen sollen. In diesem Fall soll aufgrund der unterschiedlichen Identifier das Pattern "Authentication Only" nicht verwendet werden.

Mit dieser Form der Integration wird einzig die Authentifizierungsleistung angeboten.

Das Integrationsmuster "Authentication Only" ist verfügbar für elektronische Identitäten der folgenden Identity Provider (IdP):
- CH-LOGIN (inklusive BYOI Bundle)
- FED-LOGIN