2017-11-21 2 views
3

Ich habe mich bemüht, die Verbundauthentifizierung mit Sitecore 9 zu nutzen, indem ich IdentityServer 3 als IDP verwende. Ich bin dem Beispiel gefolgt, das in http://blog.baslijten.com/enable-federated-authentication-and-configure-auth0-as-an-identity-provider-in-sitecore-9-0/ für Auth0 gesehen wurde, und habe das zu IDS3 konvertiert. Aber was ich erlebte, war eine endlose Schleife zwischen dem IDP und Sitecore.Sitecore 9 Federated Authentication mit IdentityServer3, Endlosschleife

Es scheint, dass IdentityServer 3 bei der Authentifizierung zurück zu Sitecore umleitet, wodurch die Authentifizierung nicht in einen Cookie umgewandelt werden kann. Ich bin stattdessen mit einem .nonce Cookie übrig. Sitecore, ohne einen authentifizierten Benutzer zu sehen, leitet weiter zum IDP und dies wird fortgesetzt, bis ich den Prozess stoppe.

Mein IdentityProviderProcessor (mit Dummy-Werten):

using System.Threading.Tasks; 
using Microsoft.Owin.Security.Cookies; 
using Microsoft.Owin.Security.OpenIdConnect; 
using Owin; 
using Sitecore.Diagnostics; 
using Sitecore.Owin.Authentication.Configuration; 
using Sitecore.Owin.Authentication.Pipelines.IdentityProviders; 
using Sitecore.Owin.Authentication.Services; 

namespace xx.xxxx.SC.Foundation.Authentication 
{ 
    public class IdentityProviderProcessor : IdentityProvidersProcessor 
    { 
     public IdentityProviderProcessor(FederatedAuthenticationConfiguration federatedAuthenticationConfiguration) : base(federatedAuthenticationConfiguration) 
     { 

     } 

     /// <summary> 
     /// Identityprovidr name. Has to match the configuration 
     /// </summary> 
     protected override string IdentityProviderName 
     { 
      get { return "ids3"; } 
     } 

     protected override void ProcessCore(IdentityProvidersArgs args) 
     { 
      Assert.ArgumentNotNull(args, "args"); 
      IdentityProvider identityProvider = this.GetIdentityProvider(); 
      string authenticationType = this.GetAuthenticationType(); 

      args.App.UseCookieAuthentication(new CookieAuthenticationOptions 
      { 
       AuthenticationType = "Cookies" 
      }); 

      args.App.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions 
      { 
       Authority = "xxxx", 
       ClientId = "xxxx", 
       Scope = "openid profile xxxx", 
       RedirectUri = "xxxx", 
       ResponseType = "id_token token", 
       SignInAsAuthenticationType = "Cookies", 
       UseTokenLifetime = false, 
       Notifications = new OpenIdConnectAuthenticationNotifications 
       { 
        SecurityTokenValidated = (context) => 
        { 
         var identity = context.AuthenticationTicket.Identity; 

         foreach (Transformation current in identityProvider.Transformations) 
         { 
          current.Transform(identity, new TransformationContext(FederatedAuthenticationConfiguration, identityProvider)); 
         } 

         var virtualUser = Sitecore.Security.Authentication.AuthenticationManager.BuildVirtualUser("xxxx\\[email protected]", true); 

         // You can add roles to the Virtual user 
         virtualUser.Roles.Add(Sitecore.Security.Accounts.Role.FromName("extranet\\MyRole")); 

         // You can even work with the profile if you wish 
         virtualUser.Profile.SetCustomProperty("CustomProperty", "12345"); 
         virtualUser.Profile.Email = "[email protected]"; 
         virtualUser.Profile.Name = "My User"; 

         // Login the virtual user 
         Sitecore.Security.Authentication.AuthenticationManager.LoginVirtualUser(virtualUser); 

         return Task.FromResult(0); 
        }, 
       }, 
      }); 
     } 
    } 
} 

Und meine Config-Datei:

<?xml version="1.0" encoding="utf-8"?> 
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:role="http://www.sitecore.net/xmlconfig/role/"> 
    <sitecore role:require="Standalone or ContentDelivery or ContentManagement"> 

    <pipelines> 
     <owin.identityProviders> 
     <!-- Processors for coniguring providers. Each provider must have its own processor--> 
     <processor type="xx.xxxx.SC.Foundation.Authentication.IdentityProviderProcessor, xx.xxxx.SC.Foundation.Authentication" resolve="true" /> 
     </owin.identityProviders> 
    </pipelines> 

    <federatedAuthentication type="Sitecore.Owin.Authentication.Configuration.FederatedAuthenticationConfiguration, Sitecore.Owin.Authentication"> 
     <!--Provider mappings to sites--> 
     <identityProvidersPerSites hint="list:AddIdentityProvidersPerSites"> 
     <!--The list of providers assigned to all sites--> 
     <mapEntry name="all sites" type="Sitecore.Owin.Authentication.Collections.IdentityProvidersPerSitesMapEntry, Sitecore.Owin.Authentication"> 
      <sites hint="list"> 
      <sites hint="list"> 
       <site>modules_website</site> 
       <site>website</site> 
      </sites> 
      </sites> 
      <identityProviders hint="list:AddIdentityProvider"> 
      <identityProvider ref="federatedAuthentication/identityProviders/identityProvider[@id='ids3']" /> 
      </identityProviders> 
      <externalUserBuilder type="Sitecore.Owin.Authentication.Services.DefaultExternalUserBuilder, Sitecore.Owin.Authentication"> 

      <param desc="isPersistentUser">false</param> 

      </externalUserBuilder> 
     </mapEntry> 

     </identityProvidersPerSites> 

     <!--Definitions of providers--> 
     <identityProviders hint="list:AddIdentityProvider"> 
     <!--Auth0 provider--> 
     <identityProvider id="ids3" type="Sitecore.Owin.Authentication.Configuration.DefaultIdentityProvider, Sitecore.Owin.Authentication"> 
      <param desc="name">$(id)</param> 
      <param desc="domainManager" type="Sitecore.Abstractions.BaseDomainManager" resolve="true" /> 
      <!--This text will be showed for button--> 
      <caption></caption> 
      <icon></icon> 
      <!--Domain name which will be added when create a user--> 
      <domain>sitecore</domain> 
      <!--list of identity transfromations which are applied to the provider when a user signin--> 
      <transformations hint="list:AddTransformation"> 
      <!--SetIdpClaim transformation--> 
      <transformation name="set idp claim" ref="federatedAuthentication/sharedTransformations/setIdpClaim" /> 
      </transformations> 
     </identityProvider> 
     </identityProviders> 
     <sharedTransformations hint="list:AddTransformation"> 
     </sharedTransformations> 
    </federatedAuthentication> 
    </sitecore> 
</configuration> 

Beachten Sie, dass die einzige Art, wie ich dies eine VirtualUser zur Validierung zu schaffen, war vollenden könnte. Angesichts des fast vollständigen Mangels an Dokumentation zu diesem Thema bin ich mir nicht sicher, ob dies ein notwendiger Schritt ist oder ob etwas mit der Art und Weise, wie ich das eingerichtet habe, nicht stimmt.

Im Moment funktioniert der VirtualUser wie ein Champion und wir werden das wahrscheinlich beibehalten. Ich würde gerne wissen, aber ist hier die Erstellung eines VirtualUsers erforderlich oder habe ich etwas falsch gemacht?

Danke für jede Eingabe.

+1

Hattest du Glück dabei? Vyacheslavs Antwort ist richtig, da es einige Konfigurationsfehler behebt, aber es hat mein/unser Problem nicht gelöst. Ich lande auch in einer Schleife mit nur dem Nonce-Cookie. –

Antwort

3

Ich sehe einige Probleme in Ihrer gesamten Konfiguration, aber das wichtigste ist der erste (und die Problemumgehung muss natürlich entfernt werden):

  1. Die Umsetzung des IdentityProvidersProcessor muss enthalten nur ein Middleware-Authentifizierung an externe Anbieter zu konfigurieren, wie UseOpenIdConnectAuthentication oder UseAuth0Authentication oder UseFacebookAuthentication. es darf nicht die Cookie-Authentifizierung konfigurieren, da es bereits für Sie in der Sitecore.Owin.Authentication.config getan wird:

    <pipelines> 
        ... 
        <owin.initialize> 
         ... 
         <processor type="Sitecore.Owin.Authentication.Pipelines.Initialize.CookieAuthentication, Sitecore.Owin.Authentication" 
            resolve="true" patch:before="processor[@method='Authenticate']" /> 
         ... 
        </owin.initialize> 
    </pipelines> 
    

    Hinweis: wenn Sie eines OWIN Cookie Authentifizierungsereignisse zu handhaben müssen, verwenden Sie nur Pipeline owin.cookieAuthentication.*

    Aktionen entsprechen:

    1. Ihre UseCookieAuthentication Middleware entfernen.
    2. Verwenden Sie string authenticationType = this.GetAuthenticationType();, um die SignInAsAuthenticationType-Eigenschaft des Objekts OpenIdConnectAuthenticationOptions festzulegen (die authenticationType Variable ist in Ihrem Code nicht verwendet).
  2. Kein Problem, aber es ist eine Erweiterung Methode im Sitecore.Owin.Authentication.Extensions Namespace existiert, der die ganze foreach Anweisung ersetzen könnte:

    notification.AuthenticationTicket.Identity.ApplyClaimsTransformations(new TransformationContext(this.FederatedAuthenticationConfiguration, identityProvider)); 
    
  3. Sie haben versucht, manuell virtuelle zu bauen Benutzer und authentifizieren sie, aber Sitecore kümmert sich darum, wenn Sie das erste Problem beheben.

    Aktion: ersetzen SecurityTokenValidated Handler mit:

    SecurityTokenValidated = notification => 
    { 
        notification.AuthenticationTicket.Identity 
         .ApplyClaimsTransformations(new TransformationContext(this.FederatedAuthenticationConfiguration, identityProvider)); 
        return Task.CompletedTask; 
    } 
    
  4. Ein anderes "nicht ein Problem, aber ..": es war der Fall für die nicht-RTM Sitecore 9.0 baut, aber Sie jetzt don‘ t müssen die setIdpClaim Transformation für jeden Identitätsanbieter manuell angeben. Alle Umwandlungen, die im Knoten federatedAuthentication/sharedTransformations angegeben sind, werden automatisch für alle Identitätsanbieter ausgeführt.

    Aktion: Entfernen zusätzliche Transformation

    <!--SetIdpClaim transformation--> 
    <transformation name="set idp claim" ref="federatedAuthentication/sharedTransformations/setIdpClaim" /> 
    
  5. Achten Sie darauf, einen geeigneten Wert in der RedirectUri Eigenschaft. Es muss in der RedirectUris-Eigenschaft des entsprechenden IdentityServer3.Core.Models.Client-Objekts dargestellt werden.


Wenn alles wird, Ihr externer Benutzer erfolgt authentifiziert werden, aber es wird noch keine Rollen zugewiesen haben. Der Benutzer hat Rollen zugewiesen, wenn eine der folgenden Bedingungen erfüllt ist:

  • Der Benutzer existiert in der Datenbank und hat dort Rollen zugewiesen.
  • Das ClaimsIdentity-Objekt des Benutzers weist Ansprüche mit dem Typ "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" auf.
  • Die beste Möglichkeit, Rollenansprüche zuzuweisen, ist die Verwendung der Anspruchsumwandlungen.

    Beispiel: davon ausgehen, dass Sie eine Sitecores \ Developer Rolle für all Azure AD-Benutzer zugewiesen werden sollen, die in der Gruppe mit einem Objekt-ID 3e12be6e-58af-479A-a4dc-7a3d5ef61c71 enthalten sind. Der Anspruch Transformation für die AzureAD Identity-Provider wird wie folgt aussehen:

    <transformation name="developer role" type="Sitecore.Owin.Authentication.Services.DefaultTransformation,Sitecore.Owin.Authentication"> 
         <sources hint="raw:AddSource"> 
          <claim name="groups" value="3e12be6e-58af-479a-a4dc-7a3d5ef61c70" /> 
         </sources> 
         <targets hint="raw:AddTarget"> 
          <claim name="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" value="sitecore\Developer " /> 
         </targets> 
        </transformation> 
    

    Wichtiger Hinweis: AzureAD nicht die Gruppenansprüche standardmäßig zurückschicken. Sie müssen den Wert groupMembershipClaims im App-Manifest auf SecurityGroup festlegen.


    Jetzt hat Ihr Benutzer Rollen, aber das Profil ist nicht ausgefüllt. Im Gegensatz zu den Anspruchsumwandlungen wird die Konfiguration der Eigenschaftszuordnungen von allen Identitätsanbietern gemeinsam genutzt. Der Grundgedanke dahinter ist, personalisierte Claim-Transformationen für verschiedene Identity-Provider anzuwenden und die "normalisierte" ClaimsIdentity mit Claim-Typen zu erhalten, die Sie erwarten.

    Zum Beispiel gibt der erste Anbieter Sie Anspruch "zweiten Namen", der zweite gibt "Nachname" und der dritte "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname".Dann schreiben Sie zwei Anspruch Transformationen für Anbieter entsprechen, die „zweiten Namen“ auf „Nachnamen“ Karten und „http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname“ auf „Nachnamen“ sowie:

    in dem Faust-Provider Config Knoten:

    <transformation name="surname" type="Sitecore.Owin.Authentication.Services.DefaultTransformation,Sitecore.Owin.Authentication"> 
         <sources hint="raw:AddSource"> 
          <claim name="second name" /> 
         </sources> 
         <targets hint="raw:AddTarget"> 
          <claim name="surname" /> 
         </targets> 
        </transformation> 
    

    im zweiten Anbieter Config Knoten:

    <transformation name="surname" type="Sitecore.Owin.Authentication.Services.DefaultTransformation,Sitecore.Owin.Authentication"> 
         <sources hint="raw:AddSource"> 
          <claim name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" /> 
         </sources> 
         <targets hint="raw:AddTarget"> 
          <claim name="surname" /> 
         </targets> 
        </transformation> 
    

    Seit jetzt haben Sie eine normalisierte ClaimsIdentity, können Sie eine Eigenschaftszuordnung schreiben:

    <map name="surname" type="Sitecore.Owin.Authentication.Services.DefaultClaimToPropertyMapper, Sitecore.Owin.Authentication" resolve="true"> 
         <data hint="raw:AddData"> 
         <source name="surname" /> 
         <target name="Surname" /> 
         </data> 
        </map> 
    

    Die Benutzerprofildaten konnten mit user.Profile["Surname"] gelesen werden.

    Hinweis: ist es möglich und einfach, benutzerdefinierte Claim-Transformationen und Eigenschaftenzuordnungen zu implementieren, wenn Sie sie benötigen.

    +0

    Vyacheslav - das scheint für mich perfekt zu funktionieren - aber der Benutzer geht auf nachfolgende Anfragen auf Extranet/anonymous zurück ... siehe https://sitecore.stackexchange.com/questions/10450/federated-authentication-with-externalcookie ? noredirect = 1 # Kommentar15898_10450 – Watson

    Verwandte Themen