18:01:18 #startmeeting keystone 18:01:19 Meeting started Tue Nov 20 18:01:18 2012 UTC. The chair is heckj. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:21 The meeting name has been set to 'keystone' 18:01:30 I have sent an email to the list suggestions some topics for discussion 18:01:54 KEYSTONE! 18:01:59 dwchadwick: sounds reasonable - I'm behind on email by several hundred at the moment, so I haven't seen it though... 18:02:07 agenda: http://wiki.openstack.org/Meetings/KeystoneMeeting 18:02:29 #topic burning issues 18:02:57 I can repeat the list here if you like 18:03:15 We have a security bug that we're working (not public) - Dolph has posted patches, core needs to vet. 18:03:20 heckj, I don;t think any outstanding bugs are burning issues right now. 18:03:30 ayoung: I subscribed you: https://bugs.launchpad.net/keystone/+bug/1079216 18:03:49 (note: everyone else will likely get a 404 on that link, since it's marked security) 18:04:31 dwchadwick: your list would be welcome, thank you 18:05:11 In no particular order 18:05:15 1. Groups vs. attribute mappings 18:05:15 2. Adding IDPs to service catalog 18:05:16 https://blueprints.launchpad.net/keystone/+spec/adding-idps-to-service-catalog 18:05:16 3. RBAC API, and why have tenants/projects? or groups for that matter? 18:05:16 4. Delegation 18:05:16 http://wiki.openstack.org/keystone/Delegation 18:05:16 5. Status/Timeframe of Federation integration 18:05:17 http://wiki.openstack.org/Keystone/Federation/Blueprint 18:05:56 dwchadwick: will add to agenda, as I suspect we won't get through that all 18:06:12 #topic V3 API 18:06:16 so we should prioritse first 18:06:43 I guess groups vs attribute mappings comes under this agenda item 18:07:09 getting V3 in is, I think priority, as is the other changes that are causing us to "lock down" sections of the code for changes 18:07:11 Review's are up - catalog pending attention, ayoung and dolph working on Identity along with database refactoring and normalization 18:07:26 ayoung: yep, agreed 18:07:45 We won't have all the V3 in for this first milestone, so I'll retarget that to G2 prior to the release meeting today 18:07:48 that means auth_token changes from here on out only go into keystoneclient 18:08:04 we have posted a blueprint that shows how IDPs can be added to the catalog with no changes to the API 18:08:50 dwchadwick, link? 18:09:11 Kristy should have posted it to the list. Its in google docs 18:09:17 #link http://wiki.openstack.org/Keystone/Federation/Blueprint 18:09:18 #link https://blueprints.launchpad.net/keystone/+spec/adding-idps-to-service-catalog 18:09:56 yep its here 18:10:00 https://docs.google.com/a/kent.ac.uk/document/d/1aXjt7XMEc2wQqSli8B9pB2NTjCiSe8Nz-H5xVMb8saw/edit 18:10:21 joined 18:10:48 * heckj wave 18:10:52 We are proposing two changes to the client but none to keystone 18:11:12 1. made the type a type.subtype 18:11:34 this should help with scalability as more services are added in the future, and different types of IDPs 18:11:47 but to keystone is it still just a string, so no changes 18:12:25 dwchadwick, is it possible that the change will trip up on some previous data? 18:12:45 say someone has already named their types that way? 18:12:48 2. I dont think so, since all types today are simply types and dont use subtypes 18:12:50 dwchadwick: i'm confused on how you say you don't need to modify the API, but then turn around and specify that the client needs to be passing at least two new pieces of data to the keystone server, via the API? 18:13:04 So only future types of services (like IDPs) can make use of subtype 18:13:06 dolphm, I think he means it is a format of the string 18:13:34 Its a new optional parameter that clients add at their end 18:13:51 ayoung: dwchadwick: i'm referring to certdata and protocol, not 'type', which is just an opaque string to keystone 18:13:57 but the keystone database does not change cos it is all bundled in the extras field 18:14:09 --certdata – the identity provider certificate data for signing and verification. +1 there 18:14:42 probably should be a file name. 18:14:44 yes this is a new parameter that the client can optionally add 18:14:58 Hi, correct me if I'm wrong but the service data is stored as a jsonblob in the extra field of the database? 18:14:58 dwchadwick, should tag that as optional, too. 18:15:03 so it is backwards compatible with current implementations 18:15:23 So certdata and protocol could be adding to that without changing anything? 18:15:25 We also will need a way to set and update it after the endpoint has been created for existing endpoints and cert expiration 18:15:27 yes its optional 18:15:31 ayoung, dwchadwick: what explicitly is the cert data? Is this an endpoint with where to get the identity information, or a certificate that can be used to verify requests to access the service? 18:16:10 ksiu, not a fan of 'extra' I would love to focus on keeping stuff normalized. serialization of JSON is an antipattern in my book 18:16:10 heckj: it's the certificate use to validate the signed response from the Identity provider 18:16:32 dwchadwick: what do you expect the client to do with --certdata, for example? 18:16:36 heckj, say an endpoint is allowed to sign certs, it is the cert it would present for other services to verify them 18:16:52 ayoung: +1 - was intended as a placeholder until it was clear what we wanted/needed to model and capture 18:17:09 the client will pass cert data back to the credential issuing component of federated keystone, so it does not need to touch it 18:18:06 is the way of storing the service data changing in V3? 18:18:18 dwchadwick, I kind of see this still as just the stub of the effort for cert management for endpoints. The workflow will likely be slightly more complicated. But I would classify this as "necsssary first steps" 18:18:25 federated keystone is responsible for doing all the work. The client simply gets parameters from one part of keystone and passes them back to another part 18:18:28 ksiu: not really https://review.openstack.org/#/c/15610/7/keystone/catalog/backends/sql.py 18:19:22 ksiu: driver is a little more robust, and API-level service/endpoint crud is pretty much 1:1 with the driver 18:20:12 Have we stalled? 18:20:37 dwchadwick: i absolutely don't see statement as being realistic- "As mentioned previously no changes to the Keystone service would be required to store and retrieve the extra data." 18:21:45 It depends upon where the json blob is created. If the client creates it, then keystone does not see the change. 18:21:46 dolphm: perhaps I have misunderstood the way the endpoint and service data is stored but it looked to me as if it was stored in a jsonblob in the extra field 18:22:25 So we have defined a parameter that the user passes to the client (the certdata) and the client software packages this into the json blob 18:22:26 dwchadwick, "extra" is not part of the API, just a storage detail; 18:23:04 more correct to say you have added an additional field to the API. I think that is ok, but only if it is optional. Which, I think, it is. 18:23:48 BTW there is a mistake in the diagram as we dont need protocol. This was in an earlier design but has been removed from the text but the diagram was not updated to conform to the new text 18:24:03 dwchadwick: 'localurl' should also read 'internalurl' 18:24:27 Ok. Kristy will update the doc tomorrow 18:25:10 sounds like we all need to do a little more reading to have an intelligent response 18:25:18 dwchadwick, ksiu might I suggest then that you post images as svg files, and other people can then modify them? 18:25:22 So can I understand the message that is passed from the client to keystone. Does it contain a json blob or not? And if it does, does it contains an extra field 18:26:14 ayoung: noted 18:26:58 dwchadwick: 'extra' is not exposed to the API per se 18:27:23 dwchadwick: the driver stores non-indexed attributes of services & endpoints as a JSON blob in a column called 'extra' 18:27:52 we assumed the client could pass extra to keystone for it to store. This would make a sensible extension point 18:28:14 dwchadwick: how it presents them is something we can extend into the API, which is what we want/need to define to enable this 18:28:42 Of course it could not be indexed because keystone has no idea what is contained there, except some random string of random lenght 18:28:47 dwchadwick: the service implementation is flexible in that it handles attributes it doesn't otherwise understand 18:29:15 So an alternative would be to define an attribute called certificate? 18:29:19 dwchadwick: the client must still adhere to a tested contract, in this case, i imagine you're envision a v2.0 API extension, and perhaps an extension to the OS-KSADM extension 18:29:27 dwchadwick: (unless you're only talking about v3 support) 18:30:11 I think we can wait to v3 for this, since it is not needed until you have federated keystone, which I assume will be v3 (but that is another agenda item) 18:30:38 the thing that is most pressing for v2 seems to be groups vs attribute mapping 18:30:50 dwchadwick: great that simplifies things quite a bit then! 18:31:31 dwchadwick: user groups? 18:31:35 shall we move to groups vs mappings 18:31:47 do we think groups vs attribute mapping is a v2 thing? I could be, but I had imagined part of v3 18:31:48 dolphm: yes 18:31:53 dwchadwick: please get me agenda suggestions earlier next time 18:32:08 sorry, but I was in meetings most of the day 18:32:33 dwchadwick: me too - is okay - just trying to keep things organized, and we've jumped all over 18:32:43 i haven't been following user group discussions, but there's already a defined API for them that was implemented in diablo: https://github.com/openstack/identity-api/tree/master/openstack-identity-api/src/docbkx/extensions/RAX-KSGRP 18:33:17 henrynash: I managed to get you some feedback this weekend, but haven't followed up since I sent off the initial sets 18:33:17 I am pretty much against groups, since they are no different to roles 18:33:30 dwchadwick, not correct 18:33:36 dwchadwick: I disagree entirely 18:33:42 ayoung: in what way 18:33:47 dwchadwick, they are an essential organizational tool. 18:33:55 roles must be assigned to something 18:34:05 and usually, they are assigned to a user 18:34:11 if you were to say that groups are roles 18:34:12 what you are saying is that there are two different types of roles: organisational roles and cloud service roles 18:34:13 i like the definition provided at the summit: "every operation you can apply to a user, you should be able to apply to a group of users" 18:34:15 groups allow us to not have to submit 10's or 100's of links from user < -- role --> project, but manage that in explicit "groups" 18:34:31 so, "grant this role on this project to this entire group of users" 18:34:38 you have no way to reuse things...it all falls on the back of the policy enforcement 18:34:44 dwchadwick: this isn't about different roles, but applying roles to sets of users 18:34:57 a group is just another collection, same as a role (or better still get rid of roles and call them all attributes) 18:35:31 dwchadwick: roles have explicit associations with domains or projects, however 18:35:34 dwchadwick, they are all "attributes" but that doesn't mean that there are not semantic differences. 18:35:56 dwchadwick: roles == attribute is fine from an academic perspective, but will consfuse laymen trying to implement this and looking for what they're considering "roles" 18:36:00 what you want is a mechanism to say people with this attribute (which you call group) also have this attribute (which you call role) 18:36:45 dwchadwick, right 18:36:48 dwchadwick: you're already talking in groups, but we don't have "woking with sets of people" built in to our API 18:36:52 Of course different attributes have different semantics 18:37:04 dwchadwick: the second half of your statement is meaningless unless you also specify the domain/project the "attribute" applies to 18:37:04 But ultimately what you are interested in is ABAC 18:37:24 ie. a user with this set of attributes gets access to this set of resources 18:37:25 dwchadwick, well, I am, but most people think I am crazy 18:37:50 please define ABAC 18:38:02 heckj, attribute based access control 18:38:08 thans 18:38:10 I think the challenge is we have a set of definitions (e.g. what a role is) already for keystone, we need to decide if we are going to re-define all that, or work to extend these in the direction of organisational (roles) as well as mapping to external defintions 18:38:25 heckj, so for instance, "you must be older than 18 to purchase cigarrettes." 18:38:41 ayoung: correct 18:38:47 the attribute age is evaluated against a criteria to determine access 18:39:08 it is the most generl form of auth, with RBAC a simplified version, etc 18:39:12 which is why I question why you need tenants either, since these are simply another type of attribute which grant you access to a set of resources 18:39:14 ayoung: understood. I think henrynash's has it in a nutshell though 18:39:23 dwchadwick: is there a precedence contextual attributes? 18:40:03 dwchadwick: e.g. i have a purple-shirt, but only under a blacklight 18:40:24 dwchadwick, two sides to it, one of which is granting access, and the other is providing the pieces for people to manage that access. We are trying to provide a reasonable subset of atttributes that map to how most tech-based organizations already perform auth control 18:40:38 I would like us to define an ABAC interface for authorisation, where you pass a bunch of attributes and get a response. One of the attributes can be tenant=idx, another can be role=admin and another can be age=19 18:41:09 Then we have a clean and simple interface that is fully flexible and extensible 18:41:13 dwchadwick, the thing is, role is really the tuple "role-name, tenant-name" 18:41:39 yes, and all of these concepts are confusing and end up creating spaghetti 18:41:55 So maybe the things is, we might indeed want to propose an ABAC interface, but in the meantime how to we have an RBAC interface that works well for enterprises? 18:41:57 so "role:vm-administrator in tenant:live-servers" is different from "role:vm-administrator in tenant:staging-servers" 18:42:26 well ABAC is a superset of RBAC, so it can be introduced and be backwards compatible 18:42:35 I would hope :-) 18:42:39 dwchadwick: I'm not at all opposed to that style of implementation, it fits pretty reasonably with the policy mechanisms that we're using to gate authorization today, but we need to continue to evolve, not trash and rebuild, the API and mechanisms we have today as well. We should not go for a "all in one rewrite" at this stage. 18:42:47 http://covers.openlibrary.org/b/id/6611047-M.jpg 18:43:28 heckj: i like the approach but know how to implement while maintaining backwards compatibility with roles 18:43:28 neither should we complicate the interface by adding yet more concepts like groups 18:43:32 dwchadwick: agree, but not sure we can go there in one hop 18:43:57 dwchadwick: to previous comment don't agree that we should not add groups 18:44:07 dwchadwick, OK, here is what we need: a mechanism to apply the same set of attributes to more than one user at a time. 18:44:26 the first thing to do is design the new interface and then see how it can be made to migrate from the existing one to it 18:44:54 dwchadwick: For reasonable management, I don't see how we can avoid adding groups. The alternative is asking administrators of clouds to manage sets of individuals totally externally, or hack solutions in of their own. 18:45:05 henrynash: we are specifying the attribute mapping interface now which should give you what you want 18:45:08 ayoung: +1 18:45:22 ayoung: would need to also being able to specify an operation against a set of users with an arbitrary attribute 18:45:39 ayoung: attribute mapping 18:46:18 dwchadwick, I think I might not have understood that concept that way when we discussed before 18:46:21 ayoung: anyone who is in group=my group has role=admin 18:46:23 ayoung: isn't role a name for an amalgam of permissions, the same way that group is a name for an amalgam of users? If so, solving one problem might solve two. 18:46:26 …and all in a way that is simple for non-federated openstack implementations which will be the norm for some time to come 18:46:56 dwchadwick: what's the benefit of an attribute mapping API without also changing the rest of the API to operate on attributes, and can you do that while maintaining backwards compatibility with the existing API in a single implementation? 18:47:03 attribute mapping is completely independent of federation 18:47:17 dwchadwick, right. I think that is what we are trying to get at with groups. 18:47:41 mapping is a more general purpose mechanism, but could be used to implement groups. 18:47:57 i just gave an example above 18:48:28 dwchadwick, right...what I am thinking is that groups could be "pre-canned" attribute mappings 18:48:42 the interface we are proposing will allow organisations to define their own groups and say what roles they should have 18:49:26 So the risk is that if we do groups, we find, in the further, when we have ABAC, that we could implement the same ability….but in the meantime we have delivered the "normal way of doing this in RBAC environments" to build the acceptance of openstack 18:49:48 dwchadwick, I'm kindof thinking that we might want to pull that out into its own blueprint, then, and specify how we would implement groups in terms of mapping 18:50:01 ayoung: not precanned, because you dont know what groups organisations will have. Henry gave examples of programmers, team leaders in one org, and teacher, pupil in another org 18:50:14 dwchadwick +1 18:50:23 ayoung: we're working on that 18:50:36 Our blueprint will be out this week. We sketched it out today and Kristy is currently writing it up 18:51:22 henrynash, I realize you want to get moving on this. Can you work with Kristy on just that piece, and see if we can do it in such a way as to A) get it in to grizzly and B) support what you need from groups? 18:51:45 It seems like it is at least worth evaluating the approach 18:52:11 It would be good if Henry could work with Kristy, since we are newbies to Openstack and Henry probably knows lots more than us about the internals 18:52:51 it might be that we have to punt on the mapping approach if we can't get it in to Grizzly, in which case we accept groups approach as "stop gap" and we plan on reworking groups in terms of mappings in "H*" time? 18:53:36 sure, happy to work with Kirtsy to investigate 18:53:42 great 18:53:44 henrynash has PM'ed me "sure" which I think means he is willing to do it, and is accepting that my neck is not within throttling distance. 18:54:04 ayoung :-) 18:54:14 Kristy is also able to work on the implementation to speed things up if the design is accepted 18:54:40 I'd be keen to see the mapping design, anyhow 18:54:48 What time frame are you looking at for grizzly release 18:55:04 http://wiki.openstack.org/GrizzlyReleaseSchedule 18:55:05 we got to get it in for grizzly-2 ? 18:55:17 all code implemented by Feb 21st at the latest 18:55:27 Jan 10th is much safer 18:55:43 (jan 10th is grizzly-2 milestone) 18:55:45 Grizzly 2 should be Ok for the first release 18:56:20 I can see a phased approach to implementation, with non-federated access initially then federated access afterwards 18:56:54 We want to get to the stage where the administrators dont have to have their un/pws configured into keystone, but use their own external IDP 18:57:11 for something like this, i say we must hit grizzly-2 18:57:45 What time is this call due to end? 18:57:46 going to have wrap this up in 2 minutes 18:58:00 Ok, so I will go now as I have an appointment. Bye 19:00:06 #endmeeting