I presume there’s a spec coming for this “seductive approach”? Not sure if I
get all of it. From what’s been described here, conceptually, isn’t “local
groups”, DSRs, or role groups the same thing?
Guang
From: Henry Nash [mailto:henryna...@mac.com]
Sent: Monday, February 01, 2016 3:50 PM
To:
I am with Adam, I kinda doubt Apache cause performance issues for Keystone,
especially since all we have are just simple REST APIs. For other services with
specific needs, like large file streaming, there may be some arguments to pick
one over the other. We haven’t had the need to use Apache for
Can you please elaborate on "granularity of policy support within Ironic."? Is
there a blueprint/etherpad we can take a look?
Guang
-Original Message-
From: Devananda van der Veen [mailto:devananda@gmail.com]
Sent: Friday, September 11, 2015 10:25 AM
To: OpenStack Development Mail
Morgan, thanks for all your hard work. It’s been an honor to have you as our
PTL.
"All the world's a stage,”
Now set back, relax, grab a drink, and enjoy the show. ☺
Guang
From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
Sent: Thursday, September 10, 2015 2:41 PM
To: OpenStack Develo
under
that umbrella.
Henry
On 13 Jul 2015, at 19:20, Yee, Guang
mailto:guang@hp.com>> wrote:
++!
Per my understanding, the work, and therefore the risks, are fairly
compartmentalized. The upside is this will pave the way for a much richer
authorization management system.
Guang
++!
Per my understanding, the work, and therefore the risks, are fairly
compartmentalized. The upside is this will pave the way for a much richer
authorization management system.
Guang
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Monday, July 13, 2015 10:15 AM
To: openstack-dev@lists.ope
I am confused about the goal. Are we saying we should allow operators to modify
the access policies but then warn them if they do? But if operators *intend* to
modify the policies in order to fit their compliance/security needs, which is
likely the case, aren't the warning messages confusing and
Go for it. If I remember correctly, the existing ldappool feature offer us
roughly 30% performance gain. If ldap3 can do the same or better that would be
awesomer. I would also love to see some benchmark numbers between ldap3 and
SSSD for read-only LDAP.
Guang
-Original Message-
From
++
Same here.
From: Marek Denis [mailto:marek.de...@cern.ch]
Sent: Tuesday, March 24, 2015 1:51 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Keystone][FFE] ECP wrapped assertions
Hi,
I strongly support this request.
On 23.03.2015 22:42, Steve Martinelli wrote:
I'd like
I think we can create a mapping which restricts which IdP it is applicable.
When playing around with K2K, I've experimented with multiple IdPs. I basically
chained the IdPs in shibboleth2.xml like this
And with a mapping intended for Acme IdP, we can ensure that only Acme users
can
++
As for the unbound groups concern, our initial internal Federation POCs worked
well with a single group so far. The proposed hierarchical role groups, or
perhaps even supporting nested user groups down the road should offer us more
flexibility in terms user and permission management. For exa
+1!
Guang
From: Priti Desai [mailto:priti_de...@symantec.com]
Sent: Tuesday, February 10, 2015 11:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] Proposing Marek Denis for the Keystone
Core Team
+1
Cheers
Priti
From: Brad Topol
+1!
> On Jan 18, 2015, at 3:17 PM, Jamie Lennox wrote:
>
> +1
>
> - Original Message -
>> From: "Morgan Fainberg"
>> To: "OpenStack Development Mailing List (not for usage questions)"
>>
>> Sent: Monday, 19 January, 2015 5:11:02 AM
>> Subject: [openstack-dev] [Keystone] Nominating Br
++ Amen, brother!
From: Lance Bragstad [mailto:lbrags...@gmail.com]
Sent: Tuesday, September 23, 2014 7:52 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [keystone] Stepping down as PTL
On Tue, Sep 23, 2014 at 3:51 AM, Thierry Carrez wrot
Hi Kristy,
Have you try the "[]" or "@" rule as mentioned here?
https://github.com/openstack/keystone/blob/master/keystone/openstack/common/
policy.py#L71
Guang
> -Original Message-
> From: K.W.S.Siu [mailto:k.w.s@kent.ac.uk]
> Sent: Tuesday, August 12, 2014 3:44 AM
> To: opensta
There's a HMAC-based generic signature authentication plugin patch which
should meet your needs.
https://review.openstack.org/#/c/40036/
Now the hard part, code review. :)
Guang
> -Original Message-
> From: Steven Hardy [mailto:sha...@redhat.com]
> Sent: Monday, December 09, 2013 2:34
It's just an extension, shouldn't be treated differently as long as it
follow the rules and regulations.
1. Bp
2. Spec (identity-api)
3. Server-side changes (keystone)
4. Client-side changes if any (python-keystoneclient)
If OpenStack security community is participati
Passing the query parameters, whatever they are, into the driver if the
given driver supports pagination and allowing the driver to override the
manager default pagination functionality seem reasonable to me.
Guang
From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Monday, Au
+1!
Guang
From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Tuesday, August 06, 2013 12:20 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] Proposing Morgan Fainberg for keystone-core
Through feedback on code reviews and blueprints, Morgan clearly has t
+1
Guang
-Original Message-
From: Henry Nash [mailto:hen...@linux.vnet.ibm.com]
Sent: Wednesday, June 19, 2013 8:48 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Inherited domain roles
Hi
So I don't doubt there are many ways of articulating the tar
Just out of curiosity, is there really a use case where user need to request
multiple tokens of the same scope, where the only difference are the
expiration dates?
Guang
From: Dolph Mathews [mailto:dolph.math...@gmail.com]
Sent: Wednesday, June 19, 2013 7:27 AM
To: OpenStack Developm
21 matches
Mail list logo
