RGW STS Support in Nautilus ?

List overview All Threads
Download

newer

older

test, please ignore (unless you...

osd_memory_target in Rook, set...

Wyllys Ingersoll

12 May 2020 12 May '20

4:45 p.m.

Running Nautilus 14.2.9 and trying to follow the STS example given here: https://docs.ceph.com/docs/master/radosgw/STS/ to setup a policy for AssumeRoleWithWebIdentity using KeyCloak (8.0.1) as the OIDC provider. I am able to see in the rgw debug logs that the token being passed from the client is passing the introspection check, but it always ends up failing the final authorization to access the requested bucket resource and is rejected with a 403 status "AccessDenied". I configured my policy as described in the 2nd example on the STS page above. I suspect the problem is with the "StringEquals" condition statement in the AssumeRolePolicy document (I could be wrong though). The example shows using the keycloak URI followed by ":app_id" matching with the name of the keycloak client application ("customer-portal" in the example). My keycloak setup does not have any such field in the introspection result and I can't seem to figure out how to make this all work. I cranked up the logging to 20/20 and still did not see any hints as to what part of the policy is causing the access to be denied. Any suggestions? -Wyllys Ingersoll

Attachments:

attachment.htm (text/html — 1.4 KB)

Show replies by date

Pritha Srivastava

12 May 12 May

5:01 p.m.

app_id must match with the 'aud' field in the token introspection result (In the example the value of 'aud' is 'customer-portal') Thanks, Pritha On Tue, May 12, 2020 at 8:16 PM Wyllys Ingersoll < wyllys.ingersoll(a)keepertech.com> wrote:

...

Wyllys Ingersoll

5:11 p.m.

The "aud" field in the introspection result is a list, not a single string. On Tue, May 12, 2020 at 11:02 AM Pritha Srivastava <prsrivas(a)redhat.com> wrote:

...

Wyllys Ingersoll

5:37 p.m.

Thanks for the hint, I fixed my keycloak configuration for that application client so the token only includes a single audience value and now it works fine. thanks!! On Tue, May 12, 2020 at 11:11 AM Wyllys Ingersoll < wyllys.ingersoll(a)keepertech.com> wrote:

...

The "aud" field in the introspection result is a list, not a single string. On Tue, May 12, 2020 at 11:02 AM Pritha Srivastava <prsrivas(a)redhat.com> wrote: > app_id must match with the 'aud' field in the token introspection result > (In the example the value of 'aud' is 'customer-portal') > > Thanks, > Pritha > > On Tue, May 12, 2020 at 8:16 PM Wyllys Ingersoll < > wyllys.ingersoll(a)keepertech.com> wrote: > >> >> Running Nautilus 14.2.9 and trying to follow the STS example given here: >> https://docs.ceph.com/docs/master/radosgw/STS/ to setup a policy >> for AssumeRoleWithWebIdentity using KeyCloak (8.0.1) as the OIDC provider. >> I am able to see in the rgw debug logs that the token being passed from the >> client is passing the introspection check, but it always ends up failing >> the final authorization to access the requested bucket resource and is >> rejected with a 403 status "AccessDenied". >> >> I configured my policy as described in the 2nd example on the STS page >> above. I suspect the problem is with the "StringEquals" condition statement >> in the AssumeRolePolicy document (I could be wrong though). >> >> The example shows using the keycloak URI followed by ":app_id" matching >> with the name of the keycloak client application ("customer-portal" in the >> example). My keycloak setup does not have any such field in the >> introspection result and I can't seem to figure out how to make this all >> work. >> >> I cranked up the logging to 20/20 and still did not see any hints as to >> what part of the policy is causing the access to be denied. >> >> Any suggestions? >> >> -Wyllys Ingersoll >> >> _______________________________________________ >> Dev mailing list -- dev(a)ceph.io >> To unsubscribe send an email to dev-leave(a)ceph.io >> >

Matt Benjamin

5:50 p.m.

yay! thanks Wyllys, Pritha Matt On Tue, May 12, 2020 at 11:38 AM Wyllys Ingersoll <wyllys.ingersoll(a)keepertech.com> wrote:

...

The "aud" field in the introspection result is a list, not a single string. On Tue, May 12, 2020 at 11:02 AM Pritha Srivastava <prsrivas(a)redhat.com> wrote: > > app_id must match with the 'aud' field in the token introspection result (In the example the value of 'aud' is 'customer-portal') > > Thanks, > Pritha > > On Tue, May 12, 2020 at 8:16 PM Wyllys Ingersoll <wyllys.ingersoll(a)keepertech.com> wrote: >> >> >> Running Nautilus 14.2.9 and trying to follow the STS example given here: https://docs.ceph.com/docs/master/radosgw/STS/ to setup a policy for AssumeRoleWithWebIdentity using KeyCloak (8.0.1) as the OIDC provider. I am able to see in the rgw debug logs that the token being passed from the client is passing the introspection check, but it always ends up failing the final authorization to access the requested bucket resource and is rejected with a 403 status "AccessDenied". >> >> I configured my policy as described in the 2nd example on the STS page above. I suspect the problem is with the "StringEquals" condition statement in the AssumeRolePolicy document (I could be wrong though). >> >> The example shows using the keycloak URI followed by ":app_id" matching with the name of the keycloak client application ("customer-portal" in the example). My keycloak setup does not have any such field in the introspection result and I can't seem to figure out how to make this all work. >> >> I cranked up the logging to 20/20 and still did not see any hints as to what part of the policy is causing the access to be denied. >> >> Any suggestions? >> >> -Wyllys Ingersoll >> >> _______________________________________________ >> Dev mailing list -- dev(a)ceph.io >> To unsubscribe send an email to dev-leave(a)ceph.io

_______________________________________________ Dev mailing list -- dev(a)ceph.io To unsubscribe send an email to dev-leave(a)ceph.io

-- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309

Wyllys Ingersoll

6:50 p.m.

...

yay! thanks Wyllys, Pritha Matt On Tue, May 12, 2020 at 11:38 AM Wyllys Ingersoll <wyllys.ingersoll(a)keepertech.com> wrote:

Thanks for the hint, I fixed my keycloak configuration for that

application client so the token only includes a single audience value and now it works fine.

thanks!! On Tue, May 12, 2020 at 11:11 AM Wyllys Ingersoll <

wyllys.ingersoll(a)keepertech.com> wrote:

> > The "aud" field in the introspection result is a list, not a single

string.

> > On Tue, May 12, 2020 at 11:02 AM Pritha Srivastava <prsrivas(a)redhat.com>

wrote:

>> >> app_id must match with the 'aud' field in the token introspection

result (In the example the value of 'aud' is 'customer-portal')

>> >> Thanks, >> Pritha >> >> On Tue, May 12, 2020 at 8:16 PM Wyllys Ingersoll <

wyllys.ingersoll(a)keepertech.com> wrote:

>>> >>> >>> Running Nautilus 14.2.9 and trying to follow the STS example given

here: https://docs.ceph.com/docs/master/radosgw/STS/ to setup a policy for AssumeRoleWithWebIdentity using KeyCloak (8.0.1) as the OIDC provider. I am able to see in the rgw debug logs that the token being passed from the client is passing the introspection check, but it always ends up failing the final authorization to access the requested bucket resource and is rejected with a 403 status "AccessDenied".

>>> >>> I configured my policy as described in the 2nd example on the STS

page above. I suspect the problem is with the "StringEquals" condition statement in the AssumeRolePolicy document (I could be wrong though).

>>> >>> The example shows using the keycloak URI followed by ":app_id"

matching with the name of the keycloak client application ("customer-portal" in the example). My keycloak setup does not have any such field in the introspection result and I can't seem to figure out how to make this all work.

>>> >>> I cranked up the logging to 20/20 and still did not see any hints as

to what part of the policy is causing the access to be denied.

>> >> Any suggestions? >> >> -Wyllys Ingersoll >> >> _______________________________________________ >> Dev mailing list -- dev(a)ceph.io >> To unsubscribe send an email to dev-leave(a)ceph.io

_______________________________________________ Dev mailing list -- dev(a)ceph.io To unsubscribe send an email to dev-leave(a)ceph.io

-- Matt Benjamin Red Hat, Inc. 315 West Huron Street, Suite 140A Ann Arbor, Michigan 48103 http://www.redhat.com/en/technologies/storage tel. 734-821-5101 fax. 734-769-8938 cel. 734-216-5309

Pritha Srivastava

13 May 13 May

3:32 a.m.

Matching other fields in the token as part of the Condition Statement is work in progress, but isnt there in nautilus. Thanks, Pritha On Tue, May 12, 2020 at 10:21 PM Wyllys Ingersoll < wyllys.ingersoll(a)keepertech.com> wrote:

...

Does STS support using other fields from the token as part of the Condition statement? For example looking for specific "sub" identities or matching on custom token fields like lists of roles? On Tue, May 12, 2020 at 11:50 AM Matt Benjamin <mbenjami(a)redhat.com> wrote: > yay! thanks Wyllys, Pritha > > Matt > > On Tue, May 12, 2020 at 11:38 AM Wyllys Ingersoll > <wyllys.ingersoll(a)keepertech.com> wrote: > > > > > > Thanks for the hint, I fixed my keycloak configuration for that > application client so the token only includes a single audience value and > now it works fine. > > > > thanks!! > > > > > > On Tue, May 12, 2020 at 11:11 AM Wyllys Ingersoll < > wyllys.ingersoll(a)keepertech.com> wrote: > >> > >> The "aud" field in the introspection result is a list, not a single > string. > >> > >> On Tue, May 12, 2020 at 11:02 AM Pritha Srivastava < > prsrivas(a)redhat.com> wrote: > >>> > >>> app_id must match with the 'aud' field in the token introspection > result (In the example the value of 'aud' is 'customer-portal') > >>> > >>> Thanks, > >>> Pritha > >>> > >>> On Tue, May 12, 2020 at 8:16 PM Wyllys Ingersoll < > wyllys.ingersoll(a)keepertech.com> wrote: > >>>> > >>>> > >>>> Running Nautilus 14.2.9 and trying to follow the STS example given > here: https://docs.ceph.com/docs/master/radosgw/STS/ to setup a policy > for AssumeRoleWithWebIdentity using KeyCloak (8.0.1) as the OIDC provider. > I am able to see in the rgw debug logs that the token being passed from the > client is passing the introspection check, but it always ends up failing > the final authorization to access the requested bucket resource and is > rejected with a 403 status "AccessDenied". > >>>> > >>>> I configured my policy as described in the 2nd example on the STS > page above. I suspect the problem is with the "StringEquals" condition > statement in the AssumeRolePolicy document (I could be wrong though). > >>>> > >>>> The example shows using the keycloak URI followed by ":app_id" > matching with the name of the keycloak client application > ("customer-portal" in the example). My keycloak setup does not have any > such field in the introspection result and I can't seem to figure out how > to make this all work. > >>>> > >>>> I cranked up the logging to 20/20 and still did not see any hints as > to what part of the policy is causing the access to be denied. > >>>> > >>>> Any suggestions? > >>>> > >>>> -Wyllys Ingersoll > >>>> > >>>> _______________________________________________ > >>>> Dev mailing list -- dev(a)ceph.io > >>>> To unsubscribe send an email to dev-leave(a)ceph.io > > > > _______________________________________________ > > Dev mailing list -- dev(a)ceph.io > > To unsubscribe send an email to dev-leave(a)ceph.io > > > > -- > > Matt Benjamin > Red Hat, Inc. > 315 West Huron Street, Suite 140A > Ann Arbor, Michigan 48103 > > http://www.redhat.com/en/technologies/storage > > tel. 734-821-5101 > fax. 734-769-8938 > cel. 734-216-5309 > >

1303

days inactive

1304

days old

dev@ceph.io

Manage subscription

6 comments

3 participants

tags (0)

participants (3)

Matt Benjamin
Pritha Srivastava
Wyllys Ingersoll