Logo Zéphyrnet

Accès fédéré à l'éditeur de requêtes Amazon Redshift V2 avec Active Directory Federation Services (AD FS) : partie 3

Date :

Dans le premier article de cette série, Fédérer l'accès à votre cluster Amazon Redshift avec Active Directory Federation Services (AD FS) : Partie 1, vous avez configuré l'authentification basée sur Microsoft Active Directory Federation Services (AD FS) et SAML (Security Assertion Markup Language) et testé la fédération SAML à l'aide d'un navigateur Web.

In Partie 2, vous avez appris à mettre en place un Redshift d'Amazon cluster et utilisez l'authentification fédérée avec AD FS pour vous connecter à partir d'un outil client JDBC SQL.

Dans cet article, nous passons en revue les étapes de configuration Éditeur de requête Amazon Redshift v2 pour travailler avec la fédération AD FS SSO.

Les organisations souhaitent permettre à leurs utilisateurs finaux tels que les analystes de données, les scientifiques des données et les développeurs de bases de données d'utiliser l'éditeur de requête v2 pour accélérer l'analyse en libre-service. L'éditeur de requêtes Amazon Redshift v2 permet aux utilisateurs d'explorer, d'analyser et de collaborer sur des données. Vous pouvez utiliser l'éditeur de requête pour créer des bases de données, des schémas, des tables et charger des données à partir d'Amazon Simple Storage Service (Amazon S3) à l'aide de la commande COPY ou d'un assistant. Vous pouvez parcourir plusieurs bases de données et exécuter des requêtes sur votre entrepôt de données ou lac de données Amazon Redshift, ou exécuter des requêtes fédérées sur des bases de données opérationnelles telles que Amazon Aurora.

Dans cet article, nous montrons comment vous pouvez utiliser votre Active Directory (AD) d'entreprise et le fournisseur d'identité SAML 2.0 AD FS (IdP) pour permettre à vos utilisateurs d'accéder facilement aux clusters Amazon Redshift via l'éditeur de requête v2 en utilisant des noms d'utilisateur d'entreprise sans gérer les utilisateurs de la base de données. et mots de passe. Nous montrons également comment vous pouvez limiter l'accès de vos utilisateurs à utiliser uniquement l'éditeur de requête sans leur donner accès pour effectuer des fonctions d'administration sur le Console de gestion AWS.

Vue d'ensemble de la solution

Après avoir suivi les étapes expliquées dans Partie 1, vous configurez un lien profond pour les utilisateurs fédérés via SAML 2.0 RelayState paramètre dans AD FS. Vous utilisez l'utilisateur que vous avez configuré dans votre AD dans la partie 1 (Bob) pour s'authentifier à l'aide d'AD FS et contrôler l'accès aux objets de la base de données en fonction du groupe auquel l'utilisateur est affecté. Vous testez également si l'utilisateur Bob est intégré aux groupes de bases de données Amazon Redshift tels qu'ils sont contrôlés dans les groupes AD.

À la fin de cet article, vous aurez créé un lien profond unique qui authentifie l'utilisateur Bob à l'aide d'AD FS et les redirige directement vers la console de l'éditeur de requête v2, où ils sont authentifiés à l'aide de l'option SSO de fédération.

Le processus de connexion est le suivant :

  1. L'utilisateur choisit un lien profond qui redirige vers l'IdP pour l'authentification avec les informations sur l'URL de destination (éditeur de requête v2, dans notre cas) intégré dans le RelayState paramètre. L'utilisateur saisit ses informations d'identification sur la page de connexion.
  2. Votre fournisseur d'identité (AD FS dans le cas) vérifie l'identité de l'utilisateur dans votre organisation.
  3. Votre IdP génère une réponse d'authentification SAML qui inclut des assertions qui identifient l'utilisateur et des attributs sur l'utilisateur. L'IdP envoie cette réponse au navigateur de l'utilisateur.
  4. Le navigateur de l'utilisateur est redirigé vers le Authentification unique AWS point de terminaison et publie l'assertion SAML et le RelayState paramètre.
  5. Le point de terminaison appelle le AssumeRoleWithSAML Action d'API pour demander des informations d'identification temporaires au Gestion des identités et des accès AWS (IAM) spécifié dans l'assertion SAML et crée une URL de connexion à la console v2 de l'éditeur de requête qui utilise ces informations d'identification. Le rôle IAM fait confiance à l'entité de fédération SAML et dispose également d'une stratégie qui a accès à l'éditeur de requête V2. Si la réponse d'authentification SAML inclut des attributs qui correspondent à plusieurs rôles IAM, l'utilisateur est d'abord invité à choisir le rôle à utiliser pour accéder à la console de l'éditeur de requête v2. L'URL de connexion est celle spécifiée par le RelayState paramètre.
  6. AWS renvoie l'URL de connexion au navigateur de l'utilisateur en tant que redirection.
  7. Le navigateur de l'utilisateur est redirigé vers la console de l'éditeur de requêtes Amazon Redshift v2 définie par le RelayState paramètre.

Le schéma suivant illustre ce flux.

Dans cet article, nous vous expliquons les étapes suivantes :

  1. Mettre en place le Sales groupe dans AD et configurer le PrincipalTag règles de revendication dans AD FS.
  2. Mettez à jour les rôles IAM.
  3. Créez l'URL SSO pour authentifier et rediriger les utilisateurs vers la console v2 de l'éditeur de requête Amazon Redshift.
  4. Configurer la base de données Amazon Redshift groupes et les autorisations sur le cluster Amazon Redshift.
  5. Configurez l'éditeur de requête Amazon Redshift v2 pour utiliser l'authentification fédérée avec AD FS pour vous connecter directement à partir de l'interface de l'éditeur de requête.
  6. Interrogez les objets Amazon Redshift pour valider votre autorisation.

Pré-requis

Pour cette procédure pas à pas, effectuez les étapes préalables suivantes :

  1. Créez un cluster Amazon Redshift. Pour obtenir des instructions, reportez-vous à Créer un exemple de cluster Amazon Redshift ou suivez les étapes de Partie 2 de cette série.
  2. Suivez les étapes de Partie 1 pour configurer la fédération SAML avec AD FS :
    1. Configurer un contrôleur de domaine AD à l'aide d'un AWS CloudFormation modèle sur un Windows 2016 Cloud de calcul élastique Amazon (Amazon EC2).
    2. Configurez la fédération dans AD FS.
    3. Configurez AWS en tant que partie de confiance avec AD FS à l'aide d'un fournisseur IAM SAML et de rôles SAML avec une stratégie attachée pour autoriser l'accès au cluster Amazon Redshift.
    4. Configurez les règles de revendication.
    5. Testez l'authentification SAML à l'aide d'un navigateur Web.
  3. Vérifiez que votre fournisseur d'identité prend en charge RelayState et est activé. Si vous utilisez AD FS 2.0, vous devez télécharger et installer soit Mettre à jour le Rollup 3 or Mettre à jour le Rollup 2 de Microsoft pour activer le RelayState paramètre.

Configurer AD et AD FS

Après avoir configuré vos services AD FS et AD en suivant les instructions de Partie 1, vous pouvez configurer le groupe AD et les règles de revendication suivants.

Dans ce post, vous utilisez l'utilisateur Bob pour vous connecter à Amazon Redshift et vérifier si Bob peut accéder au Sales et Marketing schémas sur le cluster Amazon Redshift. Pour créer le sales groupe et assigne l'utilisateur Bob@adfsredshift.com connectez-vous à votre serveur AD FS (machine Amazon EC2) que vous avez créé dans la partie 1 et utilisez l'outil de commande Windows pour exécuter la commande suivante :

dsadd group "cn=RSDB-sales, cn=Users, dc=adfsredshift, dc=com" -members "cn=Bob, cn=Users, dc=adfsredshift, dc=com"

Vous êtes maintenant prêt à créer vos règles de revendication personnalisées : PrincipalTag:RedshiftDbUser et PrincipalTag:RedshiftDbGroup.

Balise principale : RedshiftDbUser

La règle de revendication personnalisée PrincipalTag:RedshiftDbUser est mappé au nom de principal universel dans AD FS. Lorsqu'un utilisateur s'authentifie via SSO fédéré, cette règle de réclamation est mappée au nom d'utilisateur. Si l'utilisateur n'existe pas dans la base de données Amazon Redshift, l'utilisateur est automatiquement créé. L'option de création automatique est accordée via une stratégie IAM attachée au rôle IAM. Le CreateClusterUser l'autorisation permet la création automatique de l'utilisateur (vous configurez cela dans le cadre de la partie 1 en tant que prérequis).

Procédez comme suit pour créer votre règle de revendication personnalisée :

    1. Sur la console de gestion AD FS, choisissez Invoquant Trusts Partie.
    2. Selectionnez Modifier la politique d'émission de réclamation.
    3. Selectionnez Choisissez le type de règle.
    4. Pour Modèle de règle de revendication, choisissez Envoyer des réclamations à l'aide d'une règle personnalisée.
    5. Selectionnez Suivant.
    6. Pour Nom de la règle de revendications, Entrer RedshiftDbUser.
    7. Ajoutez la règle personnalisée suivante :
      c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
       => issue(store = "Active Directory", types = ("https://aws.amazon.com/SAML/Attributes/PrincipalTag:RedshiftDbUser"), query = ";userPrincipalName;{0}", param = c.Value);

    8. Selectionnez Finition.
    9. Capturez les règles de revendication envoyées dans une réponse d'assertion SAML via votre navigateur. Pour obtenir des instructions, reportez-vous à Comment afficher une réponse SAML dans votre navigateur pour le dépannage.

Dans mon exemple, j'utilise l'attribut SAML suivant pour le RedshiftDbUser PrincipalTag:

<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:RedshiftDbUser"> <AttributeValue>bob@adfsredshift.com</AttributeValue>
</Attribute>

Balise principale : RedshiftDbGroup

La règle de revendication personnalisée PrincipalTag:RedshiftDbGroup est construit à partir de groupes AD dont l'utilisateur est membre. Cette règle est mappée aux groupes de bases de données Amazon Redshift. Les groupes AD et les noms de groupe de base de données Amazon Redshift doivent correspondre. JoinGroup l'autorisation définie dans la stratégie IAM permet à l'utilisateur d'assumer un groupe de bases de données et est basée sur la session. Si l'utilisateur est mappé à plusieurs groupes dans le groupe AD, la réponse d'assertion SAML doit envoyer ces groupes dans : des valeurs séparées et non comme des revendications de valeurs multiples. Les étapes suivantes montrent comment envoyer des groupes AD en tant que : valeurs séparées.

Dans cet exemple, l'utilisateur Bob est assigné au marketing et sales groupes. Le code suivant montre comment envoyer plusieurs groupes via la réponse SAML lorsque l'utilisateur se trouve dans plusieurs groupes, et également comment gérer la situation lorsqu'un utilisateur n'existe pas dans un groupe particulier.

  1. Suivez les mêmes étapes que dans la section précédente pour créer la règle Marketing, en utilisant le code suivant pour la règle personnalisée :
    c:[Type == " http://temp/groups", Value =~ "RSDB-Marketing"] => add(Type = " http://temp/marketing", Value = c.Value);

  2. Créer la règle MarketingNotExists en utilisant le code suivant :
    NOT EXISTS([Type == "http://temp/variable", Value =~ "RSDB-marketing"]) => add(Type = "http://temp/marketing", Value = ""); 

  3. Créer la règle sales en utilisant le code suivant :
    c:[Type == " http://temp/groups", Value =~ "RSDB-sales"] => add(Type = " http://temp/marketing", Value = c.Value);

  4. Créer la règle SalesNotExists en utilisant le code suivant :
    NOT EXISTS([Type == "http://temp/variable", Value =~ "RSDB-sales"])
     => add(Type = "http://temp/sales", Value = ""); 

  5. Créer la règle RedshiftDbGroups en utilisant le code suivant :
    c:[Type == "http://temp/marketing"]
     && c2:[Type == "http://temp/sales"]
     => issue(Type = "https://aws.amazon.com/SAML/Attributes/PrincipalTag:RedshiftDbGroups", Value = c.Value + ":" + c2.Value);

La capture d'écran suivante montre la liste des règles que j'ai créées dans mon AD FS. Notez le nombre de règles et l'ordre dans lequel elles sont positionnées. Nous avons créé les règles 6 à 11 dans le cadre de cet article.

Si vous voyez une réponse SAML similaire pour RedshiftDbGroups, ta configuration est bonne :

<Attribute Name="https://redshift.amazon.com/SAML/Attributes/PrincipalTag:RedshiftDbGroups"> <AttributeValue> marketing:sales</AttributeValue>

Si un utilisateur n'existe pas dans l'un des groupes, une valeur vide est transmise à la règle de réclamation. Par exemple, si l'utilisateur bob est supprimé du marketing groupe, la réponse SAML pour PrincipalTag:RedshiftDbGroup serait :sales.

Mettre à jour les rôles IAM

In Partie 1 de cette série, vous avez créé deux rôles IAM : ADFZ-Dev et ADFZ-Production. Ces deux rôles ne sont pas encore configurés avec des autorisations sur l'éditeur de requêtes. Dans cette section, vous mettez à jour ces rôles avec les autorisations de l'éditeur de requêtes.

L'éditeur de requête Amazon Redshift v2 fournit plusieurs stratégies gérées pour accéder à l'éditeur de requête. Pour obtenir la liste de toutes les stratégies gérées, reportez-vous à Configuration de votre compte AWS. Pour ce post, nous joignons le AmazonRedshiftQueryEditorV2ReadSharing stratégie gérée aux rôles.

  1. Sur la console IAM, choisissez Rôles dans le volet de navigation.
  2. Choisissez le rôle ADFZ-Dev.
  3. Selectionnez Ajouter des autorisations et alors Joindre des politiques.
  4. Sous Autres règles d'autorisation, recherchez le AmazonRedshiftQueryEditorV2ReadSharing politique gérée.
  5. Sélectionnez la politique et choisissez Joindre des politiques.
  6. Modifiez les relations d'approbation pour votre rôle et ajoutez sts:TagSession. Pendant que vous êtes dans le rôle, sélectionnez Relations de confiance et cliquez sur Modifier la stratégie d'approbation.Lors de l'utilisation de balises de session, les stratégies d'approbation pour tous les rôles connectés aux balises de transmission IdP doivent avoir le sts:TagSession autorisation. Pour les rôles sans cette autorisation dans la stratégie d'approbation, le AssumeRole l'opération échoue.
  7. Choisissez Stratégie de mise à jour.
  8. Répétez ces étapes pour fixer le AmazonRedshiftQueryEditorV2ReadSharing stratégie gérée au rôle ADFZ-Production.

Limitation de l'accès des utilisateurs uniquement à l'éditeur de requête

Si vous souhaitez limiter les utilisateurs à l'accès à l'éditeur de requête, mettez à jour la politique redshift-marketing que vous avez créé dans le billet de blog de la partie 1 comme ci-dessous.

Remarque: une fois mis à jour, les utilisateurs perdront les privilèges d'administrateur tels que créer un cluster.

Remplacez les paramètres de région, de compte et de cluster. Cette stratégie personnalisée accorde l'accès à Amazon Redshift pour obtenir les informations d'identification du cluster, créer des utilisateurs et permettre aux utilisateurs de rejoindre des groupes.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftClusterPermissions",
            "Effect": "Allow",
            "Action": [
                "redshift:GetClusterCredentials",
                "redshift:CreateClusterUser",
                "redshift:JoinGroup"
            ],
            "Resource": [
                "arn:aws:redshift:<region>:<account>:cluster:<cluster>,
                "arn:aws:redshift:<region>:<account>:dbuser:<cluster>/${aws:PrincipalTag/RedshiftDbUser}",
                "arn:aws:redshift:<region>:<account>:dbgroup:<cluster>/marketing",
                "arn:aws:redshift:<region>:<account>:dbgroup:<cluster>/sales",
                "arn:aws:redshift:<region>:<account>:dbname:<cluster>/${redshift:DBName}"
            ]
        }
    ]
}

Il y a quelques points importants à noter :

  1. L'appartenance au groupe ne dure que pendant la durée de la session utilisateur.
  2. Il n'y a pas de CreateGroup autorisation parce que les groupes doivent être créés manuellement et accordés des privilèges de base de données.

Générer l'URL de destination SSO en tant que console de l'éditeur de requête Amazon Redshift v2

Dans cette étape, vous créez l'URL de connexion pour l'IdP AD FS afin de rediriger les utilisateurs vers la console v2 de l'éditeur de requête Amazon Redshift. Pour obtenir des instructions, reportez-vous à Comment utiliser SAML pour diriger automatiquement les utilisateurs fédérés vers une page AWS Management Console spécifique.

Pour fournir une expérience SSO complète aux utilisateurs finaux, la réponse SAML peut inclure un paramètre facultatif appelé RelayState. Ce paramètre contient l'URL de destination.

Microsoft fournit un outil pour aider à générer ces URL SSO pour AD FS appelé le Générateur d'état de relais AD FS 2.0.

Pour créer cette URL, vous avez besoin de trois informations :

  • Chaîne d'URL du fournisseur d'identité – La chaîne est au format https://ADFSSERVER/adfs/ls/idpinitiatedsignon.aspx. Pour ce poste, nous utilisons https://EC2AMAZ-F9TJOIC.adfsredshift.com/adfs/ls/IdpInitiatedSignOn.aspx.
  • Identifiant de la partie de confiance – Pour AWS, c'est urn:amazon:webservices.
  • État du relais ou application cible - C'est le Console de gestion AWS URL vers laquelle vous souhaitez rediriger vos utilisateurs authentifiés. Dans ce cas, c'est https://eu-west-1.console.aws.amazon.com/sqlworkbench/home?. Pour ce post, nous utilisons le eu-west-1 Région, mais vous pouvez l'ajuster si nécessaire.

J'ai suivi les instructions de Comment utiliser SAML pour diriger automatiquement les utilisateurs fédérés vers une page AWS Management Console spécifique et utilisé le générateur AD FS 2.0 RelayState pour générer l'URL indiquée dans la capture d'écran suivante.

Voici un exemple de l'URL finale que vous utilisez pour vous authentifier et également être redirigé vers l'éditeur de requête Amazon Redshift v2 (cette URL ne fonctionnera pas dans votre configuration car elle a été créée spécifiquement pour un serveur AD FS dans mon compte) : https://EC2AMAZ-F9TJOIC.adfsredshift.com/adfs/ls/IdpInitiatedSignOn.aspx?RelayState=RPID%3Durn%253Aamazon%253Awebservices%26RelayState%3Dhttps%253A%252F%252Feu-west-1.console.aws.amazon.com%252Fsqlworkbench%252Fhome%253Fregion%253Deu-west-1%2523%252Fclient

Vous pouvez maintenant enregistrer cette URL et l'utiliser depuis n'importe quel endroit où vous pouvez accéder à votre serveur AD FS. Après avoir saisi l'URL dans un navigateur, vous vous authentifiez d'abord auprès d'AD FS, puis vous êtes redirigé vers la console v2 de l'éditeur de requête Amazon Redshift.

Configurer des groupes de bases de données sur le cluster Amazon Redshift

Dans cette étape, vous configurez votre groupe de base de données Amazon Redshift. Cette étape est nécessaire car lorsque l'utilisateur est authentifié, il doit faire partie d'un groupe de bases de données Amazon Redshift avec les autorisations appropriées définies sur un schéma ou une table (ou une vue).

Dans Active Directory, l'utilisateur Bob fait partie de deux groupes : Sales et Marketing. Dans votre base de données Amazon Redshift, vous disposez de trois groupes de bases de données : Sales, Marketinget Finance.

Lorsque l'utilisateur Bob se connecte via l'authentification fédérée, l'utilisateur assume Sales et Marketing groupes de bases de données, afin que cet utilisateur puisse interroger des tables à la fois dans Sales et Marketing schémas. Parce que l'utilisateur Bob ne fait pas partie du Finance groupe, lorsqu'ils tentent d'accéder au Finance schéma, ils reçoivent une erreur d'autorisation refusée.

Le schéma suivant illustre cette configuration.

Effectuez les étapes suivantes pour configurer vos groupes de bases de données :

  1. Connectez-vous en tant que awsuser (un superutilisateur).
  2. Créez trois groupes de bases de données :
    CREATE GROUP sales;
    CREATE GROUP marketing;
    CREATE GROUP finance;

  3. Créez trois schémas :
    CREATE SCHEMA sales;
    CREATE SCHEMA marketing;
    CREATE SCHEMA finance;

  4. Créez une table dans chaque schéma :
    CREATE TABLE IF NOT EXISTS marketing.employee
    (
    	n_empkey INTEGER
    	,n_name CHAR(25)
    	,n_regionkey INTEGER
    	,n_comment VARCHAR(152)
    )
    DISTSTYLE AUTO
     SORTKEY (n_empkey);
    
    CREATE TABLE IF NOT EXISTS sales.employee_sales
    (
    	n_empkey INTEGER
    	,n_name CHAR(25)
    	,n_regionkey INTEGER
    	,n_comment VARCHAR(152)
    )
    DISTSTYLE AUTO
     SORTKEY (n_empkey);
    
    
    CREATE TABLE IF NOT EXISTS finance.accounts
    (
    	account_id INTEGER
    	,account_name CHAR(25)
    
    )
    DISTSTYLE AUTO
     SORTKEY (account_id);

  5. Insérez des exemples de données dans les trois tables :
    INSERT INTO marketing.employee
    VALUES(1, 'Bob', 0, 'Marketing');
    
    INSERT INTO sales.employee_sales
    VALUES(1, 'John', 0, 'Sales');
    
    INSERT INTO finance.accounts
    VALUES(1, 'online company');

  6. Vérifiez que les données sont disponibles dans les tables :
    Select * from marketing.employee;
    Select * from sales.employee_sales;
    Select * from finance.accounts;

Vous pouvez maintenant configurer les privilèges appropriés pour le sales, financeet marketing groupes. Les groupes sont des ensembles d'utilisateurs qui disposent tous des privilèges associés au groupe. Vous pouvez utiliser des groupes pour attribuer des privilèges par fonction. Par exemple, vous pouvez créer différents groupes pour les ventes, l'administration et le support, et accorder aux utilisateurs de chaque groupe l'accès approprié aux données dont ils ont besoin pour leur travail. Vous pouvez accorder ou révoquer des privilèges au niveau du groupe, et ces modifications s'appliquent à tous les membres du groupe, à l'exception des superutilisateurs.

  1. Entrez les requêtes SQL suivantes pour accorder l'accès à toutes les tables du sales schéma au groupe de vente, accès à toutes les tables du marketing schéma à la marketing groupe et l'accès à toutes les tables du finance schéma à la finance groupe:
ALTER DEFAULT PRIVILEGES IN SCHEMA sales
GRANT SELECT on TABLES to GROUP sales;
GRANT USAGE on SCHEMA sales to GROUP sales;
GRANT SELECT on ALL TABLES in SCHEMA sales to GROUP sales;

ALTER DEFAULT PRIVILEGES IN SCHEMA marketing
GRANT SELECT on TABLES to GROUP marketing;
GRANT USAGE on SCHEMA marketing to GROUP marketing;
GRANT SELECT on ALL TABLES in SCHEMA marketing to GROUP marketing;

ALTER DEFAULT PRIVILEGES IN SCHEMA finance
GRANT SELECT on TABLES to GROUP finance;
GRANT USAGE on SCHEMA finance to GROUP finance;
GRANT SELECT on ALL TABLES in SCHEMA finance to GROUP finance;

Accéder à l'éditeur de requêtes Amazon Redshift v2 via l'authentification fédérée

Maintenant que vous avez terminé votre intégration SAML, la configuration des liens profonds et la configuration des groupes de bases de données et des droits d'accès, vous pouvez configurer l'éditeur de requête Amazon Redshift v2 pour utiliser l'authentification fédérée avec AD FS pour vous connecter directement à partir de l'interface de l'éditeur de requête.

  1. Accédez à l'URL de lien profond que vous avez créée précédemment.
    Vous êtes redirigé vers la page de connexion AD FS.
  2. Connectez-vous en tant que bob@adfsredshift.com.
    Pour cet article, j'ai accédé à cette URL à partir d'une machine Amazon EC2, mais vous pouvez y accéder depuis n'importe quel emplacement où vous pouvez atteindre l'IdP AD FS.
    Une fois qu'AD FS vous authentifie avec succès, il redirige vers le point de terminaison AWS SSO et publie l'assertion SAML et RelayState paramètre. Étant donné que vous avez configuré deux rôles IAM du côté AWS, vous êtes invité à sélectionner un rôle.
  3. Sélectionnez un rôle (pour cet exemple, ADFZ-Dev) et choisissez Se connecter.

    AWS envoie l'URL de connexion basée sur le RelayState valeur vers votre navigateur en tant que redirection. Votre navigateur est automatiquement redirigé vers la console de l'éditeur de requête v2.
  4. Cliquez avec le bouton droit sur votre cluster Amazon Redshift (pour cet article, redshift-cluster-1) et choisissez Modifier la connexion.

    La valeur pour nom d'utilisateur est automatiquement rempli, et Accès fédéré est automatiquement sélectionné.
  5. Selectionnez Modifier la connexion pour enregistrer la connexion et se connecter à la base de données.

    Une fois connecté, vous pouvez parcourir les objets de la base de données dans le volet de gauche.
  6. Testez la connexion en exécutant la requête suivante :
    select * from stv_sessions;

La capture d'écran suivante montre la sortie.

La sortie montre que l'utilisateur bob@adfsredshift.com a été authentifié à l'aide d'AD FS. L'utilisateur a également rejoint le marketing et Sales groupes tels qu'appliqués par AD FS PrincipalTag:RedshiftDbGroups règle de revendication et la politique associée à la ADFZ-Dev rôle que l'utilisateur assume au cours de cette session.

Exécuter des requêtes pour valider l'autorisation via des groupes fédérés

Dans cette dernière étape, vous validez la manière dont les groupes et l'appartenance configurés dans AD sont intégrés de manière transparente aux groupes de base de données Amazon Redshift.

Exécutez la requête suivante sur le marketing et sales schéma:

select * from marketing.employee;
select * from sales.employee_sales;

Les captures d'écran suivantes montrent le résultat :

Les images précédentes montrent que l'utilisateur AD Bob fait partie du groupe AD RSDB-marketing et RSDB-sales, qui sont mappés aux groupes de bases de données marketing et sales. Ces groupes de bases de données ont un accès sélectif aux schémas marketing et ventes et à toutes les tables de ces schémas. Par conséquent, l'utilisateur peut interroger les tables avec succès.

Pour exécuter une requête sur le finance schéma, saisissez le code suivant :

select * from finance.accounts;

La capture d'écran suivante montre la sortie.

La sortie montre que Bob n'est qu'une partie des groupes AD RSDB-marketing et RSDB-sales. En raison de la configuration de la règle de revendication, Bob n'a pas accès au groupe de base de données finance, et par conséquent la requête renvoie une erreur d'autorisation refusée.

Nettoyer

Pour éviter des frais futurs, supprimez les ressources en supprimant la pile CloudFormation. Cela nettoie toutes les ressources de votre compte AWS que vous avez configurées dans Partie 1.

Conclusion

Dans cet article, nous avons montré comment configurer un serveur AD FS, configurer différents PrincipalTag attributs utilisés pour l'éditeur de requête Amazon Redshift v2 et générer une URL SSO avec l'éditeur de requête comme emplacement de destination. Vous vous êtes ensuite connecté au cluster de base de données Amazon Redshift à l'aide d'un utilisateur de base de données disposant de privilèges d'administrateur pour configurer des groupes et des autorisations de base de données, et avez utilisé une authentification d'utilisateur fédéré avec AD FS pour exécuter plusieurs requêtes. Cette solution vous permet de contrôler l'accès à vos objets de base de données Amazon Redshift en utilisant des groupes et des adhésions AD de manière transparente.

Si vous avez des commentaires ou des questions, veuillez les laisser dans les commentaires.


À propos des auteurs

Sumeet Joshi est un architecte de solutions spécialisées en analyse basé à New York. Il se spécialise dans la construction de solutions d'entreposage de données à grande échelle. Il a plus de 16 ans d'expérience dans le domaine de l'entreposage de données et de l'analyse.

Bhanu Pittampally est un architecte de solutions spécialisées en analyse basé à Dallas. Il est spécialisé dans la construction de solutions analytiques. Son expérience est dans les données et l'analyse depuis plus de 14 ans. Son profil LinkedIn peut être trouvé ici.

Erol Murtezaoğlu, responsable produit technique chez AWS, est un penseur curieux et enthousiaste, animé par une volonté d'amélioration personnelle et d'apprentissage. Il possède une expérience technique solide et éprouvée dans le développement et l'architecture de logiciels, équilibrée par une volonté de fournir des produits à succès commercial. Erol accorde une grande importance au processus de compréhension des besoins et des problèmes des clients, afin de fournir des solutions qui dépassent les attentes.

Yanis Télaoumaten est ingénieur en développement logiciel chez AWS. Ses passions sont la construction de logiciels fiables et la création d'outils permettant à d'autres ingénieurs de travailler plus efficacement. Au cours des dernières années, il a travaillé sur l'identité, la sécurité et la fiabilité des services Redshift

spot_img

Dernières informations

spot_img

Discutez avec nous

Salut! Comment puis-je t'aider?