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, muss wie bei AAD bzw. ADFS vorgegangen werden und in der Datei "appsettings.production.json" Einstellungen hinzugefügt werden. Dieses Protokoll ist sehr variabel und bietet umfassende Einstellungsmöglichkeiten.

In dem nachfolgenden Code Snippet, finden Sie einen Ausschnitt, aus "appsettings.production.json", dass darstellt, wie sie OpenID Connect Provider konfigurieren können.

Das Beispiel zeigt, wie Google und Microsoft (ohne Active Directory) als OpenID Connect Provider verwendet werden können. Die Microsoft Anbindung zeigt außerdem wie ein "custom claim" verwendet werden kann, damit sich bestehende User direkt mit ihrem Microsoft Konto anmelden können, ohne zuerst ihren Account über ihr Profil mit ihrem Microsoft Konto zu verknüpfen (siehe Profil). Wie sie eine entsprechenden "ClientId" und "ClientSecret" sowie die dazugehörige "Authority" kommen, unterscheidet sich je nach Provider.

Wichtig:

• Damit die Provider auch wirklich konfiguriert werden, muss das "OpenIdConnect.Enabled" auf "true" gesetzt werden!
• Nach Änderung der Konfiguration, muss die Applikation neu gestartet werden! (am besten via "stop" und "start" im IIS Manager, "restart" startet oft die Applikation nicht neu!)

Eine Erklärung würde diesen Rahmen sprengen. Wenn Sie Fragen zur Einstellung eines OpenID Connect Providers haben, melden Sie sich unter "office@togethersecure.com".

{
"AllowOpenIdConnectUserMappingByUsername": false, // 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 configured 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.
      }
    ]
  }
}