OpenID Connect-autentisering

OpenID Connect (OIDC) erbjuder organisationer ett modernt och säkert sätt att autentisera användare samtidigt som åtkomsten till Windows-applikationer som hostas av GO-Global effektiviseras. Genom att integrera med identitetsleverantörer som Okta, Azure AD eller ADFS kan administratörer centralisera autentiseringen och förbättra inloggningsupplevelsen för användarna – oavsett om de loggar in med lokala Windows-konton, domänkonton eller båda. Denna guide förklarar hur man aktiverar OIDC-autentisering i GO-Global, konfigurerar automatisk inloggning i Windows, matchar identitetsleverantörskonton med Active Directory-användare och hanterar ytterligare inställningar som krävs för smidig åtkomst. Den täcker även avancerade alternativ såsom att anpassa användarnamnsfält, hantera skapande av lokala konton, konfigurera behörigheter och hämta OIDC-tokens programmatiskt.

När en användare har autentiserats via OIDC erbjuder GO-Global administratörer flera alternativ för att automatiskt autentisera användaren i Windows. Om identitetsleverantören till exempel är integrerad med organisationens Active Directory kan GO-Global automatiskt logga in användaren på dennes domänkonto. Om integration med Active Directory däremot inte krävs eller önskas kan GO-Global skapa ett lokalt Windows-konto åt användaren och automatiskt logga in användaren på det kontot. Stöd för enkel inloggning är ett tillval. OpenID Connect-autentisering kommer att vara gråmarkerad (inaktiverad) om inte funktionen har köpts.

‍Så här aktiverar du OpenID Connect-autentisering

Klicka på Verktyg | Värdalternativ.
Klicka på fliken Autentisering.
Aktivera OpenID Connect-autentisering.
Välj ett av följande alternativ, eller inget alls:
- Logga in användare automatiskt på lokala Windows-konton. När denna funktion är aktiverad skapar GO-Global automatiskt ett lokalt användarkonto för användare som inte har ett domänkonto.
- Logga in användare automatiskt på deras domänkonton. När denna funktion är aktiverad försöker GO-Global utföra en S4U-inloggning med hjälp av användarens UPN, som hämtas från OIDC-identitetsleverantören efter en lyckad OpenID Connect-inloggning. En S4U-inloggning i sig ger användarna åtkomst till resurser på GO-Global-värden, men användarna kan inte autentisera sig mot tjänster som körs i nätverket. För att få åtkomst till tjänster som körs i nätverket måste administratörer antingen aktivera begränsad delegering (enligt beskrivningen i Konfigurationskrav för stöd för delegering (artikel) eller aktivera Alternativet för att spara lösenord i cache på värddatorn.
  - Om en applikation som drivs av GO-Global kan köras under ett lokalt konto på GO-Global-värden ska alternativet ”Logga in användare automatiskt på lokala Windows-konton” väljas. Om applikationen däremot kräver åtkomst till resurser som hanteras av Active Directory måste alternativet ”Logga in användare automatiskt på deras domänkonton” väljas. I det senare fallet måste identitetsleverantören vara integrerad med Active Directory så att den kan förse GO-Global med användarens UPN.
  - Om varken ”Logga in användare automatiskt på lokala Windows-konton” eller ”Logga in användare automatiskt på deras domänkonton” är valt, kommer användarna att uppmanas att logga in på Windows enligt vad som anges i de övriga alternativen på fliken ”Autentisering”. Om till exempel både OpenID Connect-autentisering och standardautentisering är aktiverade kommer användarna att uppmanas att logga in två gånger. Först uppmanas de att logga in hos OpenID Connect-identitetsleverantören. Efter att de har autentiserats hos OpenID Connect-identitetsleverantören uppmanas de att ange användarnamn och lösenord för ett Windows-konto.
Skriv in strängen för klient-ID från konfigurationen av din OpenID Connect-server i rutan Klient-ID .
Skriv in strängen för klienthemligheten från konfigurationen av din OpenID Connect-server i rutan för klienthemligheten .
Ange den auktoriserings-URL som används för att autentisera användare mot din OpenID Connect-server i rutan Auktoriserings-URL.
Ange den token-URL som används för att autentisera användare mot din OpenID Connect-server i rutan Token-URL.
I rutan Omdirigerings-URL anger du den URL som identitetsleverantören måste använda för att omdirigera användare tillbaka till GO-Global Host efter att de har autentiserats. Detta bör vara samma bas-URL som användarna använder för att komma åt GO-Global Host, med callback.html tillagt i slutet. Om du till exempel använder en separat webbserver som IIS och TLS inte är aktiverat, skulle återkopplings-URL:en vara http://hostname/goglobal/callback.html. Alternativt, om du använder GO-Globals integrerade webbserver och TLS inte är aktiverat och GO-Global är konfigurerat för att acceptera anslutningar på sin standardport, 491, skulle återkopplings-URL:en vara http://hostname:491/callback.html.
Klicka på OK.

Koppla Active Directory-användare till identitetsleverantörskonton

GO-Global erbjuder flera alternativ för att härleda en användares UPN från uppgifter i ett OIDC-ID-token. Användarkonton måste stämma överens på något av tre sätt mellan Active Directory (AD) och identitetsleverantören.

Det finns tre sätt att åstadkomma detta:

Användarens ursprungliga UPN (User Principal Name) stämmer redan överens med , identitetsleverantörens användarnamn. Till exempel är den lokala AD-domänen example.com och identitetsleverantörens domän är också example.com. Som standard söker GO-Global efter ett giltigt UPN i fälten e-post, UPN, sub och userid i ID-token, i den ordningen. Alternativt kan administratörer ange den anspråk som innehåller UPN via egenskapen OpenIDConnectUserNameField i HostProperties.xml.
Lägg till ett UPN-suffix och använd det i AD-användarnamnen så att AD-UPN:et och identitetsleverantörens UPN:er stämmer överens. Till exempel: den lokala AD-domänen är company.local, men lägg till ett UPN-suffix för användare som heter example.com. Identitetsleverantörens domän är också example.com.
Ställ in användarens AD-e-postattribut så att det stämmer överens med identitetsleverantörens UPN och ändra en inställning i HostProperties.xml. I vissa miljöer finns det ingen uppgift i ID-token som stämmer överens med användarens AD-UPN. I en värdmiljö där kundens identitetsleverantör används kommer till exempel kundens domän (t.ex. customercompany.com) inte att matcha värdmiljöns AD-domän (t.ex. hostedapp.com). Eftersom kundens identitetsleverantör används kommer administratörer av värdmiljön inte att kunna lägga till en anspråk i användarnas OIDC-ID-token som anger AD-UPN.

I situationer som denna kan administratörer konfigurera GO-Global så att det söker upp användarens AD UPN via användarens e-postadress. Detta uppnås genom att ställa in värdet för egenskapen OpenIDConnectUserLookupByEmail i HostProperties.xml till true på alla tillämpliga värdar. När denna egenskap är inställd på true söker GO-Global i Active Directory efter ett användarkonto med ett e-postattribut som matchar OIDC-ID-tokenets e-postanspråk.

Lagring av användarnamn i alternativa fält

Som standard hämtar GO-Global Windows-användarnamnet från det användarprincipnamn (User Principal Name) eller den e-postadress som identitetsleverantören har angett i användarens OpenID Connect-ID-token. Om identitetsleverantören däremot är konfigurerad att lagra användarens Windows-användarnamn i ett annat fält, kan administratörer konfigurera GO-Global att använda det alternativa fältet genom att ange fältets namn i egenskapen OpenIDConnectUserNameField i filen HostProperties.xml.

Så här ställer du in egenskapen OpenIDConnectUserNameField

Stäng av tjänsten för publicering av applikationer.
Öppna %PROGRAMDATA%\GraphOn\GO-Global\HostProperties.xml i en textredigerare.
Leta reda på egenskapen OpenIDConnectUserNameField och ändra värdet till namnet på den anspråksuppgift i användarens OpenID Connect-token som innehåller det användarprincipnamn som GO-Global ska använda för att autentisera användaren i Windows.
Spara filen HostProperties.xml.
Starta om tjänsten för publicering av applikationer.

När alternativet ”Logga in användare automatiskt på lokala Windows-konton” är aktiverat, skapas namnen på de lokala användarkontona utifrån användarens huvudnamn (User Principal Name) eller e-postadressen som erhållits via OpenID Connect-autentiseringen. Eftersom lokala konton inte får innehålla tecknen ”@” eller ”.” ersätts dessa med ”_” respektive ”-”. Till exempel skulle e-postadressen sales@graphon.com omvandlas till sales_graphon-com.

Obs!: Windows har en begränsning på 20 tecken för lokala kontonamn. Om det genererade kontonamnet är längre än 20 tecken, avkortar GO-Global namnet till 20 tecken

Lösenorden för dessa konton består av tecken som slumpmässigt väljs ut från gemener, versaler, siffror och specialtecknen !@#$%& . Längden på det lösenord som GO-Global genererar kommer att motsvara den minsta lösenordslängd som angetts för användarna på datorn, såvida inte minimilängden är mindre än 7. I så fall genererar GO-Global ett lösenord som är 14 tecken längre än kravet på minsta längd. Om datorns minsta lösenordslängd till exempel är 6 kommer GO-Global att generera ett lösenord som är 20 tecken långt, i följande format: 8tw@m4b9Dek#vR76@t6%. Om GO-Global inte kan hämta datorns minsta lösenordslängd kommer det att generera ett lösenord som är 14 tecken långt.

Om kravet på minsta längd ställs in via grupprincip, aktivera grupprincipen på fliken Session Startup i dialogrutan Host Options. Dessa lösenord sparas inte och återanvänds inte. Lösenordet ändras vid varje OpenID Connect-autentisering.

Behörigheter för Windows-applikationer som körs i GO-Global-sessioner hanteras inte av identitetsleverantörer som Okta eller ADFS. De hanteras i Windows eller Active Directory.

Integrering med Active Directory är en funktion hos identitetsleverantören. Active Directory Federated Services (ADFS) integreras automatiskt med Active Directory. Andra identitetsleverantörer tillhandahåller sina egna integrationer. Organisationer som använder en identitetsleverantör har redan konfigurerat detta. Organisationer som just håller på att konfigurera detta måste konsultera sin identitetsleverantörs dokumentation för att få information om hur man konfigurerar detta.

För mer information om Okta, besök: https://help.okta.com/en/prod/Content/Topics/Directory/ad-agent-main.htm.

När du använder Azure, se till att använda URL:erna för OAuth 2.0-auktoriseringsändpunkten (v1) och OAuth 2.0-tokenändpunkten (v1). URL:erna för v2-ändpunkterna fungerar inte.

När du använder ADFS väljer du Serverapplikation när du skapar OIDC-applikationen.

Bevilja standardanvändare rättigheter för att starta och aktivera COM

Som standard ger Windows inte standardanvändare som inte har loggat in interaktivt genom att ange användarnamn och lösenord rätt att starta och aktivera COM-objekt. Detta innebär att program som Windows Utforskaren, som är beroende av COM-gränssnitt, endast kan köras eller fungera korrekt för användare som ingår i gruppen Administratörer när OpenID Connect-autentisering används. När OIDC-autentisering är aktiverad bör du därför bevilja standardanvändare rättigheterna ”Starta” och ”Aktivera” för COM enligt följande:

Kör dcomcnfg.
Gå till Komponenttjänster | Datorer | Den här datorn.
Högerklicka på " Den här datorn " och välj " Egenskaper".
Välj fliken COM-säkerhet.
Under ”Start- och aktiveringsbehörigheter” klickar du på knappen ”Redigera standard... ”.
Klicka på knappen Lägg till . (Obs! Standardbehörigheterna ger fullständiga rättigheter till grupperna INTERACTIVE och Administrators. Det är därför detta fungerar för alla användare som autentiseras via användarnamn och lösenord (INTERACTIVE-användare) och medlemmar i gruppen Administrators när OIDC används.
Lägg till gruppen Domänanvändare.
Markera kryssrutorna för ”Tillåt ” bredvid ”Lokal start ” och ”Lokal aktivering”.
Klicka på OK.
Klicka på OK.

Hämta OIDC-ID-token och åtkomsttoken programmatiskt

Ibland kan det vara användbart för applikationer som körs i en GO-Global-session att kunna hämta de påståenden som finns i OIDC-ID-tokenet och/eller åtkomsttokenet, vilka tillhandahålls av identitetsleverantören när användaren autentiseras. När detta krävs kan applikationsutvecklare lägga till kod i sina applikationer för att hämta dessa token.

För att programmatiskt hämta OIDC-ID-token och åtkomsttoken krävs kod som:

Hämta ett HANDLE till redirector.dll genom att anropa GetModuleHandle()
hämta proceduradressen till två exporterade funktioner genom att anropa GetProcAddress() för ”GetOpenIDConnectIDToken” och ”GetOpenIDConnectAccessToken”
anropa dessa två proceduradresser med parametrarna 0 och NULL för att få fram längden på den teckenbuffert som behövs
allokera teckenbufferten
anropa de två funktionerna igen för att hämta de faktiska token

Exempelkod:

/**
* File: GetOidcIdAndAccessTokens.cpp
*
* Copyright 2025 by GraphOn Corporation
* All rights reserved.
*
* This software is the confidential and proprietary information
* of GraphOn Corporation  ("Confidential Information").  You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with GraphOn.
*/

#include <Windows.h>
#include <stdio.h>

int main()
{
    printf ("GetOidcIdAndAccessTokens\n");

    HMODULE hRedirector = ::GetModuleHandleA ("redirector.dll");
    if (hRedirector)
    {
        typedef unsigned int (WINAPI* fnGetOpenIDConnectToken)(unsigned int, char*);

        fnGetOpenIDConnectToken pfnGetOpenIDConnectIDToken = (fnGetOpenIDConnectToken)::GetProcAddress (hRedirector, "GetOpenIDConnectIDToken");
        if (pfnGetOpenIDConnectIDToken)
        {
            unsigned int length = pfnGetOpenIDConnectIDToken (0, NULL);
            if (length)
            {
                printf ("GetOpenIDConnectIDToken(1) returned OIDC ID token length %d.\n", length);

                char* oidcCustomClaims = NULL;
                try { oidcCustomClaims = new char[length]; }
                catch (...) {}
                if (oidcCustomClaims)
                {
                    length = pfnGetOpenIDConnectIDToken (length, oidcCustomClaims);
                    if (length)
                    {
                        printf ("GetOpenIDConnectIDToken(2) returned OIDC ID token length %d.\n", length);
                        printf ("GetOpenIDConnectIDToken(2) returned OIDC ID token %hs.\n", oidcCustomClaims);
                    }
                    else
                        printf ("ERROR GetOpenIDConnectIDToken(2) returned OIDC ID token length %d\n", length);
                }
                else
                    printf ("ERROR Failed to allocate ID token string length %d\n", length);
            }
            else
                printf ("ERROR GetOpenIDConnectIDToken(1) returned OIDC ID token length %d\n", length);
        }
        else
            printf ("ERROR ::GetProcAddress (hRedirector, \"GetOpenIDConnectIDToken\") failed!\n");

        fnGetOpenIDConnectToken pfnGetOpenIDConnectAccessToken = (fnGetOpenIDConnectToken)::GetProcAddress (hRedirector, "GetOpenIDConnectAccessToken");
        if (pfnGetOpenIDConnectAccessToken)
        {
            unsigned int length = pfnGetOpenIDConnectAccessToken (0, NULL);
            if (length)
            {
                printf ("GetOpenIDConnectAccessToken(1) returned OIDC access token length %d.\n", length);

                char* oidcCustomClaims = NULL;
                try { oidcCustomClaims = new char[length]; }
                catch (...) {}
                if (oidcCustomClaims)
                {
                    length = pfnGetOpenIDConnectAccessToken (length, oidcCustomClaims);
                    if (length)
                    {
                        printf ("GetOpenIDConnectAccessToken(2) returned OIDC access token length %d.\n", length);
                        printf ("GetOpenIDConnectAccessToken(2) returned OIDC access token %hs.\n", oidcCustomClaims);
                    }
                    else
                        printf ("ERROR GetOpenIDConnectAccessToken(2) returned OIDC access token length %d\n", length);
                }
                else
                    printf ("ERROR Failed to allocate access token string length %d\n", length);
            }
            else
                printf ("ERROR GetOpenIDConnectAccessToken(1) returned OIDC access token length %d\n", length);
        }
        else
            printf ("ERROR ::GetProcAddress (hRedirector, \"GetOpenIDConnectAccessToken\") failed!\n");
    }
    else
        printf ("ERROR ::GetModuleHandle (\"redirector.dll\") failed!\n");

    printf ("\nPress Enter to exit.\n");

    ::getchar ();
}

‍

Så här kör du testapplikationerna för GetOidcIdAndAccessTokens

Ladda ner och packa upp filen GetOidcIdAndAccessTokens.zip från https://cdn.graphon.com/portal_resources/Downloads/GetOidcIdAndAccessTokens.zip på en GO-Global-värd där OpenID Connect-autentisering är aktiverad.
Registrera de två testapparna GetOidcIdAndAccessTokens_32bit.exe och GetOidcIdAndAccessTokens_64bit.exe hos GO-Global.
Starta en GO-Global-session.
Kör testapparna under GO-Global-sessionen. OpenID Connect-ID-token och åtkomsttoken visas i ett konsolfönster.

Slutsats

Genom att implementera OpenID Connect-autentisering i GO-Global får administratörer tillgång till kraftfulla verktyg för att samordna identitetshanteringen, minska användarfriktionen och stärka säkerheten i alla hostade applikationer. Genom att välja rätt inloggningsflöde, se till att OIDC-anspråk stämmer överens med Active Directory och tillämpa nödvändiga Windows-behörigheter kan organisationer skapa en smidig autentiseringsupplevelse för både lokala och domänbaserade miljöer. Med möjligheten att anpassa hanteringen av användarnamn och få åtkomst till OIDC-tokens programmatiskt stöder GO-Global även mer avancerade applikationsbehov. Tillsammans ger dessa funktioner administratörer flexibiliteten att integrera moderna identitetslösningar samtidigt som full kompatibilitet med Windows-autentiseringskrav upprätthålls.

Är du en ISV som utforskar molnbaserad applikationsleverans? Kontakta oss för att få veta hur GO-Global kan hjälpa dig att effektivisera programvarutillgången för dina slutanvändare. Eller ladda ner en gratis testversion för att testa själv.

‍

OpenID Connect-autentisering