18:01:18 <heckj> #startmeeting keystone
18:01:19 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:01:21 <openstack> The meeting name has been set to 'keystone'
18:01:30 <dwchadwick> I have sent an email to the list suggestions some topics for discussion
18:01:54 <ayoung> KEYSTONE!
18:01:59 <heckj> dwchadwick: sounds reasonable - I'm behind on email by several hundred at the moment, so I haven't seen it though...
18:02:07 <heckj> agenda: http://wiki.openstack.org/Meetings/KeystoneMeeting
18:02:29 <heckj> #topic burning issues
18:02:57 <dwchadwick> I can repeat the list here if you like
18:03:15 <heckj> We have a security bug that we're working (not public)  - Dolph has posted patches, core needs to vet.
18:03:20 <ayoung> heckj, I don;t think any outstanding bugs are burning issues right now.
18:03:30 <heckj> ayoung: I subscribed you: https://bugs.launchpad.net/keystone/+bug/1079216
18:03:49 <heckj> (note: everyone else will likely get a 404 on that link, since it's marked security)
18:04:31 <heckj> dwchadwick: your list would be welcome, thank you
18:05:11 <dwchadwick> In no particular order
18:05:15 <dwchadwick> 1. Groups vs. attribute mappings
18:05:15 <dwchadwick> 2. Adding IDPs to service catalog
18:05:16 <dwchadwick> https://blueprints.launchpad.net/keystone/+spec/adding-idps-to-service-catalog
18:05:16 <dwchadwick> 3. RBAC API, and why have tenants/projects? or groups for that matter?
18:05:16 <dwchadwick> 4. Delegation
18:05:16 <dwchadwick> http://wiki.openstack.org/keystone/Delegation
18:05:16 <dwchadwick> 5. Status/Timeframe of Federation integration
18:05:17 <dwchadwick> http://wiki.openstack.org/Keystone/Federation/Blueprint
18:05:56 <heckj> dwchadwick: will add to agenda, as I suspect we won't get through that all
18:06:12 <heckj> #topic V3 API
18:06:16 <dwchadwick> so we should prioritse first
18:06:43 <dwchadwick> I guess groups vs attribute mappings comes under this agenda item
18:07:09 <ayoung> 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 <heckj> Review's are up - catalog pending attention, ayoung and dolph working on Identity along with database refactoring and normalization
18:07:26 <heckj> ayoung: yep, agreed
18:07:45 <heckj> 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 <ayoung> that means auth_token changes from here on out only go into keystoneclient
18:08:04 <dwchadwick> we have posted a blueprint that shows how IDPs can be added to the catalog with no changes to the API
18:08:50 <ayoung> dwchadwick, link?
18:09:11 <dwchadwick> Kristy should have posted it to the list. Its in google docs
18:09:17 <ayoung> #link http://wiki.openstack.org/Keystone/Federation/Blueprint
18:09:18 <dolphm> #link https://blueprints.launchpad.net/keystone/+spec/adding-idps-to-service-catalog
18:09:56 <dwchadwick> yep its here
18:10:00 <dwchadwick> https://docs.google.com/a/kent.ac.uk/document/d/1aXjt7XMEc2wQqSli8B9pB2NTjCiSe8Nz-H5xVMb8saw/edit
18:10:21 <henrynash> joined
18:10:48 * heckj wave
18:10:52 <dwchadwick> We are proposing two changes to the client but none to keystone
18:11:12 <dwchadwick> 1. made the type a type.subtype
18:11:34 <dwchadwick> this should help with scalability as more services are added in the future, and different types of IDPs
18:11:47 <dwchadwick> but to keystone is it still just a string, so no changes
18:12:25 <ayoung> dwchadwick, is it possible that the change will trip up on some previous data?
18:12:45 <ayoung> say someone has already named their types that way?
18:12:48 <dwchadwick> 2. I dont think so, since all types today are simply types and dont use subtypes
18:12:50 <dolphm> 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 <dwchadwick> So only future types of services (like IDPs) can make use of subtype
18:13:06 <ayoung> dolphm, I think he means it is a format of the string
18:13:34 <dwchadwick> Its a new optional parameter that clients add at their end
18:13:51 <dolphm> ayoung: dwchadwick: i'm referring to certdata and protocol, not 'type', which is just an opaque string to keystone
18:13:57 <dwchadwick> but the keystone database does not change cos it is all bundled in the extras field
18:14:09 <ayoung> --certdata – the identity provider certificate data for signing and verification.  +1 there
18:14:42 <ayoung> probably should be a file name.
18:14:44 <dwchadwick> yes this is a new parameter that the client can optionally add
18:14:58 <ksiu> 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 <ayoung> dwchadwick, should tag that as optional, too.
18:15:03 <dwchadwick> so it is backwards compatible with current implementations
18:15:23 <ksiu> So certdata and protocol could be adding to that without changing anything?
18:15:25 <ayoung> 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 <dwchadwick> yes its optional
18:15:31 <heckj> 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 <ayoung> 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 <ksiu> heckj: it's the certificate use to validate the signed response from the Identity provider
18:16:32 <dolphm> dwchadwick: what do you expect the client to do with --certdata, for example?
18:16:36 <ayoung> 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 <heckj> ayoung: +1 - was intended as a placeholder until it was clear what we wanted/needed to model and capture
18:17:09 <dwchadwick> 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 <ksiu> is the way of storing the service data changing in V3?
18:18:18 <ayoung> 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 <dwchadwick> 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 <dolphm> ksiu: not really https://review.openstack.org/#/c/15610/7/keystone/catalog/backends/sql.py
18:19:22 <dolphm> ksiu: driver is a little more robust, and API-level service/endpoint crud is pretty much 1:1 with the driver
18:20:12 <dwchadwick> Have we stalled?
18:20:37 <dolphm> 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 <dwchadwick> It depends upon where the json blob is created. If the client creates it, then keystone does not see the change.
18:21:46 <ksiu> 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 <dwchadwick> 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 <ayoung> dwchadwick, "extra" is not part of the API, just a storage detail;
18:23:04 <ayoung> 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 <dwchadwick> 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 <dolphm> dwchadwick: 'localurl' should also read 'internalurl'
18:24:27 <dwchadwick> Ok. Kristy will update the doc tomorrow
18:25:10 <heckj> sounds like we all need to do a little more reading to have an intelligent response
18:25:18 <ayoung> dwchadwick, ksiu might I suggest then that you post images as svg files, and other people can then modify them?
18:25:22 <dwchadwick> 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 <ksiu> ayoung: noted
18:26:58 <dolphm> dwchadwick: 'extra' is not exposed to the API per se
18:27:23 <dolphm> dwchadwick: the driver stores non-indexed attributes of services & endpoints as a JSON blob in a column called 'extra'
18:27:52 <dwchadwick> we assumed the client could pass extra to keystone for it to store. This would make a sensible extension point
18:28:14 <heckj> 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 <dwchadwick> 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 <dolphm> dwchadwick: the service implementation is flexible in that it handles attributes it doesn't otherwise understand
18:29:15 <dwchadwick> So an alternative would be to define an attribute called certificate?
18:29:19 <dolphm> 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 <dolphm> dwchadwick: (unless you're only talking about v3 support)
18:30:11 <dwchadwick> 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 <dwchadwick> the thing that is most pressing for v2 seems to be groups vs attribute mapping
18:30:50 <dolphm> dwchadwick: great that simplifies things quite a bit then!
18:31:31 <dolphm> dwchadwick: user groups?
18:31:35 <dwchadwick> shall we move to groups vs mappings
18:31:47 <henrynash> do we think groups vs attribute mapping is a v2 thing?  I could be, but I had imagined part of v3
18:31:48 <dwchadwick> dolphm: yes
18:31:53 <heckj> dwchadwick: please get me agenda suggestions earlier next time
18:32:08 <dwchadwick> sorry, but I was in meetings most of the day
18:32:33 <heckj> dwchadwick: me too - is okay - just trying to keep things organized, and we've jumped all over
18:32:43 <dolphm> 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 <heckj> 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 <dwchadwick> I am pretty much against groups, since they are no different to roles
18:33:30 <ayoung> dwchadwick, not correct
18:33:36 <heckj> dwchadwick: I disagree entirely
18:33:42 <dwchadwick> ayoung: in what way
18:33:47 <ayoung> dwchadwick, they are an essential organizational tool.
18:33:55 <ayoung> roles must be assigned to something
18:34:05 <ayoung> and usually, they are assigned to a user
18:34:11 <ayoung> if you were to say that groups are roles
18:34:12 <dwchadwick> what you are saying is that there are two different types of roles: organisational roles and cloud service roles
18:34:13 <dolphm> 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 <heckj> 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 <dolphm> so, "grant this role on this project to this entire group of users"
18:34:38 <ayoung> you have no way to reuse things...it all falls on the back of the policy enforcement
18:34:44 <heckj> dwchadwick: this isn't about different roles, but applying roles to sets of users
18:34:57 <dwchadwick> 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 <dolphm> dwchadwick: roles have explicit associations with domains or projects, however
18:35:34 <ayoung> dwchadwick, they are all "attributes" but that doesn't mean that there are not semantic differences.
18:35:56 <heckj> 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 <dwchadwick> 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 <ayoung> dwchadwick, right
18:36:48 <heckj> 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 <dwchadwick> Of course different attributes have different semantics
18:37:04 <dolphm> dwchadwick: the second half of your statement is meaningless unless you also specify the domain/project the "attribute" applies to
18:37:04 <dwchadwick> But ultimately what you are interested in is ABAC
18:37:24 <dwchadwick> ie. a user with this set of attributes gets access to this set of resources
18:37:25 <ayoung> dwchadwick, well, I am, but most people think I am crazy
18:37:50 <heckj> please define ABAC
18:38:02 <ayoung> heckj, attribute based access control
18:38:08 <heckj> thans
18:38:10 <henrynash> 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 <ayoung> heckj, so for instance, "you must be older than 18 to purchase cigarrettes."
18:38:41 <dwchadwick> ayoung: correct
18:38:47 <ayoung> the attribute age is evaluated against a criteria to determine access
18:39:08 <ayoung> it is the most generl form of auth,  with RBAC a simplified version, etc
18:39:12 <dwchadwick> 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 <heckj> ayoung: understood. I think henrynash's has it in a nutshell though
18:39:23 <dolphm> dwchadwick: is there a precedence contextual attributes?
18:40:03 <dolphm> dwchadwick: e.g. i have a purple-shirt, but only under a blacklight
18:40:24 <ayoung> 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 <dwchadwick> 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 <dwchadwick> Then we have a clean and simple interface that is fully flexible and extensible
18:41:13 <ayoung> dwchadwick, the thing is, role is really the tuple "role-name, tenant-name"
18:41:39 <dwchadwick> yes, and all of these concepts are confusing and end up creating spaghetti
18:41:55 <henrynash> 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 <ayoung> so "role:vm-administrator in tenant:live-servers" is different from "role:vm-administrator in tenant:staging-servers"
18:42:26 <dwchadwick> well ABAC is a superset of RBAC, so it can be introduced and be backwards compatible
18:42:35 <dwchadwick> I would hope :-)
18:42:39 <heckj> 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 <ayoung> http://covers.openlibrary.org/b/id/6611047-M.jpg
18:43:28 <dolphm> heckj: i like the approach but know how to implement while maintaining backwards compatibility with roles
18:43:28 <dwchadwick> neither should we complicate the interface by adding yet more concepts like groups
18:43:32 <henrynash> dwchadwick: agree, but not sure we can go there in one hop
18:43:57 <henrynash> dwchadwick: to previous comment don't agree that we should not add groups
18:44:07 <ayoung> 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 <dwchadwick> 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 <heckj> 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 <dwchadwick> henrynash: we are specifying the attribute mapping interface now which should give you what you want
18:45:08 <heckj> ayoung: +1
18:45:22 <dolphm> ayoung: would need to also being able to specify an operation against a set of users with an arbitrary attribute
18:45:39 <dwchadwick> ayoung: attribute mapping
18:46:18 <ayoung> dwchadwick, I think I might not have understood that concept that way when we discussed before
18:46:21 <dwchadwick> ayoung: anyone who is in group=my group has role=admin
18:46:23 <brich1> 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 <henrynash> …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 <dolphm> 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 <dwchadwick> attribute mapping is completely independent of federation
18:47:17 <ayoung> dwchadwick, right.  I think that is what we are trying to get at with groups.
18:47:41 <ayoung> mapping is a more general purpose mechanism, but could be used to implement groups.
18:47:57 <dwchadwick> i just gave an example above
18:48:28 <ayoung> dwchadwick, right...what I am thinking is that groups could be "pre-canned" attribute mappings
18:48:42 <dwchadwick> the interface we are proposing will allow organisations to define their own groups and say what roles they should have
18:49:26 <henrynash> 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 <ayoung> 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 <dwchadwick> 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 <henrynash> dwchadwick +1
18:50:23 <ksiu> ayoung: we're working on that
18:50:36 <dwchadwick> Our blueprint will be out this week. We sketched it out today and Kristy is currently writing it up
18:51:22 <ayoung> 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 <ayoung> It seems like it is at least worth evaluating the approach
18:52:11 <dwchadwick> 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 <ayoung> 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 <henrynash> sure, happy to work with Kirtsy to investigate
18:53:42 <dwchadwick> great
18:53:44 <ayoung> 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 <henrynash> ayoung :-)
18:54:14 <dwchadwick> Kristy is also able to work on the implementation to speed things up if the design is accepted
18:54:40 <henrynash> I'd be keen to see the mapping design, anyhow
18:54:48 <dwchadwick> What time frame are you looking at for grizzly release
18:55:04 <heckj> http://wiki.openstack.org/GrizzlyReleaseSchedule
18:55:05 <henrynash> we got to get it in for grizzly-2 ?
18:55:17 <heckj> all code implemented by Feb 21st at the latest
18:55:27 <heckj> Jan 10th is much safer
18:55:43 <heckj> (jan 10th is grizzly-2 milestone)
18:55:45 <dwchadwick> Grizzly 2 should be Ok for the first release
18:56:20 <dwchadwick> I can see a phased approach to implementation, with non-federated access initially then federated access afterwards
18:56:54 <dwchadwick> 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 <henrynash> for something like this, i say we must hit grizzly-2
18:57:45 <dwchadwick> What time is this call due to end?
18:57:46 <heckj> going to have wrap this up in 2 minutes
18:58:00 <dwchadwick> Ok, so I will go now as I have an appointment. Bye
19:00:06 <heckj> #endmeeting