Ask Your Question

pentatonic's profile - activity

2017-02-10 04:09:10 -0500 received badge  Notable Question (source)
2016-11-07 14:46:56 -0500 received badge  Famous Question (source)
2016-10-27 10:53:43 -0500 received badge  Popular Question (source)
2016-10-24 14:55:52 -0500 asked a question Keystone inexact filters name__icontains etc.

The Keystone api for /v3/users has a set of very useful query parameters which are undocumented yet seem to be working well.

name__icontains, name__contains, name__startswith, name_endswith etc.

They come very handy in situations where despite the use of the domain config ldap filters, the number of users being returned is still very large and causes Keystone performance/timeout issues.

Is there any plan to officially "surface"/document these ?

2016-06-01 10:31:37 -0500 received badge  Famous Question (source)
2016-05-04 09:27:59 -0500 received badge  Notable Question (source)
2016-05-04 09:27:59 -0500 received badge  Popular Question (source)
2016-03-12 20:22:28 -0500 received badge  Notable Question (source)
2016-03-12 18:49:43 -0500 received badge  Popular Question (source)
2016-03-11 15:51:58 -0500 asked a question Identity api 3.6

Will Mitaka include identity api 3.6? Current trunk has 3.5 but 3.6 spec is available.

2016-03-11 10:30:54 -0500 asked a question LDAPs updating tls_cacertfile and tls_req_cert on the fly

I have been testing the Keystone behavior (with trunk Mitaka of a week ago or so) related to LDAPs integration. Most specifically playing with turning certificate validation on/off, and placing the correct or incorrect ca certificate in the location pointed at by the tls_cacertfile parameter of the domain config api.

What I noticed is that while I can dynically update:
"url": "ldaps://192.168.228.1:10636",
"tls_cacertfile": "/etc/keystone/ldapcerts/ldap.pem", #toggle between no file, correct file, incorrect file "tls_req_cert": "demand" # toggle between allow, never, demand

and have the domain config correctly updated and reloaded, the behavior is not consistent. Or more exactly, trust wise, it is stuck on the last behavior encountered by Keystone the last time it talked to that server.

For example, set: "url": "ldaps://192.168.228.1:10636",
"tls_cacertfile": "", # empty path "tls_req_cert": "never"

--> as expected, connection is ok because I set "never".

I now switch to: "url": "ldaps://192.168.228.1:10636",
"tls_cacertfile": "/etc/keystone/ldapcerts/ldap.pem", # incorrect file or bogus "tls_req_cert": "demand"

--> connection continues to work even though I switched to demand and put a fake file in place.

After Keystone restart, things work as expected (fail with the bad cert, then after I put the good cert in place and restart again, works).

The point is: unless Keystone is restarted, the trust behavior is unreliable. I was hoping that the domain config REST api being dynamic, I would expect the trust behavior to follow suit.

Do you know if this is a bug or a limitation of the implementation (which perhaps has ssl contexts already initialized and not able to "reload" or invalidate them on the fly)

2016-03-08 09:35:04 -0500 asked a question Custom identity drivers in Mitaka

Since Keystone does not provide password complexity rules for local users (sql driver), I was experimenting with writing my own, extending the existing. I'm having this basic problem: how do you configure your driver to be picked up in /etc/keystone/keystone.conf?

You used to be able to say: driver = keystone.identity.backends.[sql | yourcustom module here].Identity

But now with the shortcut syntax: driver = sql

I'm not sure how to map to a custom driver. Something like this doesn't work: driver = keystone.identity.backends.sql2.Identity

I get this at runtime: line 30, in import_class [Tue Mar 08 07:27:06.227535 2016] [:error] [pid 7613] [remote 192.168.228.127:68] __import__(mod_str) [Tue Mar 08 07:27:06.227591 2016] [:error] [pid 7613] [remote 192.168.228.127:68] ImportError: No module named sql2

2015-10-15 15:40:56 -0500 asked a question Identity api 3.6 and openstack release

I'm looking to play with the Identity API 3.6 but unsure which release packages it. I installed devstack stable/liberty today 10.15.15. API version reports 3.4.

Would the master/trunk version get me liberty+ and include 3.5 and 3.6 api changes?

2015-08-12 16:01:38 -0500 commented question How to use OS-INHERIT in keystone

Interestingly, this works with groups. In other words, if I do a PUT /v3/OS-INHERIT/domains/d/groups/g/roles/x then, a user from that group g can get a project scoped token with role x in any project of domain d.

It doesn't seem to be working when using the inherited grant on users directly

2015-08-11 02:45:50 -0500 received badge  Famous Question (source)
2015-08-10 19:55:08 -0500 received badge  Notable Question (source)
2015-08-10 14:27:41 -0500 received badge  Popular Question (source)
2015-08-10 10:57:14 -0500 asked a question How to use OS-INHERIT in keystone

Using Kilo, I'm looking for a way to automatically have all roles assigned in all domains inherited to all users and groups in the respective projects. In other words, I'd like to have to have full inheritance work without having to assign role inheritance for individual users and groups, per domain. I'm looking at and following this spec page, which seems to give me what I'm looking for: http://specs.openstack.org/openstack/...

I'm having some problem getting OS-INHERIT to work. I enabled the os_inherit extension in the keystone.conf file.

I'm able to PUT a project role inheritance record but not get it back.

PUT: https://{{host}}:{{port}}/v3/OS-INHERIT/domains/288b1c4d3f7b43a4b8708016d9ae3ec5/users/257cc461fde84f8aac1af1b42a7314f2/roles/daa86839ba154426ad34a95975d2d188/inherited_to_projects

(I noticed though that it validates domain, roles, but not user. The PUT succeeds if I put an invalid user.)

HEAD on the same path above returns 404. Also, this

 GET: https://{{host}}:{{port}}/v3/OS-INHERIT/domains/288b1c4d3f7b43a4b8708016d9ae3ec5/users/257cc461fde84f8aac1af1b42a7314f2/roles/inherited_to_projects

returns 200, but an empty list of roles.

So somehow, the PUT doesn't stick, I'm not sure why. Consequently, I'm also not able to get a project token with expected roles from the domain etc.

2015-07-10 13:26:46 -0500 received badge  Notable Question (source)
2015-07-07 21:01:27 -0500 received badge  Popular Question (source)
2015-07-07 08:36:07 -0500 asked a question locked out situation with default domain?

Let's say I have the cloud admin policy in place for Keystone where my cloud admin is the user with admin role in the default domain scope.

If I disable the default domain, the cloud admin cannot login back in. While other domains are still operational, the default domain is forever lost? (in terms of cloud admin being able to login with a token scoped to the default domain).

Is there a way out of that situation?

2015-06-28 03:07:21 -0500 received badge  Famous Question (source)
2015-06-12 14:29:07 -0500 received badge  Famous Question (source)
2015-06-11 15:44:53 -0500 received badge  Popular Question (source)
2015-06-11 15:44:53 -0500 received badge  Notable Question (source)
2015-06-10 13:45:39 -0500 asked a question domain specific configuration

In Juno, when configuring identity driver configuration files for the different domains, the format is keystone.domainname.conf

What happens when the domain name changes? Say someone does a PUT /v3/domains/{id} to change the name, does it mean the identity driver configuration will no longer work until the config file is renamed accordingly?

(wondering why domain is wasn't used in the configuration file name instead of domain name?)

2015-04-24 23:21:25 -0500 received badge  Popular Question (source)
2015-04-24 23:21:25 -0500 received badge  Notable Question (source)
2015-04-14 12:21:38 -0500 asked a question Keeping track of tokens

When building a UI or application that potentially performs actions across different projects or even domains, there is a concern about how to keep track of the various tokens that get generated.

For example, a user may initially get an unscoped token, then get 3 different project scoped tokens from that token to perform various project specific operations.

What is a good practice to be able to perform the appropriate house keeping of these tokens? In the situation above, there are 4 tokens. In Horizon for example, which one gets DELETED when doing a sign out? What happens to the others?

In particular if PKI tokens are used, keeping those around may become problematic due to the size, if carried around through cookies.

2015-04-14 11:38:59 -0500 received badge  Famous Question (source)
2015-04-13 10:37:23 -0500 commented answer Keeping original scope when requesting a new token from token

Thanks Ali. Indeed token from token doesn't renew expiry. I was under the assumption it did. But i tried and it doesn't. New tokens from the token, have the same expiry.

I will read up on trusts.

2015-04-10 08:31:19 -0500 answered a question Keeping original scope when requesting a new token from token

Essentially, to try to "renew a token". To tell Keystone: "I'm this person with this scope of authorization, I wish to renew this token with the same scope".

Say an application doing some scheduled background operations. User originally authenticated with some scope. And background process just wants to renew that token; but may not know explicitly what the original scope was (or care).

2015-04-10 08:29:28 -0500 received badge  Notable Question (source)
2015-04-09 13:23:41 -0500 received badge  Popular Question (source)
2015-04-08 09:48:30 -0500 asked a question Keeping original scope when requesting a new token from token

Is there a way to tell Keystone that the scope of the new token requested (when using "token" as authentication method) is the same as the presented token?

In other words, in the absence of a "scope" attribute in the new request, can Keystone be hinted at using the same scope as the original?

2015-04-03 12:52:50 -0500 commented answer Dynamic reload of identity driver

After experimenting with Kilo code, I found that though configs are added in the database through Rest, the configs+driver dictionary is loaded is cached per thread, and initialized threads are reused(and don't reload configs after that, no matter if they came from the db or config file)

2015-04-01 13:40:57 -0500 received badge  Student (source)
2015-04-01 12:56:53 -0500 commented answer Dynamic reload of identity driver

Do you know if the config is supposed to be taken into consideration right away or still requires a restart to take effect. Experimenting with Kilo code suggests a restart is still needed.(things don't work consistently otherwise).Understood it's a WIP but wondering about the intended behavior.

2015-03-31 13:51:37 -0500 received badge  Famous Question (source)
2015-03-31 00:16:22 -0500 received badge  Notable Question (source)
2015-03-31 00:16:22 -0500 received badge  Popular Question (source)
2015-03-30 15:51:58 -0500 received badge  Popular Question (source)
2015-03-30 15:51:58 -0500 received badge  Notable Question (source)
2015-03-30 15:25:23 -0500 asked a question Code question on domain config reloads

I have been looking at the latest code from master (Kilo 2 be), to understand how the domain configs are being loaded from the database, with the new APIs in identity 3.4: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3.html#domain-configuration-management (http://specs.openstack.org/openstack/...) )

I see where, in keystone/keystone/identity/core.py, the domain_configured wrapper makes sure that domain configs and drivers have been loaded.

But how does the system know to re-load modified configs:

def domains_configured(f):
"""Wraps API calls to lazy load domain configs after init.

This is required since the assignment manager needs to be initialized
before this manager, and yet this manager's init wants to be
able to make assignment calls (to build the domain configs).  So
instead, we check if the domains have been initialized on entry
to each call, and if requires load them,

"""
@functools.wraps(f)
def wrapper(self, *args, **kwargs):
    if (not self.domain_configs.configured and
            CONF.identity.domain_specific_drivers_enabled):
        self.domain_configs.setup_domain_drivers(
            self.driver, self.resource_api)
    return f(self, *args, **kwargs)
return wrapper

In particular, the line " if (not self.domain_configs.configured ". The configured flag is set to True and remains that way. So I'm not understanding how configs get reloaded when say someone changes an option for that config.

I saw that resource/core.py uses MEMOIZE and I'm sure there is some cache invalidation that happens (get_config_with_sensitive_info calls invalidate), but I'm having trouble finding the exact piece of code that would illustrate how the new config gets accounted for since the wrapper above seems like it will not reload anything because of the configure flag being set to True already.

2015-03-28 17:27:45 -0500 received badge  Famous Question (source)
2015-03-27 12:40:44 -0500 commented answer mixing authentication methods within a domain

Ah I see.Yes it would make sense. And I guess then this admin user would get mapped to a group at runtime and the group would have pre-assigned roles (like with OS-FEDERATION). The user itself absolutely doesn't exist in Keystone at all.In Juno, I don't think one can do what I'm suggesting right?