RoleSessionName при получении CognitoIdentityCredentials - PullRequest
0 голосов
/ 06 января 2020

Я пытаюсь встроить информационные панели Quicksight в приложение, использующее пул Cognito для проверки подлинности. Чтобы получить URL-адрес для встроенной панели мониторинга, я разрешаю пользователю выполнять роль IAM, которая сопоставляется с пользователем Quicksight (автоматически создается) через Cognito Identity Pool.

Чтобы этот поток состоялся, предполагаемая роль должна иметь RoleSessionName, совпадающее с именем SessionName, переданным в вызов * registerUser() в Quicksight API (т. Е. В данном случае адрес электронной почты)

Моя проблема заключается в том, что когда я получаю учетные данные из пула удостоверений, передавая RoleSessionName в параметрах, предполагаемая роль, как представляется, не имеет установленного имени сеанса, поэтому при вызове Quicksight происходит сбой.

Пример:

AWS.config.credentials = new CognitoIdentityCredentials({
            IdentityPoolId: 'eu-central-1:ea3b7c31-bf53-4a30-9bdc-xxxxxxxxx',
            RoleSessionName: user.email,
            Logins: {
                'cognito-idp.eu-central-1.amazonaws.com/eu-central-1_xxxxxxxx' : user.id_token
            }
        })

AWS.config.getCredentials((e) => {
   let sts = new STS();
   console.log(await sts.getCallerIdentity().promise());
})

Результат этого показывает

{ ResponseMetadata: { RequestId: 'e77ea0e7-30b9-11ea-a070-e5aa4c17e68c' },
  UserId: 'AROA6JSEZRBBBBBBBB:CognitoIdentityCredentials',
  Account: '9826XXXXXXXXX',
  Arn:
   'arn:aws:sts::9826XXXXXXXXX:assumed-role/Cognito_quicksightAuth_Role/CognitoIdentityCredentials' }

Насколько я понимаю, RoleSessionName должен быть последней частью ARN. Сравните, если я приму роль напрямую:

➜  aws sts assume-role --role-arn arn:aws:iam::9826XXXXXXXX:role/Cognito_quicksightAuth_Role --role-session-name me@mydomain.io
{
    "Credentials": {
        ...
    },
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA6JSEZBBBBBBB:me@mydomain.io",
        "Arn": "arn:aws:sts::9826XXXXXXXX:assumed-role/Cognito_quicksightAuth_Role/me@mydomain.io"
    }
}

Я могу показать, что проблема RoleSessionName - это проблема в моем потоке, потому что я могу заставить все работать, либо а) создав пользователя Quicksight с CognitoIdentityCredentials как SessionName, или b) Явное принятие роли с RoleSessionName по sts.assumeRole()

Неправильно ли я ожидать, что вызов AWS.config.getCredentials() вернет пользователь с переданным RoleSessionName в ARN?

1 Ответ

0 голосов
/ 08 января 2020

Короткий ответ - да. Вы правы с упомянутым вариантом использования базы ролей. Полный ответ выглядит следующим образом.

API registerUser () позволяет клиенту создавать два типа пользователей: ролевой базы (--session-name) или galaxy-user (--user-name). Для пользователя QuickSight ARN:

роль-базовый пользователь

arn:aws:quicksight:[region]:9826XXXXXXXX:user/[namespace]/[assumed-role-name]/[session-name]

galaxy-user

arn:aws:quicksight:[region]:9826XXXXXXXX:user/[namespace]/[user-name]

Использование 'default' как пространство имен, если ваша учетная запись не содержит другое пространство имен. Регион большинства учетных записей - «us-east-1».

Получив пользователя, вы можете вызвать API GetDashboardEmbedUrl () для получения URL-адреса для указанного пользователя c. Для этого вы можете предоставить аргумент --user-arn.

aws quicksight get-dashboard-embed-url --user-arn "arn:aws:quicksight:us-east-1:9826XXXXXXXX:user/..." ...

Если аргумент --user-arn не предоставлен, API сгенерирует userARN на основе ролей из имени-роли вызывающего абонента и имени сеанса. Вызов не будет выполнен, если userARN не существует в учетной записи QuickSight. Это то, что вы испытываете. Я рекомендую использовать аргумент --user-arn для детерминированного поведения c.

...