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
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 w
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.
On Tue, Nov 4, 2014 at 10:30 AM, John Dennis 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 yield a group
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 w
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
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
On 11/03/2014 05:52 AM, David Chadwick wrote:
> 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 c
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 purpo
> On Nov 2, 2014, at 22:21, Dolph Mathews wrote:
>
>> On Sunday, November 2, 2014, John Dennis 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
On Sunday, November 2, 2014, John Dennis 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 in this PDF.
>
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 Se
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
While working on federated authentication for a different project
(OpenDaylight) we discovered we needed to map from the assertion
provided by an external federated IdP to local values. This is
essentially the same requirement which exists in Keystone's federated
support. It was hoped we could simp
14 matches
Mail list logo