APIゲートウェイ許可のためのAWS IAMポリシー変数のエスケープ

Question

現在、認証プロバイダ（auth0）とAWS/AWS API Gatewayの間で期待どおりにSAML統合設定が機能しています。 しかし、$ {saml：sub}変数を使用してAWSポリシーを定義すると複雑になります。ここで

は私の構成の例です：

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

}

基本的に私はこのエンドポイントは、現在のユーザー（自分のSAMLに基づく：サブ）でauth'dによってのみアクセス可能であることを確認したいです。現在認証されているユーザーは、別の顧客レコードにアクセスできません。このように、潜在的に一般的なユースケースになるはずです。

Auth0が自動的にSAMLを割り当て：サブとidの形式は、この

auth0|429 

のようなものである私は、この問題は現在、パイプ文字がそこにいるとあると仮定することだし、それは自動的にエスケープされた値と比較することブラウザを介してAPIゲートウェイURLに要求が行われたときに発生します。このため、私はリソースへのアクセスが拒否されていると仮定しています。 auth0|429 != auth0%7C429です。

これを回避する方法はIAMポリシー内にありますか？ Auth0側で、$ {saml：sub}に別の値を割り当てるための潜在的な回避策はありますか？

Answer 1

上記のすべての潜在的な解決策を理解してください！最終的に、私はAuth0とAWSの間のSAML統合を断念し、APIゲートウェイ内のラムダ機能を介してカスタムオーソライザを選択しました。これにより、少し柔軟な設定が可能になりました。同様のシナリオが直面している他の誰のために

は、私がこれまでに素晴らしい仕事をしています。このGitHubのプロジェクトに出くわした： https://github.com/jghaines/lambda-auth0-authorizer

私は、私たち自身の目的のためにプロジェクトを少し変更し、私たちがやった、本質的にどのような内部ユーザーIDがAWS principalIdにマップされます。 APIゲートウェイ側で

は、我々は、セットアップA /顧客/私のリソースにして、統合要求にそのようなURLパスのパラメータを変更した： 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" ] } ] }

これにより、エンドポイントへの動的アクセスが可能になり、ログインしたユーザーに固有のデータのみが返されます。

Answer 2

私の意見では、AWSポリシーの設定から解決する必要がありますが、私はそれに精通していないため、潜在的な面倒な文字を避けるという視点から回避策を提供します。

Auth0がユーザ情報を出力するために使用するデフォルトのSAMLマッピングを設定して上書きすることができ、それによって出力要求とSAMLサブジェクトのそれぞれに使用される属性を制御することができます。

これを行う方法の概要は、SAML attributes mappingを参照してください。

また、使用可能なすべてのオプションの詳細については、SAML configuration via rulesを確認してください。

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

Answer 3

IAM：Auth0は1を決定するために、以下の特許請求の範囲をチェックしますデフォルトでは

は、SAMLの対象として使用されますポリシーは、実際のリソースARNの$ {saml：sub}を認識することができません。それを超えて、API GWは自動的にSAMLアサーションを理解しません。

カスタム承認者のラムダ関数を使用して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扱いとして、あなたは安全に許可するポリシーを構築することができ、リソースの符号化されていないと、符号化の両方のバージョン：

{ 
"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" 
     ] 
    } 
    ] 
} 

カスタム承認者を使用していない場合は、セットアップがどのように見えるかについて詳しく説明してください。しかしどちらの場合でも、残念ながらIAMポリシーはリソースブロック内の$ {var}構文を評価することはできません。