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@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@redhat.com> wrote:
yay!  thanks Wyllys, Pritha

Matt

On Tue, May 12, 2020 at 11:38 AM Wyllys Ingersoll
<wyllys.ingersoll@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@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@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@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@ceph.io
>>>> To unsubscribe send an email to dev-leave@ceph.io
>
> _______________________________________________
> Dev mailing list -- dev@ceph.io
> To unsubscribe send an email to dev-leave@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