>From description of use case, looks like you want 'service user' to access any
>tenant resource regardless of that user has a tenant role or not and without
>explicit read assignment on that resource. This can be done via a customized
>policy where related 'get' calls are allowed access for a
ts failed. It beats the whole logic of being available.
About the keyrings, How do we tackle if a service is using JSON API calls and
not python clients?
Thanks,
-Ravi.
On Tue, Jun 18, 2013 at 6:37 PM, Adam Young
mailto:ayo...@redhat.com>> wrote:
On 06/18/2013 09:13 PM, Kant, Arun wrote:
T
ON API calls and
not python clients?
Thanks,
-Ravi.
On Tue, Jun 18, 2013 at 6:37 PM, Adam Young
mailto:ayo...@redhat.com>> wrote:
On 06/18/2013 09:13 PM, Kant, Arun wrote:
The issue with having un-managed number of tokens for same credential is that
it can be easily exploited. Getting
The issue with having un-managed number of tokens for same credential is
that it can be easily exploited. Getting a token is one of initial step
(gateway) to get access to services. A rogue client can keep creating
unlimited number of tokens and possibly create denial of service attack on
services.
