*** jroll has joined #openstack-keystone | 00:00 | |
*** jroll has quit IRC | 00:16 | |
*** jroll has joined #openstack-keystone | 00:17 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 00:25 |
---|---|---|
*** fabian_ has joined #openstack-keystone | 01:00 | |
*** fabian_ is now known as chenyb4 | 01:04 | |
*** panbalag has joined #openstack-keystone | 01:26 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 01:28 |
*** yikun has joined #openstack-keystone | 01:33 | |
openstackgerrit | wangxiyuan proposed openstack/keystone master: Update IdP sql model https://review.openstack.org/559676 | 01:33 |
*** panbalag has left #openstack-keystone | 01:36 | |
*** mvk has quit IRC | 01:37 | |
*** mvk has joined #openstack-keystone | 01:51 | |
openstackgerrit | wangxiyuan proposed openstack/keystone-specs master: block diag quota scenarios https://review.openstack.org/441203 | 02:20 |
openstackgerrit | wangxiyuan proposed openstack/keystone-specs master: WIP: Add Project Limit Hierarchy spec https://review.openstack.org/549766 | 02:22 |
*** mvk has quit IRC | 02:39 | |
*** dave-mcc_ has quit IRC | 02:45 | |
lbragstad | adriant: that sounds good | 02:47 |
*** nicolasbock has quit IRC | 02:55 | |
*** jdennis has quit IRC | 02:58 | |
*** jdennis has joined #openstack-keystone | 03:00 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 03:01 |
*** d0ugal_ has joined #openstack-keystone | 03:14 | |
*** d0ugal has quit IRC | 03:16 | |
openstackgerrit | wangxiyuan proposed openstack/keystone-specs master: Hierarchical Unified Limits https://review.openstack.org/540803 | 03:24 |
*** annp has joined #openstack-keystone | 03:28 | |
*** sonuk has joined #openstack-keystone | 03:29 | |
*** ayoung has quit IRC | 03:41 | |
*** prashkre_ has joined #openstack-keystone | 03:46 | |
*** prashkre has quit IRC | 03:47 | |
*** dklyle has joined #openstack-keystone | 03:57 | |
*** timburke_ has joined #openstack-keystone | 04:02 | |
*** ildikov has quit IRC | 04:03 | |
*** timburke has quit IRC | 04:03 | |
*** jamiec has quit IRC | 04:03 | |
*** d0ugal_ has quit IRC | 04:03 | |
*** d0ugal__ has joined #openstack-keystone | 04:03 | |
*** jamiec has joined #openstack-keystone | 04:03 | |
*** andymccr has quit IRC | 04:05 | |
*** andymccr has joined #openstack-keystone | 04:05 | |
*** prashkre__ has joined #openstack-keystone | 04:13 | |
*** asettle_ has joined #openstack-keystone | 04:14 | |
*** prashkre_ has quit IRC | 04:16 | |
*** asettle has quit IRC | 04:16 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 04:20 |
*** annp has quit IRC | 04:21 | |
*** annp has joined #openstack-keystone | 04:21 | |
*** markvoelker has quit IRC | 04:37 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 04:47 |
*** prashkre__ has quit IRC | 04:51 | |
*** sapd_ has quit IRC | 05:07 | |
*** sapd_ has joined #openstack-keystone | 05:08 | |
*** gagehugo has quit IRC | 05:16 | |
*** links has joined #openstack-keystone | 05:23 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 05:37 |
*** markvoelker has joined #openstack-keystone | 05:38 | |
*** gagehugo has joined #openstack-keystone | 05:46 | |
*** sonuk_ has joined #openstack-keystone | 05:49 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 05:51 |
*** sonuk has quit IRC | 05:53 | |
*** hoonetorg has quit IRC | 05:59 | |
*** prashkre has joined #openstack-keystone | 06:11 | |
*** hoonetorg has joined #openstack-keystone | 06:12 | |
*** pcaruana has joined #openstack-keystone | 06:16 | |
*** tobberydberg has quit IRC | 06:21 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 06:30 |
openstackgerrit | Pavlo Shchelokovskyy proposed openstack/keystoneauth master: Use defusedxml for XML parsing in SAML https://review.openstack.org/536761 | 06:47 |
*** chenyb4 has quit IRC | 06:56 | |
*** rcernin has quit IRC | 06:57 | |
*** chenyb4 has joined #openstack-keystone | 07:01 | |
*** tesseract has joined #openstack-keystone | 07:14 | |
*** gongysh has joined #openstack-keystone | 07:22 | |
*** tobberydberg has joined #openstack-keystone | 07:23 | |
*** AlexeyAbashkin has joined #openstack-keystone | 07:31 | |
*** gagehugo has quit IRC | 07:54 | |
*** gongysh has quit IRC | 08:02 | |
*** gongysh has joined #openstack-keystone | 08:03 | |
*** gongysh has quit IRC | 08:03 | |
openstackgerrit | Tin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task https://review.openstack.org/561751 | 08:04 |
*** d0ugal__ has quit IRC | 08:05 | |
*** d0ugal has joined #openstack-keystone | 08:05 | |
*** d0ugal has quit IRC | 08:05 | |
*** d0ugal has joined #openstack-keystone | 08:05 | |
*** sonuk has joined #openstack-keystone | 08:08 | |
*** sonuk_ has quit IRC | 08:08 | |
*** rvba` has quit IRC | 08:08 | |
*** gagehugo has joined #openstack-keystone | 08:11 | |
*** pcichy has joined #openstack-keystone | 08:20 | |
*** namnh has joined #openstack-keystone | 08:45 | |
*** pcichy has quit IRC | 08:49 | |
*** edmondsw has joined #openstack-keystone | 08:58 | |
*** edmondsw has quit IRC | 09:02 | |
*** mvk has joined #openstack-keystone | 09:22 | |
*** gongysh has joined #openstack-keystone | 09:26 | |
*** namnh has quit IRC | 10:10 | |
*** chenyb4 has quit IRC | 10:19 | |
*** nicolasbock has joined #openstack-keystone | 10:37 | |
*** mvk has quit IRC | 10:41 | |
*** mvk has joined #openstack-keystone | 10:54 | |
*** AlexeyAbashkin has quit IRC | 11:07 | |
mordred | lbragstad, cmurphy, kmalloc: if you get bored today - https://review.openstack.org/#/c/462218/ and https://review.openstack.org/#/c/559125 are ready to go | 11:11 |
mordred | and https://review.openstack.org/#/c/559154 | 11:11 |
*** jaosorior has quit IRC | 11:24 | |
openstackgerrit | wangxiyuan proposed openstack/keystone master: Invalidate the shadow user cache when deleting a user https://review.openstack.org/561908 | 11:26 |
*** jaosorior has joined #openstack-keystone | 11:27 | |
*** AlexeyAbashkin has joined #openstack-keystone | 11:28 | |
*** sonuk has quit IRC | 11:29 | |
*** sonuk has joined #openstack-keystone | 11:32 | |
*** raildo has joined #openstack-keystone | 11:59 | |
*** sonuk has quit IRC | 12:09 | |
*** dave-mccowan has joined #openstack-keystone | 12:15 | |
*** gongysh has quit IRC | 12:20 | |
*** chenyb4 has joined #openstack-keystone | 12:23 | |
*** markvoelker has quit IRC | 12:25 | |
*** markvoelker has joined #openstack-keystone | 12:25 | |
*** edmondsw has joined #openstack-keystone | 12:37 | |
*** panbalag has joined #openstack-keystone | 12:41 | |
*** chenyb4 has quit IRC | 12:42 | |
*** panbalag has left #openstack-keystone | 12:43 | |
*** mchlumsky has joined #openstack-keystone | 12:50 | |
*** pcichy has joined #openstack-keystone | 12:54 | |
*** mchlumsky has quit IRC | 12:54 | |
*** mchlumsky has joined #openstack-keystone | 12:57 | |
*** andreykurilin has joined #openstack-keystone | 13:20 | |
lbragstad | mordred: thanks - will do | 13:26 |
*** spilla has joined #openstack-keystone | 13:34 | |
*** links has quit IRC | 13:38 | |
*** felipemonteiro has joined #openstack-keystone | 13:42 | |
*** felipemonteiro_ has joined #openstack-keystone | 13:46 | |
*** asettle_ is now known as asettle | 13:47 | |
*** felipemonteiro has quit IRC | 13:50 | |
*** r-daneel has joined #openstack-keystone | 14:04 | |
*** felipemonteiro_ has quit IRC | 14:16 | |
*** felipemonteiro__ has joined #openstack-keystone | 14:16 | |
*** cristicalin has joined #openstack-keystone | 14:16 | |
*** cristicalin has quit IRC | 14:48 | |
*** cristicalin has joined #openstack-keystone | 14:49 | |
kmalloc | mordred: on the list for today for sure. | 14:51 |
*** efried has quit IRC | 15:00 | |
*** felipemonteiro_ has joined #openstack-keystone | 15:10 | |
*** felipemonteiro__ has quit IRC | 15:13 | |
* lbragstad sets https://review.openstack.org/#/c/561908/ on knikolla's desk | 15:15 | |
lbragstad | since we were just talking about that last weke | 15:15 |
lbragstad | week* | 15:15 |
lbragstad | looks like wxy decided to whip up a fix | 15:15 |
knikolla | lbragstad: awesome! | 15:15 |
knikolla | o/ | 15:16 |
knikolla | lbragstad: can we talk jwt at some point today? | 15:17 |
lbragstad | knikolla: please | 15:17 |
lbragstad | knikolla: i'm free now - or we can tackle it during office hours | 15:17 |
knikolla | office hours would work and we should have a better attendance | 15:18 |
knikolla | i need to debug some openstack issues on our cloud now | 15:18 |
lbragstad | ++ | 15:19 |
lbragstad | works for me | 15:19 |
knikolla | ... and the issue is gone... gotta love transient issues... | 15:20 |
*** wxy| has joined #openstack-keystone | 15:25 | |
*** pcaruana has quit IRC | 15:28 | |
*** cristicalin has quit IRC | 15:50 | |
*** prashkre has quit IRC | 16:05 | |
*** prashkre has joined #openstack-keystone | 16:05 | |
*** prashkre has quit IRC | 16:11 | |
*** panbalag has joined #openstack-keystone | 16:14 | |
*** links has joined #openstack-keystone | 16:15 | |
*** pcaruana has joined #openstack-keystone | 16:18 | |
*** gyee has joined #openstack-keystone | 16:19 | |
*** harlowja has joined #openstack-keystone | 16:23 | |
*** r-daneel_ has joined #openstack-keystone | 16:29 | |
*** r-daneel has quit IRC | 16:30 | |
*** r-daneel_ is now known as r-daneel | 16:30 | |
*** jdennis has quit IRC | 16:34 | |
*** pcichy has quit IRC | 16:41 | |
*** harlowja has quit IRC | 16:52 | |
* gagehugo steps out for lunch | 16:54 | |
*** harlowja has joined #openstack-keystone | 16:57 | |
*** wxy| has quit IRC | 16:58 | |
lbragstad | #startmeeting keystone-office-hours | 17:00 |
openstack | Meeting started Tue Apr 17 17:00:02 2018 UTC and is due to finish in 60 minutes. The chair is lbragstad. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
*** openstack changes topic to " (Meeting topic: keystone-office-hours)" | 17:00 | |
*** ChanServ changes topic to "Rocky release schedule: https://releases.openstack.org/rocky/schedule.html | Meeting agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h | Trello: https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap" | 17:00 | |
openstack | The meeting name has been set to 'keystone_office_hours' | 17:00 |
*** panbalag has left #openstack-keystone | 17:01 | |
cmurphy | o/ | 17:01 |
knikolla | \o | 17:02 |
openstackgerrit | Russell Tweed proposed openstack/keystone master: Add prerequisite package note to Keystone install guide https://review.openstack.org/552568 | 17:04 |
openstackgerrit | Lance Bragstad proposed openstack/keystone master: Remove the sample .conf file https://review.openstack.org/521249 | 17:05 |
*** dklyle has quit IRC | 17:07 | |
*** pcichy has joined #openstack-keystone | 17:13 | |
*** harlowja has quit IRC | 17:20 | |
*** links has quit IRC | 17:35 | |
cmurphy | so did we decide how much we care about the jwt token being encrypted or not? | 17:37 |
knikolla | i'd rather them not be for interop reasons, but we might have that configurable | 17:38 |
knikolla | also the library that supported jwe, was gpl lincensed if i'm not wrong. | 17:39 |
lbragstad | what if we provided a jws token provider and a jwe token provider later? | 17:39 |
knikolla | and we could mark it as experimental | 17:40 |
lbragstad | yeah - and i think we would have to be opinionated about it given the vulnerabilities of jws | 17:40 |
knikolla | opinionated is fine i think. | 17:41 |
lbragstad | e.g. we might only support a specific signing implementation | 17:41 |
lbragstad | which could limit the interop use case | 17:41 |
*** r-daneel_ has joined #openstack-keystone | 17:42 | |
*** r-daneel has quit IRC | 17:43 | |
*** r-daneel_ is now known as r-daneel | 17:43 | |
knikolla | probably not, as most clients will support at least the popular signing algos. | 17:43 |
knikolla | unless they're strongly opinionated. | 17:44 |
*** links has joined #openstack-keystone | 17:47 | |
lbragstad | i assume we would be targetting something like HS256 | 17:47 |
lbragstad | initially | 17:47 |
knikolla | that raises the question of symmetric vs asymmetric | 17:48 |
lbragstad | if we do asymmetric, it would be easier for other service to validate tokens offline in middleware if they aren't encrypted | 17:49 |
lbragstad | services* | 17:50 |
lbragstad | if that's something we want to support | 17:51 |
knikolla | depending on if we're putting the roles in the token | 17:51 |
lbragstad | ayoung had a specification to include a maximum of one role in the token payload | 17:51 |
knikolla | would be hard to have that AND default (and more granular) roles happen at the same time. | 17:53 |
lbragstad | how so? | 17:53 |
knikolla | maybe too big of a step for the community to do at once? | 17:54 |
cmurphy | wouldn't the token need the catalog too? and then we're back to the problem with pki | 17:54 |
knikolla | i don't mind keystonemiddleware making a validate call, in general | 17:55 |
knikolla | because roles and service catalog are openstack concepts | 17:55 |
knikolla | for outside services which don't care about that | 17:55 |
knikolla | an asymmetrically signed token they can validate with enough user information may be enough for interop | 17:55 |
lbragstad | does outside services mean other openstack services or something else? | 17:56 |
knikolla | non-opensatck | 17:56 |
lbragstad | ok | 17:56 |
lbragstad | yeah - it's tough where to draw the line between what makes sense to include and not include in the token | 17:56 |
lbragstad | it really depends on what level of validation the service is going to do | 17:57 |
lbragstad | i'm not sure if i clearly understand what that is yet =/ | 17:57 |
lbragstad | do they just want to know if the token came from keystone? do they want to know if contents are valid? do they do something special with expiration? do they want the roles? | 17:58 |
lbragstad | do they want the service catalog? | 17:58 |
knikolla | i don't think they want the service catalog for one. | 17:59 |
knikolla | because if they want that, they know about openstack. so they can make a token validate call and get it. | 17:59 |
knikolla | As in, if you want the service catalog -> you know this token came from keystone -> you know how to make a call to get the service catalog if it's not in the token | 18:00 |
*** AlexeyAbashkin has quit IRC | 18:02 | |
lbragstad | so - maybe the question is, what do services want out of the token used to make the request? | 18:02 |
lbragstad | do they want to be able to have all the bit necessary to do policy enforcement, for example? | 18:03 |
knikolla | that will be abstracted by keystonemiddleware anyway. | 18:04 |
knikolla | scope/role information will be available to the services regardless. | 18:04 |
cmurphy | the service needs to validate that it is a valid token issued by keystone and needs to check that the project and user and the role assignments in the token are still valid at that point in time, which could have changed in between the token being issued and the token being used | 18:04 |
lbragstad | that's true | 18:05 |
knikolla | my gut feeling is to only include standard user information (username, email, etc) and the current project the token is scoped to. | 18:06 |
knikolla | have everything else be fetched on a validate call. | 18:06 |
*** tesseract has quit IRC | 18:06 | |
*** mvk has quit IRC | 18:07 | |
knikolla | (and of course the usual issued at, expires at, issuer, etc) | 18:08 |
lbragstad | so - aside from the possibility of making it easier to validate tokens at the service | 18:11 |
cmurphy | yeah, i guess the only difference is right now the service is forced to ask keystone to decrypt the token to get that information, with an unencrypted token a badly behaving service could decide not to validate, but that's not really our problem i guess | 18:11 |
*** prashkre has joined #openstack-keystone | 18:11 | |
lbragstad | there is the possibility to make the key repository bits easier to manage between the keystone nodes of a deployment | 18:12 |
cmurphy | the only other concern i had was that right now if you have an expired/revoked token you can't get any information out of it even if you try to validate it, but with an unencrypted token that information is just in plain sight | 18:12 |
knikolla | i don't think there's anything particularly sensitive in there. | 18:13 |
lbragstad | i guess if i'm an operator and i think that stuff is sensitive, then i'd opt for fernet | 18:14 |
knikolla | dims: we're discussing jwt in case you want to join the discussion | 18:14 |
lbragstad | or maybe my deployment has to fill a check box that says that information can't be exposed | 18:15 |
knikolla | fernet would be a viable solution for that. and maybe in the future we implement jwe to replace fernet. | 18:16 |
* gagehugo sneaks back in | 18:16 | |
lbragstad | or just a comparable alternative | 18:16 |
lbragstad | i still believe we're primarily pursuing jwt (jws/jwe) to offer some alternative in the worst case scenario that something goes wrong with fernet | 18:17 |
lbragstad | if we implement jwe, then replace or remove fernet, we're pretty close to square one in that we don't have a viable backup option | 18:17 |
knikolla | for jws i'm also looking at the federation with external systems case | 18:18 |
knikolla | a signed jwt with user information is similar to a saml assertion | 18:18 |
lbragstad | regarding the asymmetric vs symmetric bits - do you have a inclination at which approach would make that story easier for you? | 18:19 |
cmurphy | saml assertions can be encrypted too | 18:19 |
knikolla | cmurphy: yes, but the key of the intended audience. | 18:19 |
knikolla | with jwe we're targeting keystone to be the issuer and audience. | 18:19 |
cmurphy | that's true | 18:20 |
knikolla | lbragstad: i think asymmetric. since external systems can't know the symmetric key. | 18:20 |
lbragstad | #link https://stackoverflow.com/questions/8276233/is-it-recommended-to-sign-and-encrypt-saml-and-use-ssl | 18:20 |
lbragstad | yeah | 18:21 |
lbragstad | there is another requirement i've heard before where a deployment spans large geographic regions | 18:21 |
lbragstad | region A and region B are part of the same cloud | 18:21 |
lbragstad | but there are data restrictions in region B that prevent users in region A from using it (or data crossing the border) | 18:22 |
lbragstad | which is problematic when syncing the key repository | 18:22 |
cmurphy | we'd have to sync keys no matter what, it's just a question of syncing public keys or private keys | 18:23 |
lbragstad | right - i agree there | 18:23 |
lbragstad | publishing a public key would be "less scary" than syncing private keys is the justification i've heard | 18:24 |
knikolla | you want the private key is an fewer places as you can generally. | 18:24 |
cmurphy | if you publish a public key you'd have to establish some way of trusting it | 18:24 |
cmurphy | i guess maybe just http and tls | 18:25 |
knikolla | or ansible/puppet/etc. | 18:25 |
lbragstad | if we did asymmetric with jws - each keystone node would only have it's own private key | 18:25 |
lbragstad | which would be more consistent with the intended usage of a private key file | 18:25 |
lbragstad | and the public key would be shared or distribute (however that happens) | 18:26 |
knikolla | potentially that could solve the data restriction you mentioned above. | 18:26 |
lbragstad | yeah - possibly | 18:27 |
knikolla | as in you could have multiple keystones in the region and use the same token | 18:27 |
knikolla | i remember this is one of the use cases of the oranje (i think) people. | 18:28 |
lbragstad | yeah | 18:28 |
lbragstad | they have datacenters in europe - and some of the new legislation affects stuff like that (also on the db replication layer) | 18:28 |
cmurphy | that wouldn't solve their issue, there wouldn't be synchronized projects in each region so the tokens wouldn't be valid in all regions | 18:29 |
gagehugo | yeah that's their usecase | 18:29 |
*** dklyle has joined #openstack-keystone | 18:30 | |
lbragstad | i thought they were going to work around that with a custom backend to handle orchestrating projects with the same ID across regions? | 18:30 |
lbragstad | i thought we discussed something like that with them in office hours | 18:31 |
knikolla | cmurphy: not necessarily. if keystonemiddleware is smart enough, it can check the issuer of the token, and see that it is region A, so make the validate call to region A keystone rather than region B. | 18:31 |
cmurphy | lbragstad: yes that was the workaround, but i think that was actually bad advice because we decided the resource driver is sql only | 18:32 |
lbragstad | bah | 18:33 |
cmurphy | knikolla: so then the token has to be validated across datacenters? that seems like a similar data restriction problem and also not very performant | 18:33 |
lbragstad | https://github.com/openstack/keystone/blob/master/keystone/conf/resource.py#L23-L27 | 18:34 |
cmurphy | which is why i'd like to undo all those foreign keys and fix that | 18:34 |
lbragstad | so - iirc we're back to making k2k more performant | 18:35 |
lbragstad | or what cmurphy said | 18:35 |
cmurphy | there are probably a lot of people still on newton who are going to be surprised by that | 18:35 |
knikolla | a jwt token can be equivalent to k2k and probably more performant. since you wouldn't need an additional call to have keystone generate one. | 18:36 |
knikolla | aka make k2k use jwt. | 18:36 |
knikolla | where a jwt token is able to be validated offline and contains all the information that is in a saml assertion. | 18:37 |
*** felipemonteiro_ has quit IRC | 18:38 | |
cmurphy | that's kind of the opposite of what you said before "my gut feeling is to only include standard user information (username, email, etc) and the current project the token is scoped to." | 18:39 |
*** felipemonteiro_ has joined #openstack-keystone | 18:39 | |
cmurphy | a saml assertion has a lot of crap | 18:39 |
knikolla | boilerplate crap. | 18:39 |
knikolla | it can be boiled down to username, email, domain and project. | 18:40 |
knikolla | so it's not really the opposite, it's almost the same information i was arguing for. | 18:41 |
cmurphy | okay that's fair :) | 18:42 |
lbragstad | ok - approaching the question from a different angle | 18:44 |
lbragstad | does it make sense to implement jws with symmetric signing if we already have a token provider that uses symmetric encryption? | 18:45 |
*** dklyle has quit IRC | 18:46 | |
knikolla | i can't really think of a use case where that would give us something over fernet. | 18:46 |
knikolla | you need the private key to validate the token. | 18:47 |
knikolla | if you have the private key you can sign the token. | 18:47 |
knikolla | same is valid for fernet (+encryption) | 18:47 |
*** felipemonteiro has joined #openstack-keystone | 18:48 | |
*** felipemonteiro_ has quit IRC | 18:48 | |
*** felipemonteiro_ has joined #openstack-keystone | 18:49 | |
lbragstad | jwe would be nice to have as a compliment to fernet, but it doesn't look like we're going to get that in the near future | 18:49 |
knikolla | in other words: if you need the private key to verify it, potentially it doesn't matter if it is encrypted or not. | 18:49 |
lbragstad | sure | 18:50 |
*** dklyle has joined #openstack-keystone | 18:51 | |
lbragstad | i kinda like the approach paseto takes | 18:52 |
lbragstad | you have a thing and you can configure it to give you encrypted tokens or signed tokens | 18:53 |
*** felipemonteiro has quit IRC | 18:53 | |
lbragstad | which ever you chose depends on your deployment | 18:53 |
lbragstad | cmurphy: i guess you take on the resource backend might have an impact on https://review.openstack.org/#/c/559676/ | 18:56 |
lbragstad | your take* | 18:56 |
knikolla | arguably by sticking with a secure algorithm for jwt, and not processing anything else we get pretty close to paseto. | 18:56 |
*** dklyle has quit IRC | 18:57 | |
lbragstad | essentially - yeah | 18:57 |
knikolla | as we release new versions we might deprecate validating that algorithm and starting to use another one, and then remove it entirely (giving us the versioning) | 18:57 |
cmurphy | lbragstad: yeah i have mixed feelings on it | 18:58 |
lbragstad | cmurphy: i see what you mean (and i remember dstanek_ talking about stuff like that a long time ago) | 18:59 |
lbragstad | it feels like we're constantly stuck in the middle | 18:59 |
lbragstad | we want to be flexible in what we back to, but because of that we can't use the default thing we back to in ways it was meant to be used | 19:00 |
*** r-daneel_ has joined #openstack-keystone | 19:01 | |
lbragstad | knikolla: yeah - we will have to validate the algorithm in the token header within keystone for sure | 19:01 |
lbragstad | since that was one of the main issues in the JWT library vulnerability | 19:02 |
lbragstad | er - JWT vulnerability across libraries* | 19:02 |
*** r-daneel has quit IRC | 19:03 | |
*** r-daneel_ is now known as r-daneel | 19:03 | |
knikolla | lbragstad: do you think we have enough information from this discussion to start shaping up the spec? | 19:04 |
lbragstad | i think so - but i wouldn't mind recapping | 19:05 |
lbragstad | based on the discussion | 19:05 |
lbragstad | do we see value in a signing implementation of a token provider? | 19:06 |
lbragstad | i would say yes - only because it's not the only option available and people can always opt into using fernet if they want added security | 19:06 |
lbragstad | s/security/security through obscurity of encryption/ | 19:07 |
lbragstad | knikolla: cmurphy what other bigger points would you want included in the spec if any? | 19:13 |
cmurphy | lbragstad: I'd like to see huawei's use cases mentioned | 19:14 |
lbragstad | which ones? | 19:15 |
lbragstad | bah - that was a dumb question, you probably want to see all of them | 19:15 |
cmurphy | lbragstad: i don't know, what are your use cases? why is huawei pushing for it? | 19:15 |
knikolla | Federation use cases. Enough information to be useful for external systems. Aka keystone as an idp with jwt. | 19:15 |
cmurphy | we had it in the backlog for some vague "it would be nice" reasons, if we're committing to it this cycle it would be good to justify why it's more important now | 19:15 |
lbragstad | the main reason we want it is for the asymmetric signing bit | 19:16 |
lbragstad | huawei used PKI for a long time, and they wanted something that would eventually behave similarly | 19:17 |
gagehugo | keystone as an idp with jwt is something I know was brought up before | 19:17 |
gagehugo | I think kubernetes intergration is something too | 19:17 |
lbragstad | there was also hesitation internally about sharing symmetric keys across large deployments | 19:18 |
*** pcichy has quit IRC | 19:22 | |
lbragstad | even though there are other hurdles there | 19:23 |
lbragstad | (db replication and whatnot) | 19:24 |
*** AlexeyAbashkin has joined #openstack-keystone | 19:25 | |
*** r-daneel_ has joined #openstack-keystone | 19:29 | |
*** r-daneel has quit IRC | 19:30 | |
*** r-daneel_ is now known as r-daneel | 19:30 | |
lbragstad | so - i think those are the two huawei usecases | 19:31 |
lbragstad | but wxy might be able to give more insight | 19:32 |
*** AlexeyAbashkin has quit IRC | 19:34 | |
cmurphy | I think solidifying those use cases would inform the technical decisions we need to make | 19:35 |
lbragstad | i can add them | 19:36 |
cmurphy | if huawei is banking on this being a PKI replacement and that's not something we can offer then we need to be realistic about that and prioritize accordingly | 19:36 |
cmurphy | or if having a PKI replacement is a top design goal then we might need to rethink some things | 19:37 |
lbragstad | sure - that makes sense, i don't think it would be a PKI replacement | 19:38 |
lbragstad | i guess my interpretation of it is that it would allow deployments using PKI an alternative if they are willing to roll their own token formatter to include bits we've taken a hard stance against | 19:39 |
lbragstad | while providing some level of security in the sense that we have something to backup fernet | 19:39 |
*** jdennis has joined #openstack-keystone | 19:46 | |
*** harlowja has joined #openstack-keystone | 19:50 | |
*** dklyle has joined #openstack-keystone | 19:52 | |
*** jdennis has quit IRC | 20:16 | |
kmalloc | lbragstad: if we support JWT, at least if fernet has an OOPSE, we have an out | 20:18 |
kmalloc | JWE long term goal when we van | 20:18 |
kmalloc | can* | 20:18 |
kmalloc | right now, a PKI replacement is not realistic, short of JWE | 20:19 |
lbragstad | yeah - i'm not saying we should reimplement PKI with JWT | 20:21 |
*** dklyle has quit IRC | 20:21 | |
kmalloc | and i would LOVE to see JWE | 20:22 |
kmalloc | but... i'm realistic | 20:22 |
kmalloc | i would like us to be on JWT in general for reasons of $STANDARDS$ | 20:22 |
lbragstad | but... theoretically, if a deployment was using PKI for a long time, they could extend the jws token provider to get similar functionality without having to maintain the pki token provider out of tree | 20:22 |
kmalloc | yeah | 20:22 |
kmalloc | that is true | 20:22 |
kmalloc | also... if your employer wants to dedicate resources to PKI-like implementation on the JWT base [it's a lot of leg work] | 20:23 |
kmalloc | i'm happy to have that. | 20:23 |
kmalloc | but I want it to be clearly part of the standards and it would need ot be (pref) in a lib we can consume | 20:23 |
kmalloc | (one of the main-stream libs) | 20:24 |
kmalloc | i also agree with cmurphy, clear use-cases documented = win | 20:25 |
lbragstad | that's what i'm working on now | 20:25 |
kmalloc | cool | 20:25 |
lbragstad | fwiw - if we did the asymmetric route - we'd be targetting the RS256 algorithm | 20:26 |
kmalloc | yeah | 20:30 |
kmalloc | i would expect as much | 20:30 |
*** raildo has quit IRC | 20:30 | |
kmalloc | fwiw, it should be easy to implement both rS256 and HS256 | 20:31 |
*** dklyle has joined #openstack-keystone | 20:31 | |
kmalloc | (relatively) | 20:31 |
*** sapd__ has joined #openstack-keystone | 20:40 | |
*** links has quit IRC | 20:42 | |
*** pcaruana has quit IRC | 20:42 | |
*** sapd_ has quit IRC | 20:43 | |
*** oikiki has joined #openstack-keystone | 20:51 | |
openstackgerrit | Doug Hellmann proposed openstack/keystoneauth master: add lower-constraints job https://review.openstack.org/555625 | 20:58 |
openstackgerrit | Doug Hellmann proposed openstack/keystoneauth master: fix pep8 errors caused by pycodestyle>=2.4.0 https://review.openstack.org/562052 | 20:58 |
openstackgerrit | Lance Bragstad proposed openstack/keystone-specs master: Repropose JWT specification for Rocky https://review.openstack.org/541903 | 21:11 |
*** mvk has joined #openstack-keystone | 21:14 | |
lbragstad | kmalloc: cmurphy knikolla gagehugo wxy updated with usecases | 21:16 |
lbragstad | ^ | 21:16 |
lbragstad | i guess the next step is determining if they are valid and adding missing ones | 21:17 |
lbragstad | i'll rework the specifications technical details after that | 21:18 |
*** prashkre_ has joined #openstack-keystone | 21:19 | |
*** prashkre has quit IRC | 21:19 | |
lbragstad | #endmeeting | 21:21 |
*** openstack changes topic to "Rocky release schedule: https://releases.openstack.org/rocky/schedule.html | Meeting agenda: https://etherpad.openstack.org/p/keystone-weekly-meeting | Bugs that need triaging: http://bit.ly/2iJuN1h | Trello: https://trello.com/b/wmyzbFq5/keystone-rocky-roadmap" | 21:21 | |
openstack | Meeting ended Tue Apr 17 21:21:00 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:21 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-04-17-17.00.html | 21:21 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-04-17-17.00.txt | 21:21 |
openstack | Log: http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-04-17-17.00.log.html | 21:21 |
lbragstad | probably should have done that about 20 minutes ago | 21:21 |
*** edmondsw has quit IRC | 21:24 | |
*** dklyle has quit IRC | 21:42 | |
*** dklyle has joined #openstack-keystone | 21:46 | |
gagehugo | lbragstad Is there any reason to consider using python-jose if it offers the same functionality as pyjwt? | 21:47 |
*** jmlowe has quit IRC | 22:00 | |
*** fiddletwix has quit IRC | 22:03 | |
*** fiddletwix has joined #openstack-keystone | 22:07 | |
*** felipemonteiro_ has quit IRC | 22:10 | |
*** jmlowe has joined #openstack-keystone | 22:16 | |
*** fiddletwix has quit IRC | 22:18 | |
*** pcichy has joined #openstack-keystone | 22:22 | |
*** pcichy has quit IRC | 22:23 | |
*** dklyle has quit IRC | 22:27 | |
*** pcichy has joined #openstack-keystone | 22:35 | |
*** pcichy has quit IRC | 22:37 | |
*** rcernin has joined #openstack-keystone | 22:42 | |
*** jdennis has joined #openstack-keystone | 22:46 | |
*** r-daneel has quit IRC | 22:46 | |
*** r-daneel has joined #openstack-keystone | 22:52 | |
*** oikiki has quit IRC | 23:09 | |
*** oikiki has joined #openstack-keystone | 23:09 | |
*** oikiki has quit IRC | 23:09 | |
*** r-daneel has quit IRC | 23:18 | |
*** oikiki has joined #openstack-keystone | 23:19 | |
*** jdennis has quit IRC | 23:19 | |
*** spilla has quit IRC | 23:23 | |
*** oikiki has quit IRC | 23:29 | |
*** oikiki has joined #openstack-keystone | 23:29 | |
*** oikiki has quit IRC | 23:30 | |
*** jdennis has joined #openstack-keystone | 23:42 | |
*** jmlowe_ has joined #openstack-keystone | 23:44 | |
*** jmlowe has quit IRC | 23:47 | |
*** r-daneel has joined #openstack-keystone | 23:47 | |
*** r-daneel has quit IRC | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!