SAML 2.0-verificatie saml-2-0-authentication

Leer hoe u eindgebruikers (niet AEM-auteurs) instelt en verifieert op een door u gewenste SAML 2.0 compatibele IDP.

Welke SAML voor AEM as a Cloud Service?

Dankzij SAML 2.0-integratie met AEM Publish (of Preview) kunnen eindgebruikers van een op AEM gebaseerde webervaring zich verifiëren bij een niet-Adobe IDP (Identity Provider) en hebben ze toegang tot AEM als een benoemde, geautoriseerde gebruiker.

Configuratie doorlopen

Deze video doorloopt het opzetten van SAML 2.0 integratie met de publicatieservice van AEM as a Cloud Service en het gebruik 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 publicatie of voorvertoning in AEM. Om de authentificatie van de Auteur van AEM te beheren die en IDP gebruiken, integreert IDP met Adobe IMS.

IDP-certificaat voor iedereen installeren op AEM

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

De Global Trust Store wordt geconfigureerd met het openbare certificaat van IDP voor AEM-auteur, maar aangezien SAML alleen wordt gebruikt in AEM Publish, moet de Global Trust Store worden gerepliceerd naar AEM Publish om het openbare certificaat IDP daar toegankelijk te maken.

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

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

het installeren van AEM openbaar/privé zeer belangrijk 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 voor 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

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

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-verificatieproces start IDP een HTTP POST aan de clientzijde naar het eindpunt van AEM Publish .../saml_login . Als IDP en AEM op verschillende oorsprong publiceren, publiceert AEM de Filter van de Referateur van de Publicatie wordt gevormd via configuratie OSGi om HTTP POSTs van de oorsprong van IDP toe te staan.

AEM publiceert steunt één enkele het filterconfiguratie van de Referateur, zo fusie 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-verificatieproces start IDP een HTTP POST aan de clientzijde naar het eindpunt van AEM Publish .../saml_login . Als IDP en AEM op verschillende gastheren/domeinen publiceren, publiceert AEM 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-aanvraag 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.

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

Na succesvolle authentificatie aan IDP, zal IDP een POST van HTTP terug naar AEM geregistreerde /saml_login eindpunt (gevormd in IDP) orchestreren. Deze HTTP POST aan /saml_login wordt door gebrek geblokkeerd bij Dispatcher, zodat moet het uitdrukkelijk worden toegestaan gebruikend de volgende regel van Dispatcher:

...

# 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.

Dynamisch groepslidmaatschap

Het dynamische Lidmaatschap van de Groep is een eigenschap in Apache Jackrabbit Oakdie de prestaties van groepsevaluatie en levering verhoogt. Deze sectie beschrijft hoe de gebruikers en de groepen worden opgeslagen wanneer deze eigenschap wordt toegelaten en hoe te om de configuratie van de Handler van de Authentificatie van SAML te wijzigen om het voor nieuwe of bestaande milieu's toe te laten.

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"
  ],
  ...
}

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

Zoals in de vorige sectie wordt uitgelegd, wijkt de indeling van externe gebruikers en groepen enigszins af van de indeling die wordt gebruikt voor lokale gebruikers en groepen. Het is mogelijk om nieuwe ACL voor externe groepen en voorziening nieuwe externe gebruikers te bepalen, of het migratiehulpmiddel te gebruiken zoals hieronder beschreven.

Dynamisch groepslidmaatschap voor bestaande omgevingen met externe gebruikers inschakelen

De SAML-verificatiehandler maakt externe gebruikers wanneer de volgende eigenschap wordt opgegeven: "identitySyncType": "idp" . In dit geval kan dynamisch groepslidmaatschap worden ingeschakeld waarbij deze eigenschap wordt gewijzigd in: "identitySyncType": "idp_dynamic" . Er is geen migratie vereist.

Automatische migratie naar dynamisch groepslidmaatschap voor bestaande omgevingen met lokale gebruikers

De SAML-verificatiehandler maakt lokale gebruikers wanneer de volgende eigenschap wordt opgegeven: "identitySyncType": "default" . Dit is ook de standaardwaarde wanneer de eigenschap niet wordt opgegeven. In deze sectie beschrijven we de stappen die worden uitgevoerd door de automatische migratieprocedure.

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 de eigenschap rep:externalPrincipalNames

Automatische migratie naar dynamisch groepslidmaatschap configureren

{
  "idpIdentifier": "<value of IDP Identifier (idpIdentifier)" property from the "com.adobe.granite.auth.saml.SamlAuthenticationHandler" configuration to be migrated>"
}

Als u meerdere SAML-configuraties wilt migreren, moeten er meerdere OSGi-fabrieksconfiguraties voor com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration worden gemaakt. Elke configuratie geeft een idpIdentifier op die moet worden gemigreerd.

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 Web-pagina van de Plaats van AEM 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 aanmeldingsknop kan saml_request_path bijvoorbeeld instellen op verschillende AEM-pagina's, op basis van de context van de knop. Dit is de plaats waar de gebruiker naar SAML-verificatie is gegaan.

Beveiligd in cache plaatsen tijdens gebruik van SAML

Op de AEM-publicatie-instantie worden de meeste pagina's doorgaans in cache geplaatst. Nochtans, voor SAML-Beschermde wegen, zou caching of moeten worden onbruikbaar gemaakt of beveiligd caching toegelaten gebruikend de configuratie auth_checker. Voor meer informatie, gelieve te verwijzen naar de details hierworden verstrekt

Houd er rekening mee dat als u beveiligde paden in de cache plaatst zonder de AUth_checker in te schakelen, dit onvoorspelbaar gedrag kan veroorzaken.

GET-verzoek

SAML-verificatie kan worden aangeroepen door een HTTP GET-aanvraag in de volgende indeling te maken:

HTTP GET /system/sling/login

en het verstrekken van vraagparameters:

Deze HTML-koppeling activeert bijvoorbeeld de SAML-aanmeldstroom en als de gebruiker hiermee slaagt, gaat u 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>

POST-verzoek

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

HTTP POST /system/sling/login

en het verstrekken van de formuliergegevens:

Deze HTML-knop gebruikt bijvoorbeeld een HTTP POST om de SAML-aanmeldstroom te activeren en neem de gebruiker naar /content/wknd/us/en/protected/page.html wanneer dit lukt. 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 GET- als POST-methoden vereisen clienttoegang tot eindpunten van AEM /system/sling/login en moeten daarom via AEM Dispatcher 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" }