We started an etherpad to gather requirements etc:
https://etherpad.openstack.org/p/mapping-engine-enhancements
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 11/04/2014 02:46 AM, David Chadwick wrote:
Hi John
Good morning David. I hope you're enjoying Paris and the summit is both
productive and enjoyable. Wish I was there :-)
Its seems like your objective is somewhat different to what was intended
with the current mapping rules. You seem to
On Tue, Nov 4, 2014 at 10:30 AM, John Dennis jden...@redhat.com wrote:
O.K. group assignment is the final goal in Keystone. I suppose the
relevant question then is the functionality in the current Keystone
mapper sufficiently rich such that you can present to it an arbitrary
set of values and
On 11/04/2014 04:19 PM, David Stanek wrote:
There are probably a few other assumptions, but the main one is that the
mapper expects the incoming data to be a dictionary where the value is a
string. If there are multiple values we expect them to be delimited with
a semicolon in the string.
and
Hi John
there is another way of tackling this problem, based on the following
assumption We know the person who should be authorised, but we dont
know what random set of attributes the IDP will provide for him (or if
we do know, they are as horrible as you indicated in your example below).
We
On Nov 2, 2014, at 22:21, Dolph Mathews dolph.math...@gmail.com wrote:
On Sunday, November 2, 2014, John Dennis jden...@redhat.com wrote:
It was hoped we could simply borrow the Keystone mapping
implementation but it was found to be too limiting and not sufficiently
expressive. We could
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
On 11/03/2014 08:50 AM, John Dennis wrote:
I had a bunch of notes but I can't find them at the moment
so I'm going from memory here (always a bit risky).
I found my notes, attached is an reStructured text document that
summarizes the issues I found with the current Keystone mapping, the
basic
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
Hi John,
It indeed looks interesting and enhancing the mapping engine is on ours
to-do list for a long time. I'd be happy to talk this through during the
summit. Do you think you will be able to come for a Keystone
websso/federation Design Session on Wednesday at 16.30?
Thanks,
Marek
On
On 11/02/2014 03:55 PM, Marek Denis wrote:
Hi John,
It indeed looks interesting and enhancing the mapping engine is on
ours to-do list for a long time. I'd be happy to talk this through
during the summit. Do you think you will be able to come for a
Keystone websso/federation Design Session
On Sunday, November 2, 2014, John Dennis jden...@redhat.com wrote:
It was hoped we could simply borrow the Keystone mapping
implementation but it was found to be too limiting and not sufficiently
expressive. We could not find another alternative so we designed a new
mapper which is described
12 matches
Mail list logo
