SAML 2.0-verificatie saml-2-0-authentication

Leer hoe u eindgebruikers (niet AEM auteurs) instelt en verifieert voor een compatibele IDP voor SAML 2.0 van uw keuze.

Welke SAML voor AEM as a Cloud Service?

SAML 2.0 integratie met AEM Publish (of Voorproef), staat eind - gebruikers van een AEM-gebaseerde Webervaring toe om aan niet-Adobe IDP (Identiteitsleverancier) voor authentiek te verklaren, en toegang AEM als genoemde, gemachtigde gebruiker.

Configuratie doorlopen

Deze video doorloopt het opzetten van SAML 2.0 integratie met de dienst van AEM as a Cloud Service Publish, en het gebruiken van Okta als IDP.

Vereisten

Het volgende wordt vereist wanneer vestiging SAML 2.0 authentificatie:

SAML 2.0 wordt alleen ondersteund voor het verifiëren van toepassingen voor AEM Publish of Voorvertoning. Om de authentificatie van AEM Auteur te beheren die en IDP gebruiken, integreert IDP met Adobe IMS.

Openbaar certificaat van IDP installeren op AEM

Het openbare certificaat van IDP wordt toegevoegd aan AEM Globale Opslag van het Vertrouwen, en gebruikt om de bevestiging te bevestigen SAML die door IDP wordt verzonden is geldig.

De globale opslag van het Vertrouwen wordt gevormd met het openbare certificaat van IDP op AEM Auteur, maar aangezien SAML slechts op AEM Publish wordt gebruikt, moet de Globale Opslag van het Vertrouwen aan AEM Publish voor het openbare certificaat worden herhaald IDP om daar toegankelijk te zijn.

Het sleutelarchief voor de verificatieservice maken authentication-service-keystore

Creërend een sleutelarchief voor authentificatie-dienst wordt vereist wanneer SAML 2.0 het configuratiebezit OSGi van de authentificatiemanager handleLogout aan true wordt geplaatst of wanneer AuthnRequest het ondertekenen/SAML- assertieecryptiewordt vereist

Paar AEM openbare/persoonlijke sleutel installeren install-aem-public-private-key-pair

het installeren van het AEM openbare/privé zeer belangrijke paar is facultatief

AEM Publish kan worden gevormd om AuthnRequests (aan IDP) te ondertekenen, en de beweringen van SAML (aan AEM) te coderen. Dit wordt bereikt door een persoonlijke sleutel aan AEM Publish te verstrekken, en het past openbare sleutel aan IDP aan.

Zowel AuthnRequest het ondertekenen, als de bevestiging van SAML encryptie zijn facultatief, nochtans worden zij allebei toegelaten, gebruikend het SAML 2.0 de configuratiebezit OSGi van de authentificatiemanager OSGi useEncryption, betekenend allebei of geen kunnen worden gebruikt.

SAML 2.0-verificatiehandler configureren configure-saml-2-0-authentication-handler

AEM de configuratie van SAML wordt uitgevoerd via de Adobe granite SAML 2.0 Handler van de Authentificatie OSGi configuratie.
De configuratie is een OSGi fabrieksconfiguratie, die één enkele dienst van AEM as a Cloud Service Publish betekent kan veelvoudige SAML configuratie hebben die discrete middelenbomen van de bewaarplaats behandelen; dit is nuttig voor multi-plaats AEM plaatsingen.

OSGi-configuraties per omgeving (config.publish.dev, config.publish.stage en config.publish.prod ) kunnen met specifieke kenmerken worden gedefinieerd als de SAML-configuratie per omgeving verschilt.

Codering gebruiken

Wanneer het coderen van de bevestiging AuthnRequest en SAML, worden de volgende eigenschappen vereist: useEncryption, spPrivateKeyAlias, en keyStorePassword. keyStorePassword bevat een wachtwoord daarom moet de waarde niet in het OSGi configuratiedossier worden opgeslagen, maar eerder ingespoten gebruikend geheime configuratiewaarden

Referentiefilter configureren

Tijdens het SAML authentificatieproces, stelt IDP een cliënt-kant POST van HTTP in werking om het eindpunt van Publish .../saml_login te AEM. Als IDP en AEM Publish op verschillende oorsprong bestaan, AEM de Filter van de Referateur van Publish via configuratie OSGi wordt gevormd om HTTP POSTs van de oorsprong van IDP toe te staan.

AEM Publish steunt één enkele de filterconfiguratie van de Referateur, zo verenigt de configuratievereisten van SAML, met om het even welke bestaande configuraties.

OSGi-configuraties per omgeving (config.publish.dev, config.publish.stage en config.publish.prod ) kunnen met specifieke kenmerken worden gedefinieerd als de allow.hosts (of allow.hosts.regex ) per omgeving verschilt.

Resource Sharing (CORS) voor meerdere bronnen configureren

Tijdens het SAML authentificatieproces, stelt IDP een cliënt-kant POST van HTTP in werking om het eindpunt van Publish .../saml_login te AEM. Als IDP en AEM Publish op verschillende gastheren/domeinen bestaan, AEM Publish CRoss-Origin Middel dat (CORS) deelt moet worden gevormd om HTTP POSTs van de gastheer/het domein van IDP toe te staan.

De header Origin van deze HTTP POST request heeft gewoonlijk een andere waarde dan de AEM Publish host, waardoor CORS-configuratie vereist is.

Bij het testen van SAML-verificatie op de lokale AEM-SDK (localhost:4503), kan de IDP de Origin header instellen op null . Als dat het geval is, voegt u "null" toe aan de lijst alloworigin .

{
    "alloworigin": [
        "$[env:SAML_IDP_ORIGIN;default=https://dev-1234567890.okta.com]",
        "null"
    ],
    "allowedpaths": [
        ".*/saml_login"
    ],
    "supportedmethods": [
        "POST"
    ]
}

OSGi-configuraties per omgeving (config.publish.dev, config.publish.stage en config.publish.prod ) kunnen met specifieke kenmerken worden gedefinieerd als de alloworigin en allowedpaths per omgeving verschillen.

Configureer AEM Dispatcher om SAML HTTP POST's toe te staan

Na succesvolle authentificatie aan IDP, zal IDP een POST van HTTP terug naar AEM geregistreerd /saml_login eindpunt (gevormd in IDP) orchestreren. Deze HTTP-POST naar /saml_login wordt standaard geblokkeerd in Dispatcher, dus moet dit expliciet worden toegestaan met de volgende Dispatcher-regel:

...

# Allow SAML HTTP POST to ../saml_login end points
/0190 { /type "allow" /method "POST" /url "*/saml_login" }

Als URL die bij de Apache webserver herschrijft (dispatcher/src/conf.d/rewrites/rewrite.rules) wordt gevormd, zorg ervoor dat de verzoeken aan de .../saml_login eindpunten niet per ongeluk worden beheerd.

Hoe te om Dynamisch Lidmaatschap van de Groep voor de Gebruikers van SAML in nieuwe milieu's toe te laten

Om de prestaties van de groepsevaluatie in nieuwe AEM as a Cloud Service-omgevingen aanzienlijk te verbeteren, wordt de activering van de functie Dynamic Group Membership aanbevolen in nieuwe omgevingen.
Dit is ook een noodzakelijke stap wanneer de gegevenssynchronisatie wordt geactiveerd. Meer details hier.
Hiervoor voegt u de volgende eigenschap toe aan het configuratiebestand van OSGI:

/apps/example/osgiconfig/config.publish/com.adobe.granite.auth.saml.SamlAuthenticationHandler~example.cfg.json

Met deze configuratie, worden de gebruikers en de groepen gecreeerd als Externe Gebruikers van Oak. In AEM hebben externe gebruikers en groepen de standaardwaarde rep:principalName die wordt samengesteld door [user name];[idp] of [group name];[idp] .
Merk op dat de Lijsten van het Toegangsbeheer (ACL) met PrincipalName van gebruikers of groepen worden geassocieerd.
Wanneer het opstellen van deze configuratie in een bestaande plaatsing waar eerder identitySyncType niet werd gespecificeerd of aan default werd geplaatst, zullen de nieuwe gebruikers en de groepen worden gecreeerd en ACL moet op deze nieuwe gebruikers en groepen worden toegepast. Externe groepen kunnen geen lokale gebruikers bevatten. opnieuw richtkan worden gebruikt om ACL voor Externe groepen van SAML tot stand te brengen, zelfs als zij slechts zullen worden gecreeerd wanneer de gebruiker login zal uitvoeren.
Om dit refactoring op ACL te vermijden, is een standaard migratieeigenschapuitgevoerd.

Hoe de lidmaatschappen in lokale en externe groepen met dynamisch groepslidmaatschap worden opgeslagen

In lokale groepen worden de groepsleden opgeslagen in het oak-kenmerk: rep:members . Het attribuut bevat de lijst van uid van elk lid van de groep. De extra details kunnen hierworden gevonden.
Voorbeeld:

{
  "jcr:primaryType": "rep:Group",
  "rep:principalName": "operators",
  "rep:managedByIdp": "SAML",
  "rep:members": [
    "635afa1c-beeb-3262-83c4-38ea31e5549e",
    "5e496093-feb6-37e9-a2a1-7c87b1cec4b0",
    ...
  ],
   ...
}

Externe groepen met dynamisch groepslidmaatschap slaan geen leden op in het groepsitem.
Het groepslidmaatschap wordt in plaats daarvan opgeslagen in de gebruikersingangen. De extra documentatie kan hierworden gevonden. Dit is bijvoorbeeld het OAK-knooppunt voor de groep:

{
  "jcr:primaryType": "rep:Group",
  "jcr:mixinTypes": [
    "rep:AccessControllable"
  ],
  "jcr:createdBy": "",
  "jcr:created": "Tue Jul 16 2024 08:58:47 GMT+0000",
  "rep:principalName": "GROUP_1;aem-saml-idp-1",
  "rep:lastSynced": "Tue Jul 16 2024 08:58:47 GMT+0000",
  "jcr:uuid": "d9c6af8a-35c0-3064-899a-59af55455cd0",
  "rep:externalId": "GROUP_1;aem-saml-idp-1",
  "rep:authorizableId": "GROUP_1;aem-saml-idp-1"
}

Dit is de knoop voor een gebruikerslid van die groep:

{
  "jcr:primaryType": "rep:User",
  "jcr:mixinTypes": [
    "rep:AccessControllable"
  ],
  "surname": "Test",
  "rep:principalName": "testUser",
  "rep:externalId": "test;aem-saml-idp-1",
  "rep:authorizableId": "test",
  "rep:externalPrincipalNames": [
    "projects-users;aem-saml-idp-1",
    "GROUP_2;aem-saml-idp-1",
    "GROUP_1;aem-saml-idp-1",
    "operators;aem-saml-idp-1"
  ],
  ...
}

Automatische migratie naar dynamisch groepslidmaatschap voor bestaande omgevingen

Wanneer deze migratie is ingeschakeld, wordt deze uitgevoerd tijdens gebruikersverificatie en bestaat deze uit de volgende stappen:

Als vóór de migratie user1 bijvoorbeeld een lokale gebruiker en een lid van een lokale groep group1 is, worden na de migratie de volgende wijzigingen doorgevoerd:
user1 wordt een externe gebruiker. Het kenmerk rep:externalId wordt toegevoegd aan dit profiel.
user1 wordt lid van externe groep: group1;idp
user1 is geen direct lid meer van de lokale groep: group1
group1;idp is lid van de lokale groep: group1 .
user1 is dan lid van de lokale groep: group1 hoewel overerving

Het groepslidmaatschap voor externe groepen wordt opgeslagen in het gebruikersprofiel in het kenmerk rep:authorizableId

Automatische migratie naar dynamisch groepslidmaatschap configureren

{
  "idpIdentifier": "<vaule of identitySyncType of saml configuration to be migrated>"
}

SAML-configuratie implementeren

De configuraties OSGi moeten aan Git worden geëngageerd en aan AEM as a Cloud Service worden opgesteld gebruikend Cloud Manager.

$ git remote -v
adobe   https://git.cloudmanager.adobe.com/myOrg/myCloudManagerGit/ (fetch)
adobe   https://git.cloudmanager.adobe.com/myOrg/myCloudManagerGit/ (push)
$ git add .
$ git commit -m "SAML 2.0 configurations"
$ git push adobe saml-auth:develop

Implementeer de Cloud Manager Git-doelvertakking (in dit voorbeeld develop ) met behulp van een implementatiepijplijn Volledig stapelen.

De SAML-verificatie aanroepen

De SAML authentificatiestroom kan van een AEM Web-pagina van de Plaats worden aangehaald, door een speciaal gemaakte verbindingen, of een knopen te creëren. De hieronder beschreven parameters kunnen indien nodig via programmacode worden ingesteld, dus een aanmeldknop kan saml_request_path bijvoorbeeld instellen op verschillende AEM pagina's, op basis van de context van de knop.

Verzoek om GET

De authentificatie van SAML kan worden aangehaald door een verzoek van de GET van HTTP in het formaat te creëren:

HTTP GET /system/sling/login

en het verstrekken van vraagparameters:

Deze HTML-koppeling activeert bijvoorbeeld de SAML-aanmeldstroom en neemt de gebruiker met succes naar /content/wknd/us/en/protected/page.html . Deze vraagparameters kunnen programmatic worden geplaatst zoals nodig.

<a href="/system/sling/login?resource=/content/wknd&saml_request_path=/content/wknd/us/en/protected/page.html">
    Log in using SAML
</a>

Aanvraag POST

De authentificatie van SAML kan worden aangehaald door een verzoek van de POST van HTTP in het formaat te creëren:

HTTP POST /system/sling/login

en het verstrekken van de formuliergegevens:

Bijvoorbeeld, zal deze knoop van HTML een POST van HTTP gebruiken om de het login van SAML stroom teweeg te brengen, en wanneer succes, neem de gebruiker aan /content/wknd/us/en/protected/page.html. Deze parameters voor formuliergegevens kunnen zo nodig via programmacode worden ingesteld.

<form action="/system/sling/login" method="POST">
    <input type="hidden" name="resource" value="/content/wknd">
    <input type="hidden" name="saml_request_path" value="/content/wknd/us/en/protected/page.html">
    <input type="submit" value="Log in using SAML">
</form>

Dispatcher-configuratie

Zowel de HTTP-methode voor GET als de HTTP-methode vereisen clienttoegang tot AEM eindpunten van /system/sling/login , zodat deze via AEM Dispatcher moeten worden toegestaan.

De benodigde URL-patronen toestaan op basis van het gebruik van GET of POST

# Allow GET-based SAML authentication invocation
/0191 { /type "allow" /method "GET" /url "/system/sling/login" /query "*" }

# Allow POST-based SAML authentication invocation
/0192 { /type "allow" /method "POST" /url "/system/sling/login" }