Эквивалентная переменная политики AWS IAM для разрешений шлюза API

В настоящее время у меня есть настройка интеграции SAML и работает как ожидалось между моим провайдером аутентификации (auth0) и AWS/AWS API Gateway. Однако возникают сложности при определении политики AWS с переменной $ {saml: sub}.Эквивалентная переменная политики AWS IAM для разрешений шлюза API

Вот пример моей конфигурации:

{ 
"Version": "2012-10-17", 
"Statement": [ 
    { 
     "Effect": "Allow", 
     "Action": [ 
      "execute-api:*" 
     ], 
     "Resource": [ 
      "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/${saml:sub}" 
     ] 
    } 
]

}

В основном я хочу, чтобы эта конечная точка доступна только в настоящее время auth'd в пользователя (на основе их SAML: суб) , В настоящее время пользователь auth'd не должен иметь доступ к другой записи клиентов. Похоже, это должно быть потенциально распространенным случаем использования.

Auth0 автоматически назначает SAML: к югу и формат идентификатора что-то вроде этого

auth0|429

Я предполагаю, что этот вопрос в настоящее время лежит характер трубы будучи там и сравнивая его с автоматическим спасся значение когда запрос направляется на URL-адрес шлюза API через браузер. Из-за этого я предполагаю, что доступ запрещен ресурсу, потому что auth0|429 != auth0%7C429.

Есть ли способ в рамках политики IAM обойти это? Существует ли потенциальное обходное решение на стороне Auth0 для присвоения другого значения $ {saml: sub}?

источник

2016-11-28 Zach Schmid

Оцените все возможные решения выше! В конечном итоге я отказался от интеграции SAML между Auth0 и AWS и выбрал специальный авторизатор с помощью лямбда-функции внутри API-шлюза. Это позволило немного более гибкую настройку.

Для тех, кто еще сталкивается подобный сценарий, я наткнулся на этот проект GitHub, который работал большой до сих пор: https://github.com/jghaines/lambda-auth0-authorizer

Я изменил проект для наших собственных целей немного, но, по сути, что мы сделали отображает наш внутренний идентификатор пользователя в AWS mainId.

На API стороне шлюза мы настроить/клиентов/Me ресурсу, а затем по требованию интеграции модифицировали URL Path Parameters следующим образом: Integration Request Screenshot

Наша политика в нашей лямбда-функции является установка как так

{ "Version": "2012-10-17", "Statement": [ { "Sid": "324342", "Effect": "Allow", "Action": [ "execute-api:Invoke" ], "Resource": [ "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/me" ] } ] }

Это обеспечивает динамический доступ к конечной точке и возвращает данные только для зарегистрированных пользователей.

источник

2016-12-07 02:23:18

В какой конечной точке вы используете: '/ customers/{id}' или '/ customers/me'? Похоже, что если вы используете '/ me' с идентификатором в своем запросе интеграции, вам не понадобится конечная точка'/{id} ', правильно? –

Извините за путаницу. Да - мы используем/customers/me, а не клиенты/{id} как ресурс. Я обновил ответ, чтобы это отразить. –

По моему мнению, проблема, о которой вы описали, должна быть решена/обработана из конфигурации конфигурации AWS, но поскольку я не осведомлен о ней, я предлагаю вам обходной путь с точки зрения избежания потенциальных проблемных персонажей.

Вы можете настроить и переопределить сопоставления SAML по умолчанию, которые Auth0 использует для вывода информации о пользователях, и как таковой контроль атрибутов, используемых для каждой из выходных претензий и субъекта SAML.

Проверьте, пожалуйста, SAML attributes mapping, как это сделать.

Дополнительно, отметьте SAML configuration via rules для получения детального обзора всех доступных вариантов.

По умолчанию Auth0 проверит следующие требования для того, чтобы решить один будет использоваться в качестве SAML предмета:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

источник

2016-11-29 09:56:31

СИА Политика не сможет распознать $ {saml: sub} в фактическом ARN ресурса. Кроме того, API GW не будет автоматически понимать утверждение SAML.

Вы используете пользовательскую функцию Lambda для авторизации для утверждения SAML?Если это так вы хотите, чтобы разобрать поле «суб» и вставить его непосредственно в политику вернулся из авторизатор как так

{ 
"Version": "2012-10-17", 
"Statement": [ 
    { 
     "Effect": "Allow", 
     "Action": [ 
      "execute-api:*" 
     ], 
     "Resource": [ 
      "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/auth0|429" 
     ] 
    } 
    ] 
}

Если вы уже так далеко, и она по-прежнему не работает, как ожидалось, то вы Правильно, может быть, что URI не нормализуется в зависимости от кодировки клиента/браузера. Я должен проверить это. Но до тех пор, как ваш бэкенд лечит /customers/auth0|429 == /customers/auth0%7C429, можно смело строить политику, которая позволяет как Unencoded и закодированные версии ресурса:

{ 
"Version": "2012-10-17", 
"Statement": [ 
    { 
     "Effect": "Allow", 
     "Action": [ 
      "execute-api:*" 
     ], 
     "Resource": [ 
      "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/auth0|429", 
      "arn:aws:execute-api:us-west-2:[removed]/*/GET/customers/auth0%7C429" 
     ] 
    } 
    ] 
}

Если вы не используете пользовательские authorizers, пожалуйста, подробно о том, что ваша установка выглядит , Но в любом случае, к сожалению, политика IAM никогда не сможет оценить синтаксис $ {var} в блоке ресурсов.

источник

2016-11-29 19:01:57

Эквивалентная переменная политики AWS IAM для разрешений шлюза API

ответ

Смежные вопросы