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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> > wrote: > >> yay! thanks Wyllys, Pritha >> >> Matt >> >> On Tue, May 12, 2020 at 11:38 AM Wyllys Ingersoll >> <wyllys.ingersoll@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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@xxxxxxx >> >>>> To unsubscribe send an email to dev-leave@xxxxxxx >> > >> > _______________________________________________ >> > Dev mailing list -- dev@xxxxxxx >> > To unsubscribe send an email to dev-leave@xxxxxxx >> >> >> >> -- >> >> 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 >> >> _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |