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 walkthrough

Deze video laat zien hoe je SAML 2.0-integratie met AEM opzet als een Cloud Service Publish-dienst en Okta als IDP gebruikt.

Vereisten

Het volgende is vereist bij het instellen van SAML 2.0-authenticatie:

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 openbaar certificaat installeren op AEM

Het publieke certificaat van de IDP wordt toegevoegd aan de Global Trust Store van AEM en gebruikt om te valideren dat de door de IDP verzonden SAML-assertie geldig is.

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.

Maak authenticatie-service keystore aan authentication-service-keystore

Het aanmaken van een keystore voor authenticatie-service is vereist wanneer de OSGi-configuratieeigenschap ​ van de handleLogoutSAML 2.0-authenticatiehandler is ingesteld of true wanneer AuthnRequest-ondertekening/SAML-assertie-versleuteling vereist is

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 geconfigureerd om AuthnRequests (naar IDP) te ondertekenen en SAML-asserties te versleutelen (naar AEM). Dit wordt bereikt door een privésleutel aan AEM Publish te geven, die de publieke sleutel koppelt aan de IDP.

Zowel AuthnRequest-ondertekening als SAML-assertie-encryptie zijn optioneel, maar beide zijn ingeschakeld, met gebruik van de SAML 2.0-authenticatiehandler OSGi-configuratieeigenschap, useEncryptionwat betekent dat beide of geen van beide gebruikt kunnen worden.

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-authenticatieproces start de IDP een client-side HTTP POST naar het .../saml_login eindpunt van AEM Publish. Als de IDP en AEM Publish op verschillende oorsprong bestaan, wordt het Referrer Filter van AEM Publish via OSGi-configuratie geconfigureerd om HTTP POSTs vanaf de oorsprong van de IDP toe te staan.

AEM Publish ondersteunt één enkele Referrer-filterconfiguratie, dus voeg de SAML-configuratievereisten samen met bestaande configuraties.

OSGi-configuraties per omgeving (config.publish.dev, config.publish.stage, en config.publish.prod) kunnen worden gedefinieerd met specifieke attributen als de allow.hosts (of allow.hosts.regex) variëren tussen omgevingen.

Configureer Cross-Origin Resource Sharing (CORS)

Tijdens het SAML-authenticatieproces start de IDP een client-side HTTP POST naar het .../saml_login eindpunt van AEM Publish. Als de IDP en AEM Publish op verschillende hosts/domeinen bestaan, moet de CRoss-Origin Resource Sharing (CORS)van AEM Publish worden geconfigureerd om HTTP POSTs toe te staan vanaf de host/domein van de IDP.

De header van Origin dit HTTP POST-verzoek heeft meestal een andere waarde dan die van 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 het herschrijven van de URL op de Apache-webserver is geconfigureerd (dispatcher/src/conf.d/rewrites/rewrite.rules), zorg er dan voor dat verzoeken naar de .../saml_login eindpunten niet per ongeluk worden verstoord.

Dynamisch Groepslidmaatschap

Dynamisch groepslidmaatschap is een functie in Apache Jackrabbit Oak die de prestaties van groepsevaluatie en provisioning verhoogt. Deze sectie beschrijft hoe gebruikers en groepen worden opgeslagen wanneer deze functie wordt ingeschakeld en hoe de configuratie van de SAML Authentication Handler kan worden aangepast om deze te activeren voor nieuwe of bestaande omgevingen.

Hoe Dynamic Group Membership voor SAML-gebruikers in nieuwe omgevingen mogelijk maakt

Om de prestaties van groepsevaluatie in nieuwe AEM as Cloud Service-omgevingen aanzienlijk te verbeteren, wordt de activatie van de functie Dynamic Group Membership aanbevolen in nieuwe omgevingen.
Dit is ook een noodzakelijke stap wanneer datasynchronisatie wordt geactiveerd. Meer details hier .
Om dit te doen, voeg je de volgende eigenschap toe aan het OSGI-configuratiebestand:

/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 richt ​ kan 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 ​ migratieeigenschap ​ uitgevoerd.

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

Bij lokale groepen worden de groepsleden opgeslagen in het eikenattribuut: rep:members. Het attribuut bevat de lijst van uid van elk lid van de groep. Meer details zijn hier​ te vinden.
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 lid op in de groepsentry.
Het groepslidmaatschap wordt in plaats daarvan opgeslagen in de gebruikersvermeldingen. Aanvullende documentatie is hier​ te vinden. Dit is bijvoorbeeld de OAK-knoop 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 Dynamisch Groepslidmaatschap voor SAML-gebruikers in bestaande omgevingen in te schakelen

Zoals uitgelegd in de vorige sectie, is het formaat van externe gebruikers en groepen iets anders dan dat van lokale gebruikers en groepen. Het is mogelijk om een nieuwe ACL te definiëren voor externe groepen en nieuwe externe gebruikers te provisioneren, of de migratietool te gebruiken zoals hieronder beschreven.

Dynamisch groepslidmaatschap mogelijk maken voor bestaande omgevingen met externe gebruikers

De SAML-authenticatiehandler creëert externe gebruikers wanneer de volgende eigenschap wordt gespecificeerd: "identitySyncType": "idp". In dit geval kan dynamisch groepslidmaatschap worden ingeschakeld door deze eigenschap aan te passen tot: "identitySyncType": "idp_dynamic". Migratie is niet nodig.

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 bijvoorbeeld vóór de migratie user1 een lokale gebruiker en lid van een lokale groep group1is, zullen na de migratie de volgende wijzigingen plaatsvinden:
user1 wordt een externe gebruiker. Het attribuut rep:externalId wordt aan zijn profiel toegevoegd.
user1 wordt lid van de 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 dan lid is van de lokale groep: group1 hoewel erfelijkheid

Het groepslidmaatschap voor externe groepen wordt opgeslagen in het gebruikersprofiel in de eigenschap rep:externalPrincipalNames

Hoe automatische migratie naar dynamisch groepslidmaatschap te configureren,

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

Om meerdere SAML-configuraties te migreren, moeten meerdere OSGi-fabrieksconfiguraties com.adobe.granite.auth.saml.migration.SamlDynamicGroupMembershipMigration worden aangemaakt, waarbij elk een migratie specificeert idpIdentifier .

Implementatie van SAML-configuratie

De OSGi-configuraties moeten worden toegewijd aan Git en worden uitgezonden naar AEM als een Cloud Service met behulp van 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

Deploy de doel-Cloud Manager Git-branch (in dit voorbeeld, develop), met behulp van een Full Stack deployment pipeline.

Het aanroepen van de SAML-authenticatie

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 kunt u de hier verstrekte details raadplegen

Wees je ervan bewust dat als je beschermde paden cachet zonder de auth_checker in te schakelen, je onvoorspelbaar gedrag kunt ervaren.

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-link activeert bijvoorbeeld de SAML-inlogflow, en na succes brengt de gebruiker naar /content/wknd/us/en/protected/page.html. Deze queryparameters kunnen programmatisch worden ingesteld indien 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

SAML-authenticatie kan worden opgeroepen door een HTTP POST-verzoek te maken in het formaat:

HTTP POST /system/sling/login

en het aanleveren 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.

Laat de benodigde URL-patronen toe op basis van of GET of POST is gebruikt

# 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" }