[openstack-dev] [Keystone] New Policy Administration Service

[Ioram Schechtman Sette]

Hi all,

In Paris, on the last day, we listed the new features that we would like to
see in the next release of Keystone.
The top 3 were chosen as high priority.

Further down the list was a policy administration service that will collect
policies from all the Openstack services and allow the Keystone
administrator to ask the question "what role do I need to assign to a user
to give access to these services?" and will allow users to ask the question
"what can I access with my roles?".

We have now started to design and build this service. An important design
decision is "should this service be integrated with Keystone or be a
separated standalone Openstack service?" What does the Keystone group think?

If policy administration should be a separate service, what is the process
to register blueprints, apis and code reviews?

Regards,
Ioram and David
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Keystone] [Horizon] Attribute Mapping GUI for Horizon

[Ioram Schechtman Sette]

Hi Marek,

Done. ;)

Regards,
Ioram


2015-08-03 8:07 GMT+01:00 Marek Denis :

> Hi Ioram,
>
> How about moving this discussion to the mailing list? Maybe others will
> find it useful too.
>
> cheers,
> Marek
>
> On 02.08.2015 11:28, Ioram Schechtman Sette wrote:
>
>> Hi Marek, hi all,
>>
>> Just to complement, I thought in some cases that I don't know how they
>> are handled by the mapping engine.
>>
>> For instance:
>>
>>  - Remote attribute "a1" with value "v1" maps to domain/user "D1/U1"
>>  - Remote attribute "a2" with value "v2" maps to domain/user "D1/U2"
>>
>>  If the remote user has the attributes "a1=v1" and "a2=v2", will he
>> be mapped to D1/U1 or D1/U2?
>>
>> The situation can be repeated for different combinations of local users
>> and groups.
>>
>> Using the super set (union) of the privileges of D1/U1 and D1/U2 to the
>> remote user, I think it solves the problem.
>> According to this reasoning, the expression "local": {"user": {"name":
>> "{0}"}} will mean that we will search for a local user whose name
>> matches the remote user id in order to get its privileges.
>> The set of privileges can be increased if other mapping rules also
>> matches to other users or groups.
>>
>> Regards,
>> Ioram
>>
>>
>> 2015-07-30 17:32 GMT+01:00 David Chadwick > <mailto:d.w.chadw...@kent.ac.uk>>:
>>
>>
>> Hi Marek
>>
>> Thanks for the clear exposition.
>>
>> To answer your question Why are you interested in such a feature? is
>> that it seemed to be the logical thing to do. A user is identified by
>> a
>> set of identity attributes (by the IdP) and these are mapped into
>> permission by mapping rules. I assume the admin who sets up the
>> mapping
>> rules knows what he is doing, and if he wants a remote user to have
>> the
>> privileges of a local user plus some more, then the easiest way to do
>> this would be to map into one or more groups plus the local user.
>>
>> Since the same thing can be achieved by creating a new group
>> equivalent
>> to the local user, and mapping the remote user into all of these
>> groups,
>> then why downgrade the most logical (and easiest) way of achieving the
>> same ultimate objective?
>>
>> regards
>>
>> David
>>
>>
>> On 30/07/2015 11:26, Marek Denis wrote:
>>  > 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
>>  >> will override the former and the groups will be discarded. Was
>> this
>>  >> behaviour actually discussed anywhere? ie. why cannot a
>> federated user
>>  >> have a superset of the permissions of a local user and some
>> additional
>>  >> groups?
>>  >
>>  > Well, it was mostly discussed at one of the Keystone midcycles, I
>> think
>>  > the one in January. The spec for this (along with new keyword
>>  > 'whitelist' and 'blacklist') can be found here:
>>  >
>>
>> https://github.com/openstack/keystone-specs/blob/master/specs/kilo/federated-direct-user-mapping.rst
>>  >
>>  >
>>  > And to answer your question "why a federated user cannot have a
>> superset
>>  > of the permissions of a local user and some extras" is probably
>> because
>>  > we wanted to simply leverage authentication to IdP, not create any
>>  > superpower user. Also, it is because the returned identity is
>> 'existing
>>  > user', with her/his id, set of role assignments on a
>> project/domain. I
>>  > am not sure it's good to be able to dynamically upgrade average
>> users -
>>  > if so, i'd rather make 'ephemeral users with all the role
>> assignments
>>  > equal to user X'.
>>  > Why are you interested in such a feature? We can probably discuss
>> it on
>>  > a ML a

Re: [openstack-dev] [Keystone] [Horizon] UI for Keystone dynamic policies editing

[Ioram Schechtman Sette]

Hi All,

The correct link is:
https://openstack.invisionapp.com/share/9Z3RI8OD7#/screens

Regards,
Ioram

2015-08-04 11:42 GMT+01:00 David Chadwick :

> 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 bringing this up.
> >
> > I think we can borrow some concept from the Mistral Workbook Builder. I
> > like the ability to add items and seeing the preview on the right side.
> > We can re-use that part.
> >
> > The challenging part would be building a Rule expression builder that
> > supports the policy semantic [1] [2]. We should start with creating some
> > mockups.  The builder will also be useful even if we don't land the
> > dynamic policy in L by adding support of loading local policy files for
> > editing and providing export functionality.
> >
> > I imagine there would be a pop-up that will allow user to build the
> > expression with support for:
> > 1. Building nested expression using AND OR and ()
> > 2. Auto-complete that lists:
> > -  existing rule definition
> > -  available context variable (like domain_id, user_id, target.token)
> >
> > Just throwing some ideas around.
> >
> > This is a good opportunity to engage the new UX project they might have
> > a better idea how the Expression Builder should look like. :)
> >
> > Thanks,
> > Lin
> >
> > [1]
> >
> https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L18-L210
> > [2]
> >
> http://docs.openstack.org/kilo/config-reference/content/policy-json-file.html
> >
> >
> > On Mon, Aug 3, 2015 at 5:10 AM, Timur Sufiev  > > wrote:
> >
> > Hello, folks!
> >
> > A word has come to me that on the recent Keystone mid-cycle summit
> > dynamic policies have been discussed - as well as the lack of means
> > to edit them in UX-friendly manner. I had my own share of editing
> > *_policy.json files inside openstack_dashboard/conf and can hardly
> > state it's easy. At least, when dynamic policies are fully supported
> > by all OpenStack services we will have no longer to edit the same
> > files on every controller node in case of HA installations. Still,
> > the problem of editing a single policy file remains. AFAIK, the
> > obscurity of policy rules' format had lead may deployers to the
> > copy-pasting existing rules with minimal changes - when they were
> > meant to a flexible tool for RBAC definitions.
> >
> > But I wouldn't write this letter, if I didn't have some kind of
> > solution to the task of editing the policies. During my work on
> > Merlin framework/Mistral Workbook Builder I've achieved some results
> > that might be useful for a Keystone community. More specifically,
> > visual structure and type of relations between Workbook entities
> > appeared to me to be similar to the entities of Keystone policies.
> > Understanding that some things are better seen in dynamic than in
> > static screenshots, I'm sharing the address of the VM where the
> > Workbook builder is deployed inside
> > Horizon: http://horizon-merlin.mirantis.com/horizon/project/
> > Credentials are demo/demo. Some features like saving the workbooks
> > to db or the rest OpenStack control plane are disabled for security
> > reasons, leaving only the Workbook Builder UI there.
> >
> > I'd like to start the discussion about the extent of reusing Merlin
> > UI elements for making a dynamic policies editor.
> >
> >
>  __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/opens

Re: [openstack-dev] [horizon][keystone]

[Ioram Schechtman Sette]

Hi Thai,

I agree with Anton that the names are not intuitive for users.

I would use something like:
- Local authentication (for local credentials)
- ?? (I also have no idea of what is a Default protocol)
- Authenticate using  (something which is easy
to the user understand that he could use or not - this is for the discovery
service or remote IdP)

Here in the University of Kent we used another approach.
Instead of selecting the method using a "list/combo" box, we present all
the options in a single screen.
I think it's not beautiful, but functional.
I think it would be easier to the user if they could have all the options
in a single interface, since it doesn't become too much loaded (visually
polluted).

[image: Imagem inline 1]
Regards,
Ioram


2015-02-05 9:20 GMT+00:00 Anton Zemlyanov :

> Hi,
>
> I guess "Credentials" is login and password. I have no idea what is
> "Default Protocol" or "Discovery Service".
> The proposed UI is rather embarrassing.
>
> Anton
>
> On Thu, Feb 5, 2015 at 12:54 AM, Thai Q Tran  wrote:
>
>> Hi all,
>>
>> I have been helping with the websso effort and wanted to get some
>> feedback.
>> Basically, users are presented with a login screen where they can select:
>> credentials, default protocol, or discovery service.
>> If user selects credentials, it works exactly the same way it works today.
>> If user selects default protocol or discovery service, they can choose to
>> be redirected to those pages.
>>
>> Keep in mind that this is a prototype, early feedback will be good.
>> Here are the relevant patches:
>> https://review.openstack.org/#/c/136177/
>> https://review.openstack.org/#/c/136178/
>> https://review.openstack.org/#/c/151842/
>>
>> I have attached the files and present them below:
>>
>>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] Issue on adding or removing itself to/from a group

[Ioram Schechtman Sette]

Hi all,

I'm currently working on the virtual organisations (VO) management code and
I would like to add the functionallity that when a user creates a VO Role,
he automatically joins it.
Since VO Roles are represented as Groups, I need to create a new group and
add my user into it.

I that when I call the methods *add_user_to_group* and
*remove_user_from_group* from the identity_api, I get my token invalidated
and receive the following error message:

[Thu Feb 19 00:41:23 2015] [error] 11764 WARNING keystone.middleware.core
[-] RBAC: Invalid token
[Thu Feb 19 00:41:23 2015] [error] 11764 WARNING keystone.common.wsgi [-]
The request you have made requires authentication. (Disable debug mode to
suppress these details.)

I have also tested using
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] Issue on adding or removing itself to/from a group

[Ioram Schechtman Sette]

Hi all,

My previous message was sent incomplete. Sorry for that. Here it is the
correct one.

I'm currently working on the virtual organisations (VO) management code and
I would like to add the functionallity that when a user creates a VO Role,
he automatically joins it.

Since VO Roles are represented as Groups, I need to create a new group and
add my own user into it.

I have noticed that when I call the methods *add_user_to_group* and
*remove_user_from_group* from the identity_api, the actions are performed
correctly, but I get my token invalidated and receive the following error
message:

[Thu Feb 19 00:41:23 2015] [error] 11764 WARNING keystone.middleware.core
[-] *RBAC: Invalid token*
[Thu Feb 19 00:41:23 2015] [error] 11764 WARNING keystone.common.wsgi [-]
The request you have made requires authentication. (Disable debug mode to
suppress these details.)

I have also tested using the original horizon UI for adding and removing
users to groups and tried to remove my own user from a group.
I got exaclty the same behaviour, so I think the problem is not related to
my code.

Does anyone know if this is the expected behaviour?

I think that maybe because the groups can be associated to roles, this
roles should be added to or removed from the token.
Therefore, the token needs to be replaced by a new one with new privileges.
But, I think this could be done automatically, instead of invalidating the
old ones and forcing the users to log out and in.

Does it make sense to you?
Is there an easy way to avoid the token to be invalidated?

PS: I'm still working on the icehouse version, so this issue can already be
addressed in newer releases.

Regards,
Ioram Sette
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev