What is the semantic of domain in the current implementation? Until we
know this we cant devise a solution.
Will the developed solution cater for me logging in via Google using my
kent email address (as opposed to my gmail one)? In this case there
could be 2 domains (depending upon the
On 12/09/2013 16:55, Dolph Mathews wrote:
On Thu, Sep 12, 2013 at 3:15 AM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
On 11/09/2013 22:05, Adam Young wrote:
What's the use case for including providers in the service
catalog
On 12/09/2013 04:46, Dolph Mathews wrote:
On Wed, Sep 11, 2013 at 10:25 PM, Jamie Lennox jlen...@redhat.com
mailto:jlen...@redhat.com wrote:
With the aim of replacing httplib and cert validation with requests[1]
I've put forward the following review to use the requests library for
it is cut and paste into
each protocol specific module.
Comments?
David
On 11/09/2013 16:25, Adam Young wrote:
David Chadwick wrote up an in depth API extension for Federation:
https://review.openstack.org/#/c/39499
There is an abfab API proposal as well:
https://review.openstack.org/#/c
On 11/09/2013 19:05, Dolph Mathews wrote:
On Wed, Sep 11, 2013 at 12:31 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
Further supplementary information to Adam's email below, is that
there are already one further federation protocol profiles
If delegation (trusts) were enhanced to be role based, then anyone with
the same role as the initial delegator should be able to revoke the
delegation
regards
David
On 04/09/2013 05:02, Clint Byrum wrote:
Excerpts from Dolph Mathews's message of 2013-09-03 16:12:00 -0700:
On Tue, Sep 3,
you can always do anything by impersonating the user. This is why
impersonation should never be sanctioned
david
On 04/09/2013 11:45, Steven Hardy wrote:
Ok, apologies, after further testing, it appears I made a mistake and you
*can* delete the trust by impersonating the user.
as a general principle I would think it is a good idea for clients to be
able to interrogate Keystone to determine what extensions it supports.
Most protocols have some mechanism for determining what
extensions/versions are supported by the server, and what optional
features are implemented.
On 06/08/2013 14:46, Jay Pipes wrote:
API extensions are more hassle than anything else. Let us promote
standards, not endless extensibility at the expense of usability.
This is the crux of the issue. Everyone who participates in
standardisation meetings has their own agenda to follow:
On 06/08/2013 16:53, Jay Pipes wrote:
On 08/06/2013 10:45 AM, David Chadwick wrote:
On 06/08/2013 14:46, Jay Pipes wrote:
API extensions are more hassle than anything else. Let us promote
standards, not endless extensibility at the expense of usability.
This is the crux of the issue
On 06/08/2013 18:11, Jay Pipes wrote:
What SMTP, DNS and LDAP extensions are in use by systems that need to
interoperate in the same way that Keystone does? -- This is a genuine
question, not sarcasm. I'm truly curious.
Take SMTP for example. My Thunderbird client needs to know what
On 06/08/2013 20:40, Clint Byrum wrote:
Agreed Jay. The successful extensible protocols like IMAP and SMTP are
merely allowing new arguments to existing fundamental functions.
But the key thing with these protocols is that they have a defined and
standardised way of adding new extensions -
or not
regards
David
Henry
On 23 Jul 2013, at 18:31, Adam Young wrote:
On 07/23/2013 12:54 PM, David Chadwick wrote:
When writing a previous ISO standard the approach we took was as follows
Lie to people who are not authorised.
Is that your verbage? I am going to reuse that quote, and I would
and identity:revoke_token APIs
https://bugs.launchpad.net/keystone/+bug/1186059
Due to absence of a target on such API calls Auth is not possible, I
would appreciate community's thoughts on the bug.
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Thursday
When writing a previous ISO standard the approach we took was as follows
Lie to people who are not authorised.
So applying this approach to your situation, you could reply Not Found
to people who are authorised to see the object if it had existed but
does not, and Not Found to those not
Hi Henry
using the XACML processing model, the functionality that you are
describing, which you say is currently partly missing from Keystone, is
that of the context handler. Its job is to marshall all the attributes
that are needed and put them into the request context for calling the
policy
On 23/07/2013 18:36, Adam Young wrote:
On 07/23/2013 01:17 PM, David Chadwick wrote:
Of course the tricky thing is knowing which object attributes to fetch
for which user API requests. In the general case you cannot assume
that Keystone knows the format or structure of the policy rules
On 23/07/2013 18:31, Adam Young wrote:
On 07/23/2013 12:54 PM, David Chadwick wrote:
When writing a previous ISO standard the approach we took was as follows
Lie to people who are not authorised.
Is that your verbage? I am going to reuse that quote, and I would like
to get the attribution
David
Henry
On 23 Jul 2013, at 18:31, Adam Young wrote:
On 07/23/2013 12:54 PM, David Chadwick wrote:
When writing a previous ISO standard the approach we took was as follows
Lie to people who are not authorised.
Is that your verbage? I am going to reuse that quote, and I would
like to get
Martinelli | A4-317 @ IBM Toronto Software Lab
Software Developer - OpenStack
Phone: (905) 413-2851
E-Mail: steve...@ca.ibm.com
Inactive hide details for David Chadwick ---06/19/2013 04:38:56 PM--- Hi
Steve On 19/06/2013 20:56, Steve Martinelli wrote:David Chadwick
---06/19/2013 04:38:56 PM--- Hi
Hi Adam
if you do it at role assignment time, I think the newly assigned role
should be marked as implicit/inherited to differentiate it from an
explicitly assigned role. In this way, if the inheritance is
subsequently removed, then the inherited assignment can also be deleted
at the same
101 - 121 of 121 matches
Mail list logo
