Gebruik SAML-identiteiten voor programmatische toegang tot Amazon OpenSearch Service

Klanten van Amazon OpenSearch-service kan al gebruiken Beveiligingsbevestiging opmaaktaal (SAML) naar toegang OpenSearch-dashboards.

Dit bericht schetst twee methoden waarmee programmatische gebruikers nu toegang kunnen krijgen tot OpenSearch met behulp van SAML-identiteiten. Dit is van toepassing op alle identiteitsproviders (IdP's) die SAML 2.0 ondersteunen, inclusief veelvoorkomende providers zoals Active Directory Federation Service (ADFS), Okta, AWS IAM Identiteitscentrum (Opvolger van AWS Single Sign-On), KeyCloak en andere. Hoewel we de methoden schetsen zoals ze betrekking hebben op de OpenSearch-service en AWS Identiteits- en toegangsbeheer (IAM), valt programmatische toegang tot elk van deze individuele providers buiten het bestek van dit bericht. De meeste van deze aanbieders bieden wel een dergelijke voorziening.

Methoden voor eenmalige aanmelding

Wanneer u Single sign-on (SSO) gebruikt, zijn er twee verschillende authenticatiemethoden:

• Identiteitsprovider gestart – Dit is wanneer een gebruiker of een user-agent zich voor het eerst authenticeert met een IdP en een SAML-bevestiging krijgt die de identiteit van de gebruiker vaststelt. Deze bewering wordt vervolgens doorgegeven aan een serviceprovider (SP) die toegang biedt tot een beschermde bron.
• Dienstverlener gestart – Hoewel de IdP-geïnitieerde uitwisseling eenvoudig is, is een meer typische aanmeldingservaring wanneer de beveiligde bron rechtstreeks wordt benaderd. De SP leidt de gebruiker vervolgens door naar de IdP voor authenticatie samen met een SAML-authenticatieverzoek. De IdP reageert met een authenticatiebewering in een SAML-antwoord. Daarna is de SSO-ervaring hetzelfde als die van een door IdP geïnitieerde stroom.

Voor programmatische toegang tot OpenSearch Service is een externe IdP de IdP, en OpenSearch Service en IAM dienen beide als SP's. Om uw IdP naar keuze te configureren als de SAML IdP voor IAM, raadpleegt u IAM SAML-identiteitsproviders maken. Raadpleeg voor het configureren van de OpenSearch-service SAML-authenticatie voor OpenSearch-dashboards.

In de volgende secties schetsen we twee methoden om toegang te krijgen tot de OpenSearch Service API:

Methode 1: gebruik AWS STS

De volgende afbeelding toont de volgorde van oproepen om toegang te krijgen tot de OpenSearch Service API met behulp van AWS STS.

Laten we elke stap in meer detail bekijken.

Stappen 1 en 2

Stappen 1 en 2 variëren afhankelijk van de door u gekozen IdP. Over het algemeen bieden ze meestal een authenticatie-API of sessie-API of een andere vergelijkbare API om de SAML-authenticatiebevestigingsreactie te authenticeren en op te halen. We gebruiken deze SAML-bewering in de volgende stap.

Stappen 3 en 4

Bel de VeronderstelRoleWithSAML AWS STS API om de SAML-bevestiging uit te wisselen voor tijdelijke inloggegevens die zijn gekoppeld aan uw SAML-identiteit. Zie de volgende code:

curl --location 'https://sts.amazonaws.com?
Version=2011-06-15&
Action=AssumeRoleWithSAML&
RoleArn=<ARN of the role being assumed>&
PrincipalArn=<ARN of the IdP integrated with IAM>&
SAMLAssertion=<Base-64 encoded SAML assertion>'

Stap 5

Gebruik de tijdelijke inloggegevens van de laatste stap om onderteken alle API-verzoeken naar de OpenSearch-service. Zorg ook voor de rol die je bij de VeronderstelRoleWithSAML call voldoende toestemming heeft om toegang te krijgen tot de vereiste gegevens in OpenSearch Service. Verwijzen naar Rollen toewijzen aan gebruikers voor meer informatie over het toewijzen van deze rol als een backend-rol. Als extra stap om consistentie te garanderen, kunnen deze AWS STS-rol en elke SAML-groep waarvan de gebruiker deel uitmaakt, worden toegewezen aan dezelfde rol in OpenSearch Service. De volgende code toont een model om deze aanroep te doen:

curl --location ‘<OpenSearch Service domain URL>/_search' --header 'X-Amz-Security-Token: Fwo...==(truncated)' --header 'X-Amz-Date: 20230327T134710Z' --header 'Authorization: AWS4-HMAC-SHA256 Credential=ASI..(truncated)/20230327/us-east-1/es/aws4_request, SignedHeaders=host;x-amz-date;x-amz-security-token, Signature=95eb…(truncated)'

Methode 2: gebruik de consoleproxy van OpenSearch Dashboards

OpenSearch Dashboards heeft een component genaamd a console-proxy die verzoeken kunnen proxyen naar OpenSearch. Hierdoor kunnen OpenSearch-clients dezelfde API-aanroepen in Domain Specific Language (DSL) doen naar deze consoleproxy in plaats van rechtstreeks OpenSearch aan te roepen. De consoleproxy stuurt deze oproepen door naar OpenSearch en reageert terug naar de clients in hetzelfde formaat als OpenSearch.

De volgende afbeelding toont de reeks oproepen die u kunt doen naar de consoleproxy om programmatische toegang te krijgen tot de OpenSearch-service.

Stappen 1 en 2

De eerste twee stappen zijn vergelijkbaar met methode 1 en variëren afhankelijk van de gekozen IdP. In wezen moet u een SAML-authenticatiebevestigingsantwoord van de IdP verkrijgen.

Stappen 3 en 4

Gebruik de SAML-definitie uit de vorige stappen en POST deze naar de Assertion Consumer Service (ACS) URL, _opendistro/_security/saml/acs/idpinitiated, om de bewering in te ruilen voor de security_authentication teken. De volgende code toont de opdrachtregel voor deze stappen:

curl --location ‘<dashboards URL>/_opendistro/_security/saml/acs/idpinitiated' --header 'content-type: application/x-www-form-urlencoded' --data-urlencode ‘SAMLResponse=Base-64 encoded SAML assertion' --data-urlencode 'RelayState=’

Als u de OpenSearch-engine gebruikt, is de dashboard-URL <domain URL>/_dashboards. Als u de Elasticsearch-engine gebruikt, is de dashboard-URL <domain URL>/_plugin/kibana. OpenSearch Dashboards verwerkt dit en reageert met een omleidingsreactie met code 302 en een lege body. De responsheaders bevatten nu ook een cookie met de naam security_authentication, wat het token is dat u bij alle volgende oproepen moet gebruiken.

Stappen 5-8

Gebruik de security_authentication cookie in de API-aanroepen naar de consoleproxy om programmatische API-aanroepen uit te voeren. De volgende code toont een opdrachtregel voor deze stappen:

curl --location ‘<dashboardsURL>/api/console/proxy?path=_search&method=GET' --header 'content-type: application/json' --header 'cookie: security_authentication=Fe26.2**1...(truncated)' --header 'osd-xsrf: true' --data '{ "query": { "match_all": {} }
}’

Zorg ervoor dat u een koptekst opneemt met de naam osd-xsrf : true voor programmatische toegang tot dashboards. Het pad van de consoleproxy is /api/console/proxy voor Elasticsearch-engines versie 6.x en 7.x en OpenSearch-engine versie 1.x en 2.x.

Zorg ervoor dat u, net als bij methode 1, rollen en groepen toewijst die zijn gekoppeld aan een bepaalde SAML-identiteit als de juiste backend-rol met de vereiste machtigingen.

Deze methoden vergelijken

U kunt methode 1 in elk domein gebruiken, ongeacht de engine, zolang fijnmazig toegangscontrole is ingeschakeld. Methode 2 werkt alleen voor domeinen met Elasticsearch-engineversies hoger dan 6.7 en alle OpenSearch-engineversies.

Het OpenSearch Dashboards-proces is over het algemeen bedoeld voor menselijke interacties, die een lagere API-aanroepsnelheid en -volume hebben dan die van programmatische aanroepen. OpenSearch kan aanzienlijk hogere API-aanroepsnelheden en -volumes aan, dus zorg ervoor dat u geen grote hoeveelheden API-aanroepen verzendt met methode 2. Als best practice voor programmatische toegang met SAML-identiteiten raden we waar mogelijk methode 1 aan om prestatieknelpunten te voorkomen.

Conclusie

Beide methoden die in dit bericht worden beschreven, bieden een vergelijkbare stroom om programmatisch toegang te krijgen tot OpenSearch Service met behulp van SAML-identiteiten (een SAML-bevestiging uitwisselen voor een authenticatietoken). AssumeRoleWithSAML is een belangrijke en vrij eenvoudig te gebruiken API die deze toegang mogelijk maakt en is onze aanbevolen methode. Probeer een van OpenSearch Service-labs en start een OpenSearch Service-domein om met deze methoden te experimenteren. Succes!

Over de auteur

Muthu Pitchaimani is een zoekspecialist met Amazon OpenSearch Service. Hij bouwt grootschalige zoekapplicaties en -oplossingen. Muthu is geïnteresseerd in de onderwerpen netwerken en beveiliging en is gevestigd in Austin, Texas.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoAiStream. Web3 gegevensintelligentie. Kennis versterkt. Toegang hier.
• De toekomst slaan met Adryenn Ashley. Toegang hier.
• Koop en verkoop aandelen in PRE-IPO-bedrijven met PREIPO®. Toegang hier.
• Bron: https://aws.amazon.com/blogs/big-data/use-saml-identities-for-programmatic-access-to-amazon-opensearch-service/