On 20 June 2016 at 12:33, Morgan Fainberg wrote:
>
>
> On Sun, Jun 19, 2016 at 6:51 PM, Adam Young wrote:
>
>> On 06/16/2016 02:19 AM, Jamie Lennox wrote:
>>
>> Thanks everyone for your input.
>>
>> I generally agree that there is something that doesn't quite feel right
>> about purely trusting
On Sun, Jun 19, 2016 at 6:51 PM, Adam Young wrote:
> On 06/16/2016 02:19 AM, Jamie Lennox wrote:
>
> Thanks everyone for your input.
>
> I generally agree that there is something that doesn't quite feel right
> about purely trusting this information to be passed from service to
> service, this is
On 06/16/2016 02:19 AM, Jamie Lennox wrote:
Thanks everyone for your input.
I generally agree that there is something that doesn't quite feel
right about purely trusting this information to be passed from service
to service, this is why i was keen for outside input and I have been
rethinking
Thanks everyone for your input.
I generally agree that there is something that doesn't quite feel right
about purely trusting this information to be passed from service to
service, this is why i was keen for outside input and I have been
rethinking the approach.
To this end i've proposed reservat
> On Jun 2, 2016, at 10:58 AM, Adam Young wrote:
>
> Any senseible RBAC setup would support this, but we are not using a sensible
> one, we are using a hand rolled one. Replacing everything with Fortress
> implies a complete rewrite of what we do now. Nuke it from orbit type stuff.
>
> What
On 06/02/2016 11:36 AM, Shawn McKinney wrote:
On Jun 2, 2016, at 10:03 AM, Adam Young wrote:
To do all of this right, however, requires a degree of introspection that we do not have
in OpenStack. Trove needs to ask Nova "I want to do X, what role do I need?"
and there is no where in the sys
> On Jun 2, 2016, at 10:03 AM, Adam Young wrote:
>
> To do all of this right, however, requires a degree of introspection that we
> do not have in OpenStack. Trove needs to ask Nova "I want to do X, what role
> do I need?" and there is no where in the system today that this information
> li
On 06/02/2016 01:23 AM, Jamie Lennox wrote:
Hi All,
I'd like to bring to the attention of the wider security groups and
OpenStack users the Service Users Permissions [1] spec currently
proposed against keystonemiddleware.
To summarize quickly OpenStack has long had the problem of token
expi
Hi Jamie
In my opinion no security token should have the potential to last
forever. This is a bad idea and can lead to all sorts of security
vulnerabilities, some of which you highlight below. I thus take issue
with your statement 'Ideally in a big system like this we only want to
validate a token
Hi All,
I'd like to bring to the attention of the wider security groups and
OpenStack users the Service Users Permissions [1] spec currently proposed
against keystonemiddleware.
To summarize quickly OpenStack has long had the problem of token expiry
happening in the middle of a long running opera
10 matches
Mail list logo