Tuesday, 2018-04-17

*** jroll has joined #openstack-keystone00:00
*** jroll has quit IRC00:16
*** jroll has joined #openstack-keystone00:17
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175100:25
*** fabian_ has joined #openstack-keystone01:00
*** fabian_ is now known as chenyb401:04
*** panbalag has joined #openstack-keystone01:26
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175101:28
*** yikun has joined #openstack-keystone01:33
openstackgerritwangxiyuan proposed openstack/keystone master: Update IdP sql model  https://review.openstack.org/55967601:33
*** panbalag has left #openstack-keystone01:36
*** mvk has quit IRC01:37
*** mvk has joined #openstack-keystone01:51
openstackgerritwangxiyuan proposed openstack/keystone-specs master: block diag quota scenarios  https://review.openstack.org/44120302:20
openstackgerritwangxiyuan proposed openstack/keystone-specs master: WIP: Add Project Limit Hierarchy spec  https://review.openstack.org/54976602:22
*** mvk has quit IRC02:39
*** dave-mcc_ has quit IRC02:45
lbragstadadriant: that sounds good02:47
*** nicolasbock has quit IRC02:55
*** jdennis has quit IRC02:58
*** jdennis has joined #openstack-keystone03:00
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175103:01
*** d0ugal_ has joined #openstack-keystone03:14
*** d0ugal has quit IRC03:16
openstackgerritwangxiyuan proposed openstack/keystone-specs master: Hierarchical Unified Limits  https://review.openstack.org/54080303:24
*** annp has joined #openstack-keystone03:28
*** sonuk has joined #openstack-keystone03:29
*** ayoung has quit IRC03:41
*** prashkre_ has joined #openstack-keystone03:46
*** prashkre has quit IRC03:47
*** dklyle has joined #openstack-keystone03:57
*** timburke_ has joined #openstack-keystone04:02
*** ildikov has quit IRC04:03
*** timburke has quit IRC04:03
*** jamiec has quit IRC04:03
*** d0ugal_ has quit IRC04:03
*** d0ugal__ has joined #openstack-keystone04:03
*** jamiec has joined #openstack-keystone04:03
*** andymccr has quit IRC04:05
*** andymccr has joined #openstack-keystone04:05
*** prashkre__ has joined #openstack-keystone04:13
*** asettle_ has joined #openstack-keystone04:14
*** prashkre_ has quit IRC04:16
*** asettle has quit IRC04:16
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175104:20
*** annp has quit IRC04:21
*** annp has joined #openstack-keystone04:21
*** markvoelker has quit IRC04:37
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175104:47
*** prashkre__ has quit IRC04:51
*** sapd_ has quit IRC05:07
*** sapd_ has joined #openstack-keystone05:08
*** gagehugo has quit IRC05:16
*** links has joined #openstack-keystone05:23
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175105:37
*** markvoelker has joined #openstack-keystone05:38
*** gagehugo has joined #openstack-keystone05:46
*** sonuk_ has joined #openstack-keystone05:49
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175105:51
*** sonuk has quit IRC05:53
*** hoonetorg has quit IRC05:59
*** prashkre has joined #openstack-keystone06:11
*** hoonetorg has joined #openstack-keystone06:12
*** pcaruana has joined #openstack-keystone06:16
*** tobberydberg has quit IRC06:21
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175106:30
openstackgerritPavlo Shchelokovskyy proposed openstack/keystoneauth master: Use defusedxml for XML parsing in SAML  https://review.openstack.org/53676106:47
*** chenyb4 has quit IRC06:56
*** rcernin has quit IRC06:57
*** chenyb4 has joined #openstack-keystone07:01
*** tesseract has joined #openstack-keystone07:14
*** gongysh has joined #openstack-keystone07:22
*** tobberydberg has joined #openstack-keystone07:23
*** AlexeyAbashkin has joined #openstack-keystone07:31
*** gagehugo has quit IRC07:54
*** gongysh has quit IRC08:02
*** gongysh has joined #openstack-keystone08:03
*** gongysh has quit IRC08:03
openstackgerritTin Lam proposed openstack/keystone master: [Do Not Merge] Adding debugging task  https://review.openstack.org/56175108:04
*** d0ugal__ has quit IRC08:05
*** d0ugal has joined #openstack-keystone08:05
*** d0ugal has quit IRC08:05
*** d0ugal has joined #openstack-keystone08:05
*** sonuk has joined #openstack-keystone08:08
*** sonuk_ has quit IRC08:08
*** rvba` has quit IRC08:08
*** gagehugo has joined #openstack-keystone08:11
*** pcichy has joined #openstack-keystone08:20
*** namnh has joined #openstack-keystone08:45
*** pcichy has quit IRC08:49
*** edmondsw has joined #openstack-keystone08:58
*** edmondsw has quit IRC09:02
*** mvk has joined #openstack-keystone09:22
*** gongysh has joined #openstack-keystone09:26
*** namnh has quit IRC10:10
*** chenyb4 has quit IRC10:19
*** nicolasbock has joined #openstack-keystone10:37
*** mvk has quit IRC10:41
*** mvk has joined #openstack-keystone10:54
*** AlexeyAbashkin has quit IRC11:07
mordredlbragstad, cmurphy, kmalloc: if you get bored today - https://review.openstack.org/#/c/462218/ and https://review.openstack.org/#/c/559125 are ready to go11:11
mordredand https://review.openstack.org/#/c/55915411:11
*** jaosorior has quit IRC11:24
openstackgerritwangxiyuan proposed openstack/keystone master: Invalidate the shadow user cache when deleting a user  https://review.openstack.org/56190811:26
*** jaosorior has joined #openstack-keystone11:27
*** AlexeyAbashkin has joined #openstack-keystone11:28
*** sonuk has quit IRC11:29
*** sonuk has joined #openstack-keystone11:32
*** raildo has joined #openstack-keystone11:59
*** sonuk has quit IRC12:09
*** dave-mccowan has joined #openstack-keystone12:15
*** gongysh has quit IRC12:20
*** chenyb4 has joined #openstack-keystone12:23
*** markvoelker has quit IRC12:25
*** markvoelker has joined #openstack-keystone12:25
*** edmondsw has joined #openstack-keystone12:37
*** panbalag has joined #openstack-keystone12:41
*** chenyb4 has quit IRC12:42
*** panbalag has left #openstack-keystone12:43
*** mchlumsky has joined #openstack-keystone12:50
*** pcichy has joined #openstack-keystone12:54
*** mchlumsky has quit IRC12:54
*** mchlumsky has joined #openstack-keystone12:57
*** andreykurilin has joined #openstack-keystone13:20
lbragstadmordred: thanks - will do13:26
*** spilla has joined #openstack-keystone13:34
*** links has quit IRC13:38
*** felipemonteiro has joined #openstack-keystone13:42
*** felipemonteiro_ has joined #openstack-keystone13:46
*** asettle_ is now known as asettle13:47
*** felipemonteiro has quit IRC13:50
*** r-daneel has joined #openstack-keystone14:04
*** felipemonteiro_ has quit IRC14:16
*** felipemonteiro__ has joined #openstack-keystone14:16
*** cristicalin has joined #openstack-keystone14:16
*** cristicalin has quit IRC14:48
*** cristicalin has joined #openstack-keystone14:49
kmallocmordred: on the list for today for sure.14:51
*** efried has quit IRC15:00
*** felipemonteiro_ has joined #openstack-keystone15:10
*** felipemonteiro__ has quit IRC15:13
* lbragstad sets https://review.openstack.org/#/c/561908/ on knikolla's desk15:15
lbragstadsince we were just talking about that last weke15:15
lbragstadweek*15:15
lbragstadlooks like wxy decided to whip up a fix15:15
knikollalbragstad: awesome!15:15
knikollao/15:16
knikollalbragstad: can we talk jwt at some point today?15:17
lbragstadknikolla: please15:17
lbragstadknikolla: i'm free now - or we can tackle it during office hours15:17
knikollaoffice hours would work and we should have a better attendance15:18
knikollai need to debug some openstack issues on our cloud now15:18
lbragstad++15:19
lbragstadworks for me15:19
knikolla... and the issue is gone... gotta love transient issues...15:20
*** wxy| has joined #openstack-keystone15:25
*** pcaruana has quit IRC15:28
*** cristicalin has quit IRC15:50
*** prashkre has quit IRC16:05
*** prashkre has joined #openstack-keystone16:05
*** prashkre has quit IRC16:11
*** panbalag has joined #openstack-keystone16:14
*** links has joined #openstack-keystone16:15
*** pcaruana has joined #openstack-keystone16:18
*** gyee has joined #openstack-keystone16:19
*** harlowja has joined #openstack-keystone16:23
*** r-daneel_ has joined #openstack-keystone16:29
*** r-daneel has quit IRC16:30
*** r-daneel_ is now known as r-daneel16:30
*** jdennis has quit IRC16:34
*** pcichy has quit IRC16:41
*** harlowja has quit IRC16:52
* gagehugo steps out for lunch16:54
*** harlowja has joined #openstack-keystone16:57
*** wxy| has quit IRC16:58
lbragstad#startmeeting keystone-office-hours17:00
openstackMeeting 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
openstackUseful 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
openstackThe meeting name has been set to 'keystone_office_hours'17:00
*** panbalag has left #openstack-keystone17:01
cmurphyo/17:01
knikolla\o17:02
openstackgerritRussell Tweed proposed openstack/keystone master: Add prerequisite package note to Keystone install guide  https://review.openstack.org/55256817:04
openstackgerritLance Bragstad proposed openstack/keystone master: Remove the sample .conf file  https://review.openstack.org/52124917:05
*** dklyle has quit IRC17:07
*** pcichy has joined #openstack-keystone17:13
*** harlowja has quit IRC17:20
*** links has quit IRC17:35
cmurphyso did we decide how much we care about the jwt token being encrypted or not?17:37
knikollai'd rather them not be for interop reasons, but we might have that configurable17:38
knikollaalso the library that supported jwe, was gpl lincensed if i'm not wrong.17:39
lbragstadwhat if we provided a jws token provider and a jwe token provider later?17:39
knikollaand we could mark it as experimental17:40
lbragstadyeah - and i think we would have to be opinionated about it given the vulnerabilities of jws17:40
knikollaopinionated is fine i think.17:41
lbragstade.g. we might only support a specific signing implementation17:41
lbragstadwhich could limit the interop use case17:41
*** r-daneel_ has joined #openstack-keystone17:42
*** r-daneel has quit IRC17:43
*** r-daneel_ is now known as r-daneel17:43
knikollaprobably not, as most clients will support at least the popular signing algos.17:43
knikollaunless they're strongly opinionated.17:44
*** links has joined #openstack-keystone17:47
lbragstadi assume we would be targetting something like HS25617:47
lbragstadinitially17:47
knikollathat raises the question of symmetric vs asymmetric17:48
lbragstadif we do asymmetric, it would be easier for other service to validate tokens offline in middleware if they aren't encrypted17:49
lbragstadservices*17:50
lbragstadif that's something we want to support17:51
knikolladepending on if we're putting the roles in the token17:51
lbragstadayoung had a specification to include a maximum of one role in the token payload17:51
knikollawould be hard to have that AND default (and more granular) roles happen at the same time.17:53
lbragstadhow so?17:53
knikollamaybe too big of a step for the community to do at once?17:54
cmurphywouldn't the token need the catalog too? and then we're back to the problem with pki17:54
knikollai don't mind keystonemiddleware making a validate call, in general17:55
knikollabecause roles and service catalog are openstack concepts17:55
knikollafor outside services which don't care about that17:55
knikollaan asymmetrically signed token they can validate with enough user information may be enough for interop17:55
lbragstaddoes outside services mean other openstack services or something else?17:56
knikollanon-opensatck17:56
lbragstadok17:56
lbragstadyeah - it's tough where to draw the line between what makes sense to include and not include in the token17:56
lbragstadit really depends on what level of validation the service is going to do17:57
lbragstadi'm not sure if i clearly understand what that is yet =/17:57
lbragstaddo 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
lbragstaddo they want the service catalog?17:58
knikollai don't think they want the service catalog for one.17:59
knikollabecause if they want that, they know about openstack. so they can make a token validate call and get it.17:59
knikollaAs 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 token18:00
*** AlexeyAbashkin has quit IRC18:02
lbragstadso - maybe the question is, what do services want out of the token used to make the request?18:02
lbragstaddo they want to be able to have all the bit necessary to do policy enforcement, for example?18:03
knikollathat will be abstracted by keystonemiddleware anyway.18:04
knikollascope/role information will be available to the services regardless.18:04
cmurphythe 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 used18:04
lbragstadthat's true18:05
knikollamy gut feeling is to only include standard user information (username, email, etc) and the current project the token is scoped to.18:06
knikollahave everything else be fetched on a validate call.18:06
*** tesseract has quit IRC18:06
*** mvk has quit IRC18:07
knikolla(and of course the usual issued at, expires at, issuer, etc)18:08
lbragstadso - aside from the possibility of making it easier to validate tokens at the service18:11
cmurphyyeah, 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 guess18:11
*** prashkre has joined #openstack-keystone18:11
lbragstadthere is the possibility to make the key repository bits easier to manage between the keystone nodes of a deployment18:12
cmurphythe 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 sight18:12
knikollai don't think there's anything particularly sensitive in there.18:13
lbragstadi guess if i'm an operator and i think that stuff is sensitive, then i'd opt for fernet18:14
knikolladims: we're discussing jwt in case you want to join the discussion18:14
lbragstador maybe my deployment has to fill a check box that says that information can't be exposed18:15
knikollafernet would be a viable solution for that. and maybe in the future we implement jwe to replace fernet.18:16
* gagehugo sneaks back in18:16
lbragstador just a comparable alternative18:16
lbragstadi still believe we're primarily pursuing jwt (jws/jwe) to offer some alternative in the worst case scenario that something goes wrong with fernet18:17
lbragstadif we implement jwe, then replace or remove fernet, we're pretty close to square one in that we don't have a viable backup option18:17
knikollafor jws i'm also looking at the federation with external systems case18:18
knikollaa signed jwt with user information is similar to a saml assertion18:18
lbragstadregarding the asymmetric vs symmetric bits - do you have a inclination at which approach would make that story easier for you?18:19
cmurphysaml assertions can be encrypted too18:19
knikollacmurphy: yes, but the key of the intended audience.18:19
knikollawith jwe we're targeting keystone to be the issuer and audience.18:19
cmurphythat's true18:20
knikollalbragstad: 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-ssl18:20
lbragstadyeah18:21
lbragstadthere is another requirement i've heard before where a deployment spans large geographic regions18:21
lbragstadregion A and region B are part of the same cloud18:21
lbragstadbut there are data restrictions in region B that prevent users in region A from using it (or data crossing the border)18:22
lbragstadwhich is problematic when syncing the key repository18:22
cmurphywe'd have to sync keys no matter what, it's just a question of syncing public keys or private keys18:23
lbragstadright - i agree there18:23
lbragstadpublishing a public key would be "less scary" than syncing private keys is the justification i've heard18:24
knikollayou want the private key is an fewer places as you can generally.18:24
cmurphyif you publish a public key you'd have to establish some way of trusting it18:24
cmurphyi guess maybe just http and tls18:25
knikollaor ansible/puppet/etc.18:25
lbragstadif we did asymmetric with jws - each keystone node would only have it's own private key18:25
lbragstadwhich would be more consistent with the intended usage of a private key file18:25
lbragstadand the public key would be shared or distribute (however that happens)18:26
knikollapotentially that could solve the data restriction you mentioned above.18:26
lbragstadyeah - possibly18:27
knikollaas in you could have multiple keystones in the region and use the same token18:27
knikollai remember this is one of the use cases of the oranje (i think) people.18:28
lbragstadyeah18:28
lbragstadthey have datacenters in europe - and some of the new legislation affects stuff like that (also on the db replication layer)18:28
cmurphythat wouldn't solve their issue, there wouldn't be synchronized projects in each region so the tokens wouldn't be valid in all regions18:29
gagehugoyeah that's their usecase18:29
*** dklyle has joined #openstack-keystone18:30
lbragstadi thought they were going to work around that with a custom backend to handle orchestrating projects with the same ID across regions?18:30
lbragstadi thought we discussed something like that with them in office hours18:31
knikollacmurphy: 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
cmurphylbragstad: yes that was the workaround, but i think that was actually bad advice because we decided the resource driver is sql only18:32
lbragstadbah18:33
cmurphyknikolla: so then the token has to be validated across datacenters? that seems like a similar data restriction problem and also not very performant18:33
lbragstadhttps://github.com/openstack/keystone/blob/master/keystone/conf/resource.py#L23-L2718:34
cmurphywhich is why i'd like to undo all those foreign keys and fix that18:34
lbragstadso - iirc we're back to making k2k more performant18:35
lbragstador what cmurphy said18:35
cmurphythere are probably a lot of people still on newton who are going to be surprised by that18:35
knikollaa 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
knikollaaka make k2k use jwt.18:36
knikollawhere 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 IRC18:38
cmurphythat'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-keystone18:39
cmurphya saml assertion has a lot of crap18:39
knikollaboilerplate crap.18:39
knikollait can be boiled down to username, email, domain and project.18:40
knikollaso it's not really the opposite, it's almost the same information i was arguing for.18:41
cmurphyokay that's fair :)18:42
lbragstadok - approaching the question from a different angle18:44
lbragstaddoes 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 IRC18:46
knikollai can't really think of a use case where that would give us something over fernet.18:46
knikollayou need the private key to validate the token.18:47
knikollaif you have the private key you can sign the token.18:47
knikollasame is valid for fernet (+encryption)18:47
*** felipemonteiro has joined #openstack-keystone18:48
*** felipemonteiro_ has quit IRC18:48
*** felipemonteiro_ has joined #openstack-keystone18:49
lbragstadjwe 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 future18:49
knikollain other words: if you need the private key to verify it, potentially it doesn't matter if it is encrypted or not.18:49
lbragstadsure18:50
*** dklyle has joined #openstack-keystone18:51
lbragstadi kinda like the approach paseto takes18:52
lbragstadyou have a thing and you can configure it to give you encrypted tokens or signed tokens18:53
*** felipemonteiro has quit IRC18:53
lbragstadwhich ever you chose depends on your deployment18:53
lbragstadcmurphy: i guess you take on the resource backend might have an impact on https://review.openstack.org/#/c/559676/18:56
lbragstadyour take*18:56
knikollaarguably by sticking with a secure algorithm for jwt, and not processing anything else we get pretty close to paseto.18:56
*** dklyle has quit IRC18:57
lbragstadessentially - yeah18:57
knikollaas 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
cmurphylbragstad: yeah i have mixed feelings on it18:58
lbragstadcmurphy: i see what you mean (and i remember dstanek_ talking about stuff like that a long time ago)18:59
lbragstadit feels like we're constantly stuck in the middle18:59
lbragstadwe 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 used19:00
*** r-daneel_ has joined #openstack-keystone19:01
lbragstadknikolla: yeah - we will have to validate the algorithm in the token header within keystone for sure19:01
lbragstadsince that was one of the main issues in the JWT library vulnerability19:02
lbragstader - JWT vulnerability across libraries*19:02
*** r-daneel has quit IRC19:03
*** r-daneel_ is now known as r-daneel19:03
knikollalbragstad: do you think we have enough information from this discussion to start shaping up the spec?19:04
lbragstadi think so - but i wouldn't mind recapping19:05
lbragstadbased on the discussion19:05
lbragstaddo we see value in a signing implementation of a token provider?19:06
lbragstadi would say yes - only because it's not the only option available and people can always opt into using fernet if they want added security19:06
lbragstads/security/security through obscurity of encryption/19:07
lbragstadknikolla: cmurphy what other bigger points would you want included in the spec if any?19:13
cmurphylbragstad: I'd like to see huawei's use cases mentioned19:14
lbragstadwhich ones?19:15
lbragstadbah - that was a dumb question, you probably want to see all of them19:15
cmurphylbragstad: i don't know, what are your use cases? why is huawei pushing for it?19:15
knikollaFederation use cases. Enough information to be useful for external systems. Aka keystone as an idp with jwt.19:15
cmurphywe 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 now19:15
lbragstadthe main reason we want it is for the asymmetric signing bit19:16
lbragstadhuawei used PKI for a long time, and they wanted something that would eventually behave similarly19:17
gagehugokeystone as an idp with jwt is something I know was brought up before19:17
gagehugoI think kubernetes intergration is something too19:17
lbragstadthere was also hesitation internally about sharing symmetric keys across large deployments19:18
*** pcichy has quit IRC19:22
lbragstadeven though there are other hurdles there19:23
lbragstad(db replication and whatnot)19:24
*** AlexeyAbashkin has joined #openstack-keystone19:25
*** r-daneel_ has joined #openstack-keystone19:29
*** r-daneel has quit IRC19:30
*** r-daneel_ is now known as r-daneel19:30
lbragstadso - i think those are the two huawei usecases19:31
lbragstadbut wxy might be able to give more insight19:32
*** AlexeyAbashkin has quit IRC19:34
cmurphyI think solidifying those use cases would inform the technical decisions we need to make19:35
lbragstadi can add them19:36
cmurphyif 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 accordingly19:36
cmurphyor if having a PKI replacement is a top design goal then we might need to rethink some things19:37
lbragstadsure - that makes sense, i don't think it would be a PKI replacement19:38
lbragstadi 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 against19:39
lbragstadwhile providing some level of security in the sense that we have something to backup fernet19:39
*** jdennis has joined #openstack-keystone19:46
*** harlowja has joined #openstack-keystone19:50
*** dklyle has joined #openstack-keystone19:52
*** jdennis has quit IRC20:16
kmalloclbragstad: if we support JWT, at least if fernet has an OOPSE, we have an out20:18
kmallocJWE long term goal when we van20:18
kmalloccan*20:18
kmallocright now, a PKI replacement is not realistic, short of JWE20:19
lbragstadyeah - i'm not saying we should reimplement PKI with JWT20:21
*** dklyle has quit IRC20:21
kmallocand i would LOVE to see JWE20:22
kmallocbut... i'm realistic20:22
kmalloci would like us to be on JWT in general for reasons of $STANDARDS$20:22
lbragstadbut... 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 tree20:22
kmallocyeah20:22
kmallocthat is true20:22
kmallocalso... if your employer wants to dedicate resources to PKI-like implementation on the JWT base [it's a lot of leg work]20:23
kmalloci'm happy to have that.20:23
kmallocbut I want it to be clearly part of the standards and it would need ot be (pref) in a lib we can consume20:23
kmalloc(one of the main-stream libs)20:24
kmalloci also agree with cmurphy, clear use-cases documented = win20:25
lbragstadthat's what i'm working on now20:25
kmalloccool20:25
lbragstadfwiw - if we did the asymmetric route - we'd be targetting the RS256 algorithm20:26
kmallocyeah20:30
kmalloci would expect as much20:30
*** raildo has quit IRC20:30
kmallocfwiw, it should be easy to implement both rS256 and HS25620:31
*** dklyle has joined #openstack-keystone20:31
kmalloc(relatively)20:31
*** sapd__ has joined #openstack-keystone20:40
*** links has quit IRC20:42
*** pcaruana has quit IRC20:42
*** sapd_ has quit IRC20:43
*** oikiki has joined #openstack-keystone20:51
openstackgerritDoug Hellmann proposed openstack/keystoneauth master: add lower-constraints job  https://review.openstack.org/55562520:58
openstackgerritDoug Hellmann proposed openstack/keystoneauth master: fix pep8 errors caused by pycodestyle>=2.4.0  https://review.openstack.org/56205220:58
openstackgerritLance Bragstad proposed openstack/keystone-specs master: Repropose JWT specification for Rocky  https://review.openstack.org/54190321:11
*** mvk has joined #openstack-keystone21:14
lbragstadkmalloc: cmurphy knikolla gagehugo wxy updated with usecases21:16
lbragstad^21:16
lbragstadi guess the next step is determining if they are valid and adding missing ones21:17
lbragstadi'll rework the specifications technical details after that21:18
*** prashkre_ has joined #openstack-keystone21:19
*** prashkre has quit IRC21:19
lbragstad#endmeeting21: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
openstackMeeting ended Tue Apr 17 21:21:00 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:21
openstackMinutes:        http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-04-17-17.00.html21:21
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-04-17-17.00.txt21:21
openstackLog:            http://eavesdrop.openstack.org/meetings/keystone_office_hours/2018/keystone_office_hours.2018-04-17-17.00.log.html21:21
lbragstadprobably should have done that about 20 minutes ago21:21
*** edmondsw has quit IRC21:24
*** dklyle has quit IRC21:42
*** dklyle has joined #openstack-keystone21:46
gagehugolbragstad Is there any reason to consider using python-jose if it offers the same functionality as pyjwt?21:47
*** jmlowe has quit IRC22:00
*** fiddletwix has quit IRC22:03
*** fiddletwix has joined #openstack-keystone22:07
*** felipemonteiro_ has quit IRC22:10
*** jmlowe has joined #openstack-keystone22:16
*** fiddletwix has quit IRC22:18
*** pcichy has joined #openstack-keystone22:22
*** pcichy has quit IRC22:23
*** dklyle has quit IRC22:27
*** pcichy has joined #openstack-keystone22:35
*** pcichy has quit IRC22:37
*** rcernin has joined #openstack-keystone22:42
*** jdennis has joined #openstack-keystone22:46
*** r-daneel has quit IRC22:46
*** r-daneel has joined #openstack-keystone22:52
*** oikiki has quit IRC23:09
*** oikiki has joined #openstack-keystone23:09
*** oikiki has quit IRC23:09
*** r-daneel has quit IRC23:18
*** oikiki has joined #openstack-keystone23:19
*** jdennis has quit IRC23:19
*** spilla has quit IRC23:23
*** oikiki has quit IRC23:29
*** oikiki has joined #openstack-keystone23:29
*** oikiki has quit IRC23:30
*** jdennis has joined #openstack-keystone23:42
*** jmlowe_ has joined #openstack-keystone23:44
*** jmlowe has quit IRC23:47
*** r-daneel has joined #openstack-keystone23:47
*** r-daneel has quit IRC23:59

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!