Thank you, Zane for the discussion.
Point taken about sending webhook notifications.
Primarily I want Congress to consume webhook notifications from the
openstack services which already send them (monasca, vitrage, etc.). Most
of them do not currently support sending appropriate keystone tokens
On 03/05/18 15:49, Eric K wrote:
Question to the projects which send or consume webhook notifications
(telemetry, monasca, senlin, vitrage, etc.), what are your
supported/preferred authentication mechanisms? Bearer token (e.g.
Keystone)? Signing?
Signed URLs and regular Keystone auth are both
To clarify, one of the reasons I'd like to accept webhook notifications
authenticated with keystone tokens is that I don't want the access to
expire, but of course it's poor practice to use a signed URL that never
expires.
Eric
On 5/8/18, 12:29 PM, "Eric K" wrote:
Thanks, Thomas!
I see the point that it is impractical to configure a service with a fixed
keystone token to use in webhook notifications because they expire fairly
quickly.
I'm thinking about the situation where the sending service can obtain
tokens directly from keystone. In that case I'm
On Sat, May 5, 2018 at 1:53 AM, Eric K wrote:
> Thanks a lot Witold and Thomas!
>
> So it doesn't seem that someone is currently using a keystone token to
> authenticate web hook? Is is simply because most of the use cases had
> involved services which do not use
Thanks a lot Witold and Thomas!
So it doesn't seem that someone is currently using a keystone token to
authenticate web hook? Is is simply because most of the use cases had
involved services which do not use keystone?
Or is it unsuitable for another reason?
On 5/4/18, 2:36 AM, "Thomas Herve"
On Thu, May 3, 2018 at 9:49 PM, Eric K wrote:
> Question to the projects which send or consume webhook notifications
> (telemetry, monasca, senlin, vitrage, etc.), what are your
> supported/preferred authentication mechanisms? Bearer token (e.g.
> Keystone)? Signing?
>
>