Wanneer u aangepaste verificatie instelt, hebt u nu betere controle over het verificatieproces en kunt u de aanmeldingservaring aanpassen in de AEM Mobile-app. De aanmeldingservaring voor aangepaste verificatie wordt in de app weergegeven als een schermvullende webweergave die u zelf ontwerpt.

Aangepaste aanmeldingservaringen

De volgende indelingen worden ondersteund:

  • SAML 2.0, waaronder ondersteuning voor MFA/OKTA en Gigya.
  • OAuth 2.0, waaronder aanmelding voor sociaal delen, zoals via Facebook of Gmail.
  • Algemeen, waarbij u uw eigen aanmeldingsgedrag kunt ontwerpen en met uw eigen machtigingsservice kunt werken.

U kunt bijvoorbeeld uw verkoopvertegenwoordiger toestaan zich aan te melden bij de app met een eigen e-mailadres en wachtwoord plus OKTA-verificatie (SAML 2.0). Of u kunt klanten toestaan zich aan te melden bij de app met hun Gmail- of Facebook-account (OAuth 2.0). De app verkrijgt autorisatietokens van deze identiteitsproviders, die u in uw machtigingsservice kunt gebruiken om gebruikers toegang te geven tot inhoud. Door gebruik te maken van de setAuthToken API, kunt u uw verificatiemethoden op verschillende manieren uitbreiden, waaronder het gebruik van meerdere verificatiemethoden binnen dezelfde app.

Algemene identiteitsproviders bieden twee alternatieve verificatiemethoden, waaronder:

  • Een aangepaste interface gebruiken, zoals een HTML-formulier in plaats van standaard om een gebruikersnaam en wachtwoord te vragen.
  • Een aanmeldingservaring creëren binnen een artikel in plaats van via het standaardverificatieproces.

 

Houd er rekening mee dat er nog steeds een machtigingsservice die de v2 Direct Entitlement API's gebruikt, nodig is om gebruikers toegang tot inhoud te verlenen.

Er worden API's geleverd voor de klant om te bepalen of de gebruiker is geverifieerd, de verificatietoken op te halen en de webweergave van de aanmeldingsinterface te starten. Zie Specifieke API's van Cordova voor AEM Mobile gebruiken.

 

Video over aangepaste verificatie

Video over aangepaste verificatie
Video met inleiding tot aangepaste verificatie.

Aangepaste verificatie instellen

Identiteitsproviders worden ingesteld in Hoofdinstellingen en toegepast op een project in Projectinstellingen. U kunt meerdere identiteitsproviders maken op het niveau van het hoofdaccount voor gebruik in projecten.

  1. Stel een machtingsservice in voor gebruik met AEM Mobile.

    Zelfs wanneer u een aangepaste verificatieservice mogelijk maakt, is een machtigingsservice vereist die de v2 Direct Entitlement API's gebruikt om gebruikers toegang te verlenen tot inhoud. Zie Machtiging in AEM Mobile-apps.

  2. Stel een SAML 2.0-, OAuth 2.0- of algemene identiteitsprovider in voor gebruik met AEM Mobile en uw machtigingsservice.

    Google-identiteitsprovider

    Een voorbeeld van het instellen van een Google-identiteitsprovider vindt u in dit PDF-bestand (alleen in het Engels): 

    Downloaden

    Facebook-identiteitsprovider

    Een voorbeeld van het instellen van een Facebook-identiteitsprovider vindt u in dit PDF-bestand (alleen in het Engels):

    Downloaden

    Algemene identiteitsprovider

    Een voorbeeld van het instellen van een algemene identiteitsprovider vindt u in dit PDF-bestand (alleen in het Engels):

    Downloaden

    Bekijk de video over Generic IdP voor informatie over algemene identiteitsproviders (alleen in het Engels).

    Gigya

    U kunt Gigya Customer Identity Management gebruiken als identiteitsprovider, waarmee klanten zich kunnen aanmelden via traditionele methoden en methoden voor diverse sociale media, zoals Facebook, Google en LinkedIn. Een voorbeeld voor het instellen van een Gigya-identiteitsprovider vindt u in dit PDF-bestand (alleen in het Engels):

    Downloaden

    Raadpleeg dit AEM Mobile-artikel in de Gigya-documentatie.

     

    Opmerking:

    De verificatieworkflow van Gigya maakt gebruikt van cookies die zijn ingesteld in de browser van de gebruiker. Gigya-verificatie in AEM Mobile-apps kan mislukken als de app deze cookies detecteert als cookies van derden en ze blokkeert. Als geblokkeerde cookies van derden verhinderen dat de Gigya-workflow de verificatie correct uitvoert, kunt u een oplossing implementeren zoals wordt beschreven in de documentatie van Gigya: Geblokkeerde cookies van derden.

     

    De voorbeeldcode voor de machtigingsservice bevat ondersteuning voor aangepaste verificatie. Zie Een machtigingsservice instellen voor meer informatie.

  3. Meld u aan op de on-demandportal met een account voor een hoofdbeheerder. Klik op Hoofdinstellingen en klik vervolgens op het tabblad Identiteitsproviders.

  4. Klik op het pictogram Identiteitsprovider maken (+) en geef de naam en het type (OAuth 2.0, SAML 2.0 of Algemeen) van de identiteitsprovider op.

  5. Geef de informatie over uw identiteitsprovider op. Zie de beschrijvingen van opties verderop in dit artikel.

  6. Als u een vertrouwensrelatie wilt instellen tussen uw identiteitsprovider en de AEM Mobile-app, kopieert u de waarde Responseindpunt Experience Manager Mobile (SAML 2.0) of Omleidingseindpunt Experience Manager Mobile (OAuth 2.0) en voegt u deze toe aan de configuratie van uw identiteitsprovider.

    Met deze informatie geeft u aan hoe AEM Mobile op de hoogte moet worden gebracht van de resultaten van het verificatieproces. De verificatietoken die geretourneerd wordt door Facebook, is bijvoorbeeld afwijkend van de token in uw machtigingsservice voor die gebruiker. In uw machtigingsservice moet u de verificatietoken voor Facebook toewijzen aan die gebruiker, zodat de machtigingsservice de juiste respons retourneert wanneer AEM Mobile vraagt om machtigingen. De gebruiker wordt vervolgens geautoriseerd om inhoud te bekijken wanneer deze zich aanmeldt.

  7. Ga in de on-demandportal naar Projectinstellingen, bewerk het project en klik op tabblad Toegang. Selecteer 'Aangepaste verificatie inschakelen' en kies de juiste identiteitsprovider die is gemaakt in Hoofdinstellingen.

  8. Ontwikkel een niet-preflight-app en test de instellingen van uw aangepaste verificatie.

SAML 2.0-instellingen

Serviceprovider-id: De waarde die AEM Mobile gebruikt om zichzelf te identificeren wanneer er een verificatieverzoek naar de identiteitsprovider wordt gestuurd. De serviceprovider-id moet worden geregistreerd bij de identiteitsprovider.

Protocolbinding: Met deze instelling wordt de SAML-protocolbinding gedefinieerd die moet worden gebruikt om verificatieverzoeken te verzenden naar de identiteitsprovider. De protocolbindingen POST en REDIRECT worden ondersteund.

Indeling voor naam-id: Als deze instelling is opgegeven, verzoekt de AEM Mobile-machtigingsservice dat de onderwerp-id van de respons de opgegeven indeling gebruikt: Geen, Permanent, Tijdelijk of Niet opgegeven. Gebruik “Niet opgegeven” voor Gigya-identiteitsproviders.

Verificatietokenbron: Deze instelling geeft aan welk gedeelte van de verificatierespons de verificatietoken bevat. Als u Kenmerk gebruikt, moet u de naam van een kenmerk opgeven in de verificatierespons waarin de verificatietoken staat. Als Indeling voor naam-id is ingesteld op Tijdelijk, kunt u Naam-id selecteren.

Verificatie-URL: De URL van de identiteitsprovider waarnaar AEM Mobile het verificatieverzoek moet sturen.

Certificaat met openbare ondertekeningssleutel: Het X509-certificaat van de openbare ondertekeningssleutel van de identiteitsprovider die door AEM Mobile wordt gebruikt om de handtekening van de assertie te valideren.

Vervaltijd standaardsessie: Het aantal seconden dat een aanmeldrespons geldig is als er niet expliciet een duur is opgegeven in de respons. Zodra deze verlopen is, wordt de sessie vernieuwd als dit wordt ondersteund door de identiteitsprovider; anders wordt de gebruiker afgemeld. De standaardwaarde is één uur (3600 s).

Responseindpunt Experience Manager Mobile: De URL die de identiteitsprovider nodig heeft voor het verzenden van de respons voor de assertie. U moet uw identiteitsprovider configureren om deze waarde te gebruiken die door AEM Mobile wordt geleverd.

Certificaat met openbare ondertekeningssleutel voor Experience Manager Mobile: Het X509-certificaat van de openbare ondertekeningssleutel die kan worden gebruikt door de identiteitsprovider om de sleutel indien nodig te coderen in de verificatierespons.

OAuth 2.0-instellingen

Type autorisatieverlening: Deze instelling bepaalt het type autorisatieverlening: Autorisatiecode of Impliciet.

Tokeneindpunt: Deze instelling wordt door AEM Mobile gebruikt om een autorisatiecode of een vernieuwingstoken voor een toegangstoken uit te wisselen. HTTPS wordt sterk aangeraden.

Clientgeheim: AEM Mobile gebruikt deze waarde om zichzelf te verifiëren wanneer er contact wordt opgenomen met het tokeneindpunt. Het clientgeheim dat u opgeeft, moet worden geregistreerd bij de identiteitsprovider.

Vervaltijd standaardsessie: Het aantal seconden dat een aanmeldrespons geldig is als er niet expliciet een duur is opgegeven in de respons. Zodra deze verlopen is, wordt de sessie vernieuwd als dit wordt ondersteund door de identiteitsprovider; anders wordt de gebruiker afgemeld. De standaardwaarde is één uur (3600 s).

Autorisatie-eindpunt: Deze instelling wordt door AEM Mobile gebruikt om de autorisatie te verkrijgen van de identiteitsprovider. HTTPS wordt sterk aangeraden.

Client-id: AEM Mobile gebruikt deze waarde om zichzelf te identificeren wanneer er contact wordt opgenomen met de identiteitsprovider. De client-id moet worden geregistreerd bij de identiteitsprovider.

Bereik toegangstoken: Deze instelling beschrijft het bereik van het toegangsverzoek. Gebruik spaties om meerdere waarden op te geven. Voorbeelden van Facebook: public_profile, email, user_likes, user_friends.

Omleidingseindpunt Experience Manager Mobile: Deze instelling geeft de URL van AEM Mobile op waarnaar de identiteitsprovider moet omleiden nadat het autorisatieproces is voltooid. Deze door AEM Mobile geleverde waarde moet worden geregistreerd bij de identiteitsprovider.

Algemene instellingen

Verificatie-URL: Geef de URL op van de website die de interface voor het aanmeldingsgedrag bevat. Deze website moet informatie bevatten die de verificatietoken doorgeeft aan de machtigingsservice wanneer de gebruiker zich aanmeldt.

Vervaltijd standaardsessie: Het aantal seconden dat een aanmeldrespons geldig is als er niet expliciet een duur is opgegeven in de respons. Zodra deze verlopen is, wordt de sessie vernieuwd als dit wordt ondersteund door de identiteitsprovider; anders wordt de gebruiker afgemeld. De standaardwaarde is één uur (3600 s).

Opmerkingen en aanbevolen werkwijzen voor aangepaste verificatie

  • Nadat u een identiteitsprovider hebt gemaakt in Hoofdinstellingen, kunt u het type identiteitsprovider (SAML 2.0 of OAuth 2.0) niet meer wijzigen. Als u het type wilt wijzigen, moet u een nieuwe identiteitsprovider maken.
  • Wanneer de identiteitsprovider wordt gewijzigd voor een actief project, worden alle gebruikers afgemeld.
  • SAML biedt geen ondersteuning voor vernieuwen. Aan het einde van een sessie moet een gebruiker zich opnieuw aanmelden. Dit geldt ook voor OAuth als de OAuth-provider geen ondersteuning biedt voor vernieuwingstokens.
  • Een gebruiker die afmeldt op een apparaat, wordt niet per definitie afgemeld bij de identiteitsprovider. De identiteitsprovider bepaalt hoe lang de sessie geldig blijft.

Dit werk is gelicentieerd onder de Creative Commons Naamsvermelding/Niet-commercieel/Gelijk delen 3.0 Unported-licentie  De voorwaarden van Creative Commons zijn niet van toepassing op Twitter™- en Facebook-berichten.

Juridische kennisgevingen   |   Online privacybeleid