Hi Adam
Kristy has already added support to Horizon for federated login to
Keystone. She will send you details of how she did this.
One issue that arose was this:
in order to give the user the list of IDPs/protocols that are trusted,
the call to Keystone needs to be authenticated. But the user
On 17/09/2014 14:55, Marek Denis wrote:
On 17.09.2014 15:45, Steve Martinelli wrote:
++ to your suggestion David, I think making the list of trusted IdPs
publicly available makes sense.
I think this might be useful in an academic/science world but on the
other hand most cloud
this would work as well, but wouldn't it require two different API calls?
On 17/09/2014 15:17, Adam Young wrote:
On 09/17/2014 10:07 AM, David Chadwick wrote:
On 17/09/2014 14:55, Marek Denis wrote:
On 17.09.2014 15:45, Steve Martinelli wrote:
++ to your suggestion David, I think making
/2014 15:14, Tim Bell wrote:
Has Kristy's patch made it into Juno ?
Tim
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: 17 September 2014 15:37
To: openstack-dev@lists.openstack.org; Kristy Siu
Subject: Re: [openstack-dev] [Keystone][Horizon] CORS
Tim
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: 17 September 2014 15:37
To: openstack-dev@lists.openstack.org; Kristy Siu
Subject: Re: [openstack-dev] [Keystone][Horizon] CORS and Federation
Hi Adam
Kristy has already added support to Horizon
) and other protocols which
should work by default from browsers.
[0]
https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/contrib/auth/v3/saml2.py#L29
Rest of the comments inlined.
On 17.09.2014 17:00, Adam Young wrote:
On 09/17/2014 10:35 AM, David Chadwick wrote
#L29
Rest of the comments inlined.
On 17.09.2014 17:00, Adam Young wrote:
On 09/17/2014 10:35 AM, David Chadwick wrote:
this would work as well, but wouldn't it require two different API
calls?
I think it would be 2 calls no matter what.
OK, lets talk this through:
1. Configure Horizon
Our recent work on federation suggests we need an improvement to the way
the policy engine works. My understanding is that most functions are
protected by the policy engine, but some are not. The latter functions
are publicly accessible. But there is no way in the policy engine to
specify public
On 18/09/2014 21:04, Doug Hellmann wrote:
On Sep 18, 2014, at 12:36 PM, David Chadwick
d.w.chadw...@kent.ac.uk wrote:
Our recent work on federation suggests we need an improvement to
the way the policy engine works. My understanding is that most
functions are protected by the policy
On 18/09/2014 22:14, Doug Hellmann wrote:
On Sep 18, 2014, at 4:34 PM, David Chadwick d.w.chadw...@kent.ac.uk
wrote:
On 18/09/2014 21:04, Doug Hellmann wrote:
On Sep 18, 2014, at 12:36 PM, David Chadwick
d.w.chadw...@kent.ac.uk wrote:
Our recent work on federation suggests we
Hi Doug
thanks. We will test this next week
regards
David
On 19/09/2014 18:43, Doug Hellmann wrote:
On Sep 19, 2014, at 6:56 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
On 18/09/2014 22:14, Doug Hellmann wrote:
On Sep 18, 2014, at 4:34 PM, David Chadwick d.w.chadw...@kent.ac.uk
Ack
On 09/12/2013 15:54, Tiwari, Arvind wrote:
Thanks David,
Let me update the etherpad with this proposal.
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Friday, December 06, 2013 2:44 AM
To: Tiwari, Arvind; Adam Young; OpenStack
On 09/12/2013 19:37, Adam Young wrote:
On 12/06/2013 04:44 AM, David Chadwick wrote:
Another alternative is to change role name into role display name,
indicating that the string is only to be used in GUIs, is not guaranteed
to be unique, is set by the role creator, can be any string in any
---
}
domain_id = --id--, (optional)
project_id = --id-- (optional)
}
}
Fields name, scope.id, domain_id and project_id makes the composite key.
-Original Message-
From: Adam Young [mailto:ayo...@redhat.com]
Sent: Monday, December 09, 2013 1:28 PM
To: David Chadwick
How about the following which clearly separates naming and scoping
constraints
{
role: {
id: 76e72a,
domain_id = --id--,(optional, if present, role is named by
specific domain)
project_id = --id--,(optional, if present, role is named
by project)
service_id =
or (any other
attribute) for role name uniqueness. So in particular deployment want
to keep just the role name unique, this model will not restrict you.
Thoughts?
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Tuesday, December
Whilst on this topic, perhaps we should also expand it to discuss
support for external authz as well. I know that Adam at Red Hat is
working on adding additional authz attributes as env variables so that
these can be used for authorising the user in keystone. It should be the
same module in
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
value.
On Oct 29, 2013, at 8:35 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Whilst on this topic, perhaps we should also expand it to discuss support for
external authz as well. I know that Adam at Red Hat is
working on adding additional authz attributes as env variables so
of the true mapper table, who's sole job was to map
IDP groups into something keystone understands (usually a keystone group, I
would suggest)
I think that's we decided..or is the memory fading already
Henry
On 13 Nov 2013, at 17:00, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Hi
Hi Arvind
I have just added some comments to your blueprint page
regards
David
On 19/11/2013 00:01, Tiwari, Arvind wrote:
Hi,
Based on our discussion in design summit , I have redone the service_id
binding with roles BP
.
Let me know your thoughts, please feel free to update below etherpad
https://etherpad.openstack.org/p/service-scoped-role-definition
Thanks again,
Arvind
-Original Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Monday, November 25, 2013 12:12 PM
...@gmail.com; David Chadwick
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
On 11/26/2013 06:57 PM, Tiwari, Arvind wrote:
Hi Adam,
Based on our discussion over IRC, I have updated the below etherpad with
proposal for nested role definition
Updated. I made my changes
, November 26, 2013 4:08 PM
To: David Chadwick; OpenStack Development Mailing List
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
Hi David,
Thanks for your time and valuable comments. I have replied to your
comments and try to explain why I am advocating to this BP
Thanks for your time,
Arvind
-Original Message-
From: Tiwari, Arvind
Sent: Monday, December 02, 2013 4:22 PM
To: Adam Young; OpenStack Development Mailing List (not for usage questions);
David Chadwick
Subject: Re: [openstack-dev] [keystone] Service scoped role definition
means admin for service x from the default domain
etc.
will that work?
regards
David
On 04/12/2013 15:04, Adam Young wrote:
On 12/04/2013 04:08 AM, David Chadwick wrote:
I am happy with this as far as it goes. I would like to see it being
made more general, where domains, services and projects
.
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, December 04, 2013
2:16 AM To: Tiwari, Arvind; OpenStack Development Mailing List (not
for usage questions); Adam Young Subject: Re: [openstack-dev]
[keystone] Service scoped
a model to accommodate more
specialized cases. You enhance the model to take the new functionality
into account, and preferably in a backwards compatible way.
regards
David
Thanks, Arvind
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday
Message-
From: David Chadwick [mailto:d.w.chadw...@kent.ac.uk]
Sent: Thursday, December 05, 2013 4:15 AM
To: Tiwari, Arvind; Adam Young; OpenStack Development Mailing List (not for
usage questions)
Cc: Henry Nash; dolph.math...@gmail.com; Yee, Guang
Subject: Re: [openstack-dev] [keystone
In preparation for and input to today's design summit session on
Authorisation at 11.50am, I thought it might be beneficial to remind
folks of the proposed design that was circulated by me at the end of the
long discussion on the format of a scoped role, that was held at the end
of last year on
Hi Everyone
at the Atlanta meeting the following slides were presented during the
federation session
http://www.slideshare.net/davidwchadwick/keystone-apach-authn
It was acknowledged that the current design is sub-optimal, but was a
best first efforts to get something working in time for the
On 14/10/2014 01:25, Nathan Kinder wrote:
On 10/13/2014 01:17 PM, Morgan Fainberg wrote:
Description of the problem: Without attempting an action on an
endpoint with a current scoped token, it is impossible to know what
actions are available to a user.
This is not unusual in the
Dave
when federation is used, the user's group is stored in a mapping rule.
So we do have a mechanism for storing group memberships without using
LDAP or creating an entry for the user in the SQL backend. (The only
time this is kinda not true is if we have a specific rule for each
federated user,
I agree with Morgan. We designed the current mapping functionality to
cover all the use cases we were aware of, but if there are more, then we
would love to hear about them and make the fixes that are necessary.
Attribute mapping is a critical component of federation, and it should
be fit for
Hi John
Its seems like your objective is somewhat different to what was intended
with the current mapping rules. You seem to want a general purpose
mapping engine that can map from any set of attribute values into any
other set of values, whereas the primary objective of the current
mapping rules
for the administrator to OK at a later time.
Users who try to hack in are blacklisted if they present a wrong secret
for 3 times.
Would this solve your problem?
regards
David
On 04/11/2014 15:30, John Dennis wrote:
On 11/04/2014 02:46 AM, David Chadwick wrote:
Hi John
Good morning David. I hope you're
I tend to agree with Morgan. There are resources and there are users.
And there is something in the middle that says which users can access
which resources. It might be an ACL, a RBAC role, or a set of ABAC
attributes, or something else (such as a MAC policy). So to my mind this
middle bit, whilst
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
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
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
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
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 -
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.
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
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
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
Hi guys
we now have the ABFAB federation protocol working with Keystone, using a
modified mod_auth_kerb plugin for Apache (available from the project
Moonshot web site). However, we did not change Keystone configuration
from its original SAML federation configuration, when it was talking to
SAML
Hi Adam
On 23/12/2014 17:34, Adam Young wrote:
On 12/23/2014 11:34 AM, David Chadwick wrote:
Hi guys
we now have the ABFAB federation protocol working with Keystone, using a
modified mod_auth_kerb plugin for Apache (available from the project
Moonshot web site). However, we did not change
On 23/12/2014 21:56, Morgan Fainberg wrote:
On Dec 23, 2014, at 1:08 PM, Dolph Mathews dolph.math...@gmail.com
mailto:dolph.math...@gmail.com wrote:
On Tue, Dec 23, 2014 at 1:33 PM, David
Chadwick d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
Hi Adam
On 23/12
HI John
On 24/12/2014 14:15, John Dennis wrote:
Can't this be solved with a couple of environment variables? The two
keys pieces of information needed are:
1) who authenticated the subject?
AUTH_AUTHORITY or similar would stop wrong configuration of Apache if it
was set by the protocol
for
different URLs.
The second step, still in progress, is to include an ID in the IdP
configuration. My patch is under review here:
https://review.openstack.org/#/c/142743/
Let me know if it is enough to solve the issue in your case.
Marco
On 24 Dec 2014, at 10:08, David Chadwick d.w.chadw
.
This is not a huge change to make, in fact it should be a rather simple
re-engineering task.
regards
David
On 24/12/2014 17:50, Marco Fargetta wrote:
On 24 Dec 2014, at 17:34, David Chadwick d.w.chadw...@kent.ac.uk wrote:
If I understand the bug fix correctly, it is firmly tying the URL
solution.
Cheers,
-Adrian
On 15/01/15 21:20, David Chadwick wrote:
Hi Adrian
Morgan is right in saying that an external IdP would solve many of your
user management problems, but then of course, you will be using
federated keystone which you seem reluctant to do :-) However, if you
it easy for users to start doing real work.
Regards,
Brad
On 1/19/15, 10:03 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Hi Enrique
You are right in that we have been addressing different problems. There
are three aspects to managing users: registration, assigning
,
Enrique Garcia Navalon
On 16 January 2015 at 15:12, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
The VO code exists already, as does a public demo (see my original email
for details). I gave demos to the Keystone core in Paris last November.
How
I think this GUI is not intuitive to users and therefore should not be
encouraged or supported.
If you ask a user what does authenticate via a Discovery Service mean?
I think you will get some very strange answers. The same goes for
Authenticate using Default Protocol. Users will have no idea
Hi Adrian
You might be glad to know that we have already produced a blueprint and
implementation for this, based on federated keystone and Horizon. You
can read the specs here
https://blueprints.launchpad.net/keystone/+spec/vo-management
and see a demo here
http://icehouse.sec.cs.kent.ac.uk/
implementers accept
that the current design is poor and needs re-engineering, then I will be
happy to propose a new design
regards
David
Marco
On Fri, Jan 02, 2015 at 09:51:55PM +, David Chadwick wrote:
Hi Marco
I think the current design is wrong because it is mixing up
In my opinion you have got into this situation because your federation
trust model is essentially misguided. As I have been arguing since the
inception of federated Keystone, you should have rules for trusted IdPs
(already done), trusted attributes (not done), and then one set of
mapping rules
Encryption per se does not decrease token size, the best it can do is
keep the token size the same size. So using Fernet tokens will not on
its own alter the token size. Reducing the size must come from putting
less information in the token. If the token recipient has to always go
back to Keystone
Hi Adam
prior art is the publish-subscribe mechanism. I dont know if Keystone
already has this implemented or not, or if Python implementation exists
or not, without doing some research
regards
David
On 16/03/2015 18:08, Sumit Naiksatam wrote:
On Mon, Mar 16, 2015 at 8:10 AM, Adam Young
. With this mechanism we should be able to create
a rule for multiple IdPs as well.
Guang
-Original Message- From: David Chadwick
[mailto:d.w.chadw...@kent.ac.uk] Sent: Wednesday, March 18, 2015 2:41
AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev]
[Keystone][FFE] - IdP ID
screen, and
this summer I am hoping to have another student integrate this into the
current release, as well as make some enhancements to it (like
type-ahead searching for IdPs)
regards
David
On 23/02/2015 15:54, Adam Young wrote:
On 02/18/2015 12:02 PM, David Chadwick wrote:
I think this GUI
Hi Tim
On 06/05/2015 21:53, Tim Hinrichs wrote:
I wondered if we could properly protect the API call for adding a new
Role using the current mechanism. So I came up with a simple example.
Suppose we want to write policy about the API call: addRole(user,
role-name). If we’re hosting both
it, there is no limitation on the number of
roles that can be defined in OpenStack.
regards
David
On 08/05/2015 15:52, Tim Hinrichs wrote:
Hi David,
See below.
On 5/7/15, 1:01 AM, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Hi Tim
On 06/05/2015 21:53, Tim Hinrichs wrote:
I wondered if we could
On 03/06/2015 19:55, Sean Dague wrote:
On 06/03/2015 02:44 PM, David Chadwick wrote:
In the design that we have been building for a policy administration
database, we dont require a single policy in order to unify common
concepts such as hierarchical attributes and roles between
delimiter. Each domain would define
its own and this would be carried in the JSON as a separate parameter so
that the recipient can tell how to parse hierarchical names
David
Henrique
Em qua, 3 de jun de 2015 às 04:21, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk
In the design that we have been building for a policy administration
database, we dont require a single policy in order to unify common
concepts such as hierarchical attributes and roles between the different
policies of Openstack services. This is because policies and hierarchies
are held
model for the right task. Using the wrong model will lead to
either over complication (DoA when subcontracting is sufficient) or
security vulnerability (subcontracting when DoA is needed)
regards
David
On 08/06/2015 15:10, Adam Young wrote:
On 06/06/2015 06:00 AM, David Chadwick wrote:
In order
Hi Jamie
I think if we are going for hierarchical names we should do it properly
in one go ie. have a recursive scheme that allows infinite nesting of
name components, and then it will solve all current and future problems.
Having a half baked scheme which only allows one level of nesting, or
that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 03/06/2015 14:54, Henrique Truta wrote:
Hi David,
You mean creating some kind of delimiter attribute
On 06/05/2015 10:39 AM, Dolph Mathews wrote:
On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
I did suggest another solution to Adam whilst we were in Vancouver, and
this mirrors what happens
On 02/06/2015 23:34, Morgan Fainberg wrote:
Hi Henrique,
I don't think we need to specifically call out that we want a domain, we
should always reference the namespace as we do today. Basically, if we
ask for a project name we need to also provide it's namespace (your
option #1). This
I did suggest another solution to Adam whilst we were in Vancouver, and
this mirrors what happens in the real world today when I order something
from a supplier and a whole supply chain is involved in creating the end
product that I ordered. This is not too dissimilar to a user requesting
a new
[mailto:ayo...@redhat.com]
Sent: Wednesday, June 3, 2015 4:39 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone] [nova] [oslo] [cross-project] Dynamic
Policy
On 06/03/2015 02:55 PM, Sean Dague wrote:
On 06/03/2015 02:44 PM, David Chadwick wrote:
In the design
the delimiter / set the delimiter when
creating a domain is likely to make for a worse user experience than
selecting one that is not different across installations.
--Morgan
On Wed, Jun 3, 2015 at 12:19 PM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote
the values in the horizon settings (idp+protocol)
But, it's already in keystone.
Thanks,
Steve Martinelli
OpenStack Keystone Core
Dolph Mathews ---2015/08/05 01:38:09 PM---On Wed, Aug 5, 2015 at 5:39 AM,
David Chadwick d.w.chadw...@kent.ac.uk wrote:
From: Dolph Mathews dolph.math
Hi Lance
On 12/08/2015 18:55, Lance Bragstad wrote:
On Wed, Aug 12, 2015 at 12:06 PM, David Chadwick
d.w.chadw...@kent.ac.uk mailto:d.w.chadw...@kent.ac.uk wrote:
On 11/08/2015 01:46, Jamie Lennox wrote:
- Original Message -
From: Jamie Lennox
Hi Jamie
see
http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf
regards
David
On 13/08/2015 02:06, Jamie Lennox wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk To:
openstack-dev@lists.openstack.org Sent: Thursday, 13 August
I would also like a spec proposal freeze exception, but not if this
leads to a rushed design and a poor implementation that will need to be
fixed again during the next cycle. Its far better to get the right
design now, even if it means missing the liberty release, than to
implement a suboptimal
On 13/08/2015 02:22, Jamie Lennox wrote:
- Original Message -
From: David Chadwick d.w.chadw...@kent.ac.uk To:
openstack-dev@lists.openstack.org Sent: Thursday, 13 August, 2015
7:46:54 AM Subject: Re: [openstack-dev] [Keystone] [Horizon]
Federated Login
Hi Jamie
I have
:
Hi David,
On 29.07.2015 18:59, David Chadwick wrote:
this is very helpful thanks, and it answers our question.
So to summarise, you can map a federated user into multiple
groups, or
into an existing local user/domain, but not into both, since the
latter
Hi Everyone
I have a student building a GUI for federated login with Horizon. The
interface supports both a drop down list of configured IDPs, and also
Type Ahead for massive federations with hundreds of IdPs. Screenshots
are visible in InVision here
https://invis.io/HQ3QN2123
All comments on
Hi All
Ioram has built a complete set of wireframe policy GUI screens for
comment. He has uploaded them to InVision
https://openstack.invisionapp.com/share/HQ3QN2123#/screens
Please comment on these in InVision
regards
David
On 03/08/2015 21:39, Lin Hua Cheng wrote:
Hi Timur,
Thanks for
for getting a
list of Identity Providers from Keystone
http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers
Doug Fish David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015
06:01:48 AM: From: David Chadwick
for getting a list of Identity Providers from Keystone
_http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html#list-identity-providers_
Doug Fish
David Chadwick _d.w.chadw...@kent.ac.uk_
mailto:d.w.chadw...@kent.ac.uk wrote on 08/01
://docs.openstack.org/developer/keystone/extensions/websso.html
[3] https://review.openstack.org/#/c/199339/
https://review.openstack.org/#/c/199339/
On Sat, Aug 1, 2015 at 4:01 AM, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
Hi Everyone
I have a student
general for all
sorts of lists of entities?
regards
David
On 11/08/2015 10:55, Jesse Pretorius wrote:
On 6 August 2015 at 10:02, David Chadwick d.w.chadw...@kent.ac.uk
mailto:d.w.chadw...@kent.ac.uk wrote:
this is a value judgement that admins take. I think we should allow
?
No, Horizon uses the Keystone API
regards
David
Doug Fish
David Chadwick d.w.chadw...@kent.ac.uk wrote on 08/01/2015 06:01:48 AM:
From: David Chadwick d.w.chadw...@kent.ac.uk
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: 08/01/2015 06:05 AM
Subject
1 - 100 of 121 matches
Mail list logo