From: J. Eric Ivancich <ivancich@redhat.com>
Date: Wed, 27 Oct 2021 13:28:47 +0000 (-0400)
Subject: Merge pull request #42704 from wzbxqt327/patch-1
X-Git-Tag: v17.1.0~588
X-Git-Url: http://git-server-git.apps.pok.os.sepia.ceph.com/?a=commitdiff_plain;h=d72d74a7edccbe7e6ee3e0582979bf6f063d7d5e;p=ceph.git

Merge pull request #42704 from wzbxqt327/patch-1

rgw,doc: fix command problem

Reviewed-by: Pritha Srivastava <prsrivas@redhat.com>
Reviewed-by: Casey Bodley <cbodley@redhat.com>
---

d72d74a7edccbe7e6ee3e0582979bf6f063d7d5e
diff --cc doc/radosgw/STS.rst
index e26e68e3b6a82,6cfb28dd4f1ca..b4cd67148b582
--- a/doc/radosgw/STS.rst
+++ b/doc/radosgw/STS.rst
@@@ -63,22 -63,13 +63,22 @@@ Parameters
  Before invoking AssumeRoleWithWebIdentity, an OpenID Connect Provider entity (which the web application
  authenticates with), needs to be created in RGW.
  
 -The trust between the IDP and the role is created by adding a Condition to the role trust policy, which
 -allows access only to applications with the app id given in the trust policy document. The Condition
 -is of the form::
 +The trust between the IDP and the role is created by adding a condition to the role's trust policy, which
 +allows access only to applications which satisfy the given condition.
 +All claims of the JWT are supported in the condition of the role's trust policy.
 +An example of a policy that uses the 'aud' claim in the condition is of the form::
  
-     "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Federated\":[\"arn:aws:iam:::oidc-provider/<URL of IDP>\"]},\"Action\":[\"sts:AssumeRoleWithWebIdentity\"],\"Condition\":{\"StringEquals\":{\"<URL of IDP> :app_id\":\"<aud>\"\}\}\}\]\}"
+     '''{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Federated":["arn:aws:iam:::oidc-provider/<URL of IDP>"]},"Action":["sts:AssumeRoleWithWebIdentity"],"Condition":{"StringEquals":{"<URL of IDP> :app_id":"<aud>"}}}]}'''
  
 -The app_id in the condition above must match the 'aud' field of the incoming token.
 +The app_id in the condition above must match the 'aud' claim of the incoming token.
 +
 +An example of a policy that uses the 'sub' claim in the condition is of the form::
 +
 +    "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Federated\":[\"arn:aws:iam:::oidc-provider/<URL of IDP>\"]},\"Action\":[\"sts:AssumeRoleWithWebIdentity\"],\"Condition\":{\"StringEquals\":{\"<URL of IDP> :sub\":\"<sub>\"\}\}\}\]\}"
 +
 +Similarly, an example of a policy that uses 'azp' claim in the condition is of the form::
 +
 +    "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"Federated\":[\"arn:aws:iam:::oidc-provider/<URL of IDP>\"]},\"Action\":[\"sts:AssumeRoleWithWebIdentity\"],\"Condition\":{\"StringEquals\":{\"<URL of IDP> :azp\":\"<azp>\"\}\}\}\]\}"
  
  A shadow user is created corresponding to every federated user. The user id is derived from the 'sub' field of the incoming web token.
  The user is created in a separate namespace - 'oidc' such that the user id doesn't clash with any other user ids in rgw. The format of the user id