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
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
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
++!
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:
under
that umbrella.
Henry
On 13 Jul 2015, at 19:20, Yee, Guang
guang@hp.commailto: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
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
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-
++
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
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
MetadataProvider type=Chaining
MetadataProvider type=XML
++
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
+1!
On Jan 18, 2015, at 3:17 PM, Jamie Lennox jamielen...@redhat.com wrote:
+1
- Original Message -
From: Morgan Fainberg morgan.fainb...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Sent: Monday, 19 January, 2015
++ 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
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: openstack
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
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,
16 matches
Mail list logo
