Login Möglichkeiten

HITGuard unterstützt die Authentication Provider Active Directory (AD), Azure Active Directory (AAD), Active Directory Federation Services (ADFS) und OpenIdProvider.

Active Directory

Das Active Directory ist der einzige Authentication Provider, der zur Laufzeit von HITGuard eingestellt werden kann. Es kann von Administratoren und Experten in den Globalen Einstellungen konfiguriert werden.

Mehr über die Active Directory Konfiguration ist unter "Administration → Globale Einstellungen → LDAP" zu finden.

Azure Active Directory

Um die Authentication Provider AAD oder ADFS zu konfigurieren, muss die Datei "appsettings.production.json" von HITGuard geändert werden. Diese Datei befindet sich im Wurzelverzeichnis des Installationsordners.

In der Sektion AzureAd müssen folgende Einträge an Ihre Azure-App angepasst werden:

"Activated": true,
"Instance": "https://login.microsoftonline.com/",
"HITGuardBaseUrl": "https-Adresse unter der Ihre HITGuard-Instanz erreichbar ist",
"ClientId": "your-clientId-guid",
"TenantId": "your-tententId-guid",
"ClientSecret": "your-tententId-guid",

Single Sign On (SSO)

Ist das AAD nun als Authentication Provider für HITGuard eingerichtet, können sich Benutzer per Single Sign On bei HITGuard anmelden (siehe Abbildung unten).

Voraussetzung ist, dass ein Benutzer in HITGuard existiert, dessen E-Mail-Adresse mit der E-Mail-Adresse, die zur Anmeldung im AAD verwendet wird, übereinstimmt. Denn: Bei der ersten Anmeldung via AAD wird diese verwendet um den AAD-Benutzer mit dem HITGuard-Benutzer zu verbinden. Anschließend kann die E-Mail-Adresse des HITGuard-Benutzers bei Bedarf geändert werden.

Login mit Azure Active Directory konfiguriert

Active Directory Federation Services

Um ein ADFS zu konfigurieren müssen sie ähnlich wie beim Azure Active Directory vorgehen und im "appsettings.production.json" File die Einträge

"MetadataAddress": "https://adfs.yourcompany.com/FederationMetadata/2007-06/FederationMetadata.xml",
"Wtrealm": "https://www.hitguard.com/"

konfigurieren.

Single Sign On (SSO)

Siehe Azure Active Directory (AAD) SSO.

OpenID Connect Provider

Um einen OpenID Connect Provider einzurichten, müssen in der Datei "appsettings.production.json" Änderungen vorgenommen werden. OpenID Connect bietet viele flexible Einstellungen, die je nach Provider angepasst werden können.

Schritte zur Konfiguration

Fügen Sie die Konfiguration in der Datei "appsettings.production.json" hinzu.
Achten Sie darauf, die korrekte "ClientId", "ClientSecret" und "Authority" für jeden Provider zu verwenden. Diese Informationen sind bei jedem OpenID Connect-Provider unterschiedlich und müssen entsprechend den jeweiligen Anbietern konfiguriert werden. Außerdem muss für jeden Provider ein entsprechender einzigartiger "CallbackPath" definiert werden, sowie ein "Name" der für den Login Button verwendet wird.
Setzen Sie die Einstellung `"OpenIdConnect.Enabled"` auf `true`, damit die Provider auch wirklich verwendet werden können.
Wichtig Starten Sie die Anwendung nach der Änderung der Konfiguration neu, indem Sie dies über den IIS Manager tun (idealerweise mit "stop" und "start", da "restart" manchmal die Anwendung nicht vollständig neu startet).

Eine detailliertere Erklärung würde den Rahmen sprengen. Bei weiteren Fragen zur Konfiguration eines OpenID Connect Providers melden Sie sich unter "office@togethersecure.com".

Beispiel-Konfiguration

Im folgenden Beispiel sehen Sie, wie Sie Google und Microsoft (ohne Active Directory) als OpenID Connect Provider konfigurieren können.

Die Microsoft-Integration zeigt außerdem, wie ein "custom claim" verwendet wird, damit sich bestehende Benutzer direkt mit ihrem Microsoft-Konto anmelden können, ohne das Konto mit ihrem Profil zu verknüpfen (siehe Profil).

{
"AllowOpenIdConnectUserMappingByUsername": true, // Allow mapping of OpenIdConnect (or Microsoft Entra ID) user with HITGuard user by OpenIdConnect username with HITGuard user's username when first logging in with OpenIdConnect if activated. (i.e. the OpenIdConnect account gets associated with a hitguard user that has a username, see "HitGuardUserNameClaim" to configure which claim provides the username)
"AllowOpenIdConnectUserMappingByEmail": false, // Allow mapping of OpenIdConnect (or Microsoft Entra ID) user with HITGuard user by OpenIdConnect username with HITGuard user's email when first logging in with OpenIdConnect if activated. (i.e. the OpenIdConnect account gets associated with a hitguard user that has a matching email)
"OpenIdConnect": {
    // If you need to authorize redirect URIs at the Provider, authorize '{HITGuard-domain}/Account/ExternalLoginCallback'
    "Enabled": true,
    "Providers": [
      {
        "Name": "Google", // This name will be displayed to the Users and needs to be unique. Entering 'Google' would for example display as Login with Google
        "Authority": "https://accounts.google.com", // needs to point to the domain where the provider hosts the '/.well-known/openid-configuration', for google this would be e.g. 'https://accounts.google.com'"
        "ClientId": "[Google-Client-Id]", // ClientId for your Application with the Provider
        "ClientSecret": "[Google-Client-Secret]", // ClientSecret for your Application with the Provider
        "CallbackPath": "/signin-oidc-google", // CallbackPath registered with the Provider, must be unique from other providers. Choose any valid path e.g.: '/signin-oidc-google
      },
      {
        "Name": "Microsoft",
        "Authority": "https://login.microsoftonline.com/[Microsoft-Tenatn-Id]/v2.0",
        "ClientId": "[Microsoft-Client-Id]",
        "ClientSecret": "[Microsoft-Client-Secret]",
        "CallbackPath": "/signin-oidc-microsoft",       
        "GetClaimsFromUserInfoEndpoint": true, // If set to true additional claims will be retrieved from the UserInfo endpoint, by default this is false so it will only look at claims in the ID_token, set this to true, if you configure a different "HitGuardUserNameClaim" and do not include it in the ID_token
        "HitGuardUserNameClaim": "hitguard_username", // If AllowOpenIdConnectUserMappingByUsername (toplevel) is set, this property can be used to customize which claim will have the hitgurad username that should be matched. The default of this is the "preferred_username" claim which should be present in the "profile" scope. If this is set to a different value, the Identity Provider needs to be configured to actually include the configured claim in the ID_token (or UserInfo endpoint, which requires "GetClaimsFromUserInfoEndpoint": true) returned to HITGuard.
      }
    ]
  }
}

Hinweise

Die `ClientId` und `ClientSecret` müssen für jedes OpenID Connect-Provider-Konto individuell erstellt werden. Diese erhalten Sie direkt von Google oder Microsoft, wenn Sie eine Anwendung im jeweiligen Developer-Portal registrieren.
Achten Sie darauf, dass die Callback-URL korrekt konfiguriert ist. Diese URL wird beim Authentifizierungsprozess verwendet, um die Antwort vom Provider zu empfangen.
Wenn Sie einen benutzerdefinierten Claim zum Mappen auf Benutzername verwenden wollen, müssen Sie sicherstellen, dass der OpenID Connect Provider diesen Claim über den ID-Token oder den UserInfo-Endpunkt zurückgibt und im "appsetting.production.json" entsprechend konfigurieren.