Rejestracja aplikacji SAML 2.0

Rejestracja aplikacji SAML 2.0 w FoxIDs umożliwia podłączenie aplikacji opartej na SAML 2.0.

SAML (Security Assertion Markup Language) 2.0 to oparty na XML standard uwierzytelniania i autoryzacji, który umożliwia bezpieczny single sign-on (SSO) między identity providerem (IdP) a service providerem (SP). FoxIDs obsługuje zarówno logowanie inicjowane przez SP, jak i przez IdP.

FoxIDs SAML 2.0 application registration

Twoja aplikacja staje się SAML 2.0 Relying Party (RP), a FoxIDs działa jako SAML 2.0 Identity Provider (IdP).

FoxIDs obsługuje SAML 2.0 redirect i post bindings.

FoxIDs przekazuje również login hint z adresu URL żądania SAML Authn, używając parametru zapytania login_hint lub LoginHint, gdy żądanie nie zawiera NameID. Dzięki temu relying parties takie jak Microsoft Entra ID i Okta mogą wstępnie wypełnić identyfikator użytkownika w doświadczeniu logowania FoxIDs.

Rejestracja aplikacji udostępnia metadata SAML 2.0, dzięki czemu aplikacja może odnaleźć SAML 2.0 Identity Providera (IdP).

FoxIDs obsługuje profile SAML 2.0 dla login, logout i single logout. Profil Artifact nie jest obsługiwany.

Metadata SAML 2.0 generowane przez FoxIDs zawierają informacje o logout i single logout tylko wtedy, gdy logout jest skonfigurowany w rejestracji aplikacji SAML 2.0.

FoxIDs obsługuje zarówno certyfikaty RSA, jak i ECDSA jako certyfikaty walidacji podpisu SAML. Walidacja podpisu może akceptować wiele dozwolonych algorytmów, dzięki czemu relying parties mogą podpisywać SAML requests certyfikatami RSA lub ECDSA, a starszy RSA-SHA-1 pozostaje domyślnie wyłączony.

Instrukcje:

Konfiguracja

Tak konfigurujesz aplikację jako SAML 2.0 Relying Party (RP).

Endpointy metadata

  • Metadata IdP: https://foxids.com/tenant-x/environment-y/application-saml-pr1(*)/saml/idpmetadata (zastąp tenant-x, environment-y i application-saml-pr1 własnymi wartościami).
  • Alternatywny pojedynczy endpoint: endpoint Authn zwraca również metadata IdP, gdy jest wywołany metodą GET i bez SAMLRequest. Dzięki temu partnerzy, którzy wymagają jednego adresu URL zarówno do pobierania metadata, jak i do żądań Authn, mogą używać tego samego adresu, na przykład https://foxids.com/tenant-x/environment-y/application-saml-pr1(*)/saml/authn. Gdy ten sam endpoint otrzyma SAML AuthnRequest przez redirect lub post binding, wykona normalny flow logowania.

Rejestracja aplikacji może obsługiwać logowanie przez wiele metod uwierzytelniania przez dodanie nazwy metody uwierzytelniania do adresu URL.

Na przykład https://foxids.com/tenant-x/environment-y/application-saml-pr1(login)/saml/idpmetadata lub /saml/authn kieruje do metody logowania login. Możesz też użyć domyślnej notacji *, aby włączyć logowanie wszystkimi metodami uwierzytelniania.

Poniższy zrzut ekranu pokazuje konfigurację rejestracji aplikacji SAML 2.0 w FoxIDs Control Client. Tutaj konfiguracja jest tworzona na podstawie metadata aplikacji. Wydawane claims są ograniczone do skonfigurowanego zestawu claims, a do wydawania wszystkich claims możesz użyć notacji *.

Więcej opcji konfiguracji będzie dostępnych po kliknięciu Show advanced.

Configure SAML 2.0

Możesz zmienić SAML 2.0 claim collection i implementować claim tasks za pomocą claim transforms i claim tasks. Jeśli tworzysz nowy claim, dodaj claim albo * do listy Issue claims, aby wydać ten claim swojej aplikacji.

Bezpieczeństwo i interoperacyjność

Zaawansowane ustawienia bezpieczeństwa SAML są dostępne po kliknięciu Show advanced w rejestracji aplikacji SAML 2.0.

  • Signature algorithm określa algorytm używany przez FoxIDs podczas podpisywania SAML responses lub assertions. Domyślny jest RSA-SHA-256.
  • Signature validation algorithms to allowlista dla przychodzących podpisanych SAML requests i komunikatów logout od relying party. Domyślna allowlista obejmuje obsługiwane algorytmy RSA-SHA-256/384/512 i ECDSA-SHA-256/384/512 oraz wyklucza RSA-SHA-1.
  • Certyfikaty walidacji podpisu SAML obsługują zarówno certyfikaty RSA, jak i ECDSA, dzięki czemu relying party może używać obu typów certyfikatów podczas podpisywania SAML requests i komunikatów logout.
  • Encrypt authn response szyfruje assertion w SAML authentication response. Po włączeniu tej funkcji należy wskazać relying party encryption certificate, a jeśli wymaga tego interoperacyjność, można wybrać Encryption algorithm i Key encryption algorithm.

Obsługiwane algorytmy data encryption to AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-GCM, AES-192-GCM i AES-256-GCM. AES-256-CBC jest domyślny.

Obsługiwane algorytmy key encryption to RSA 1.5, RSA-OAEP i XML Encryption 1.1 RSA-OAEP. RSA-OAEP jest domyślny. Używaj RSA 1.5 tylko wtedy, gdy wymaga tego starsza relying party.

Wymaganie uwierzytelniania wieloskładnikowego (MFA)

SAML 2.0 Relying Party (RP) może wymagać MFA przez dodanie urn:foxids:mfa do RequestedAuthnContext.AuthnContextClassRef. Możesz połączyć tę wartość z bardziej szczegółowymi wartościami, takimi jak urn:foxids:link. Zobacz żądanie MFA z aplikacji.

Przykładowy kod znajdziesz w AspNetCoreSamlSample oraz w pliku SamlController.cs. Właściwość AuthnContextClassRef można ustawić w metodzie Login w SamlController.cs:

public IActionResult Login(string returnUrl = null)
{
    var binding = new Saml2RedirectBinding();
    binding.SetRelayStateQuery(new Dictionary<string, string>
    {
        { relayStateReturnUrl, returnUrl ?? Url.Content("~/") }
    });

    var saml2AuthnRequest = new Saml2AuthnRequest(saml2Config)
    {
        // To require MFA
        RequestedAuthnContext = new RequestedAuthnContext
        {
            Comparison = AuthnContextComparisonTypes.Exact,
            AuthnContextClassRef = new string[] { "urn:foxids:mfa" },
        }
    };

    return binding.Bind(saml2AuthnRequest).ToActionResult();
}