Authorization: The main purpose of authorization (permissions) is to control access to resources based on defined permission records, once the autherntication system has determined the identity of the current user. The basic infrastructure and enforcement is already in place. What we're doing here is to make sure we're enforcing existing permissions consistently, providing a UI for admins to manipulat permission grants, and expanding the scope of the permissions system to deal with resources stored externally to the main conductor database.
The basic components of permissions that we need are as follows. Some initial indication of what we think is in scope for this iteration is included, but this is only an initial estimate.
In scope for 0.4.0 1) Always check/filter/etc for permissions: a) raise exceptions/show proper error pages on permission denied (a good bit is done) b) hide elements/links/actions based on permission (user shouldn't be presented with any option that he's not allowed to perform) c) filter lists properly based on permission (some is done already) 2) Permission setting UI a) UI design for single object grants/deletes b) Implementation for single object grants/deletes c) UI design for bulk operations (maybe out of scope) d) Implementation for bulk operations (maybe out of scope) 3) Permissions on IWHD objects Maybe in scope for 0.4.0 4) Permissions on user groups Probably not in scope for 0.4.0 5) Permission filtering of search results (if search is in scope, this must be too) 6) Additional permissions for external objects a) permissions on templates b) permissions on assemblies/deployables
User stories and tasks:
1) a) As a user, I should see an appropriate error page if I attempt to access a resource to which I do not have the appropriate level of access 1) Make sure permission checks are being applied to every page 2) Make sure error pages are being styled properly
b) As a user, I should not see action links for actions that I do not have permission on (i.e. if I have 'view' permission on a provider I shouldn't see an 'edit' link, if I have 'view' permission on a deployment, I shouln't see a 'stop' action) 1) make sure links, actions, and any "privileged" content section are included conditionally (by privilege level) in views (already done in some cases)
c) As a user, I should not see entries in a list of resources that I do not have access to view by other means (i.e. the pool 'instance list' should only include instances that I have 'view' permissions on, etc.) 1) Make sure we use 'list_for_user' where appropriate for any list output. 2) We may need an association-specific list_for_user, or we could re-style association queries to use existing list_for_user (i.e. instead of pool.instances, we have Instance.list_for_user(...) where the user and pool are specified.
2) a) As a Developer, I should be able to see the web UI design for single-object permission operations 1) UI design for permissions tab: * reusable across all permissioned-object types (pool, instance, provider, etc) * Shows table of existing permission grants: - user - role - whether direct or indirect -- if indirect, which object is the explicit grant on: - a direct permission is a permission defined on this resource -- i.e. the instance owner has the 'owner' role on this instance - for some object types, there's a defined hierarchy of permission grant inheritence. For example, 'view instance' permission defined on a pool lets a user view all instances in that pool - Any permission defined on BasePermissionObject is considered a site-wide permision grant and will be applicable to any object of the same type as that of the BasePermissionObject role * Actions allowed on the table of permissions (delete/change role) * "Grant additional access" action which will allow the user/admin to choose a new user and a role on which to grant permissions on this resource b) As an admin, I should be able to use the Web UI to grant and revoke access to a resource. 1) Design permission setting UI (single user/resource) 2) Implement views and controller actions for permission setting UI (single user/resource) 3) Make sure API calls are sane here too (single user/resource) 4) Repeat 1)-3) for bulk operations c) As a Developer, I should be able to see the web UI design for bulk permission operations (no tasks broken out here) d) As an admin, I should be able to use the Web UI to grant and revoke access to multiple resources at once (no tasks broken out here).
3) As a user, I should be able to see that permissions checking, filtering, etc. is being applied to Images, Builds, and Provider Images 1) Design interaction w/ IWHD api for permissions 2) Refactor PermissionedObject into a hierarchy: PermissionedObject is the base class with anything common to both AR and ActiveResource models PermissionedActiveRecordObject includes AR-specific components (from today's model) PermissionedActiveResourceObject contains the parts needed to deal with the IWHD models (at a general level) 3) Augment IWHD models to include PermissionedActiveResourceObject and implement any required methods 4) Refactor Permission model to work with ActiveResource models 5) Define appropriate privileges and roles for the new models
4) As an admin, I should be able to grant a user group access to a pool (or other resource) without identifying individual users. 1) Implement UserGroup model (figure out any integration w/ external data source) 2) Work out caching group membership from external source (cache on schedule, by trigger, or re-query a user's group memberships before performing a permission query for this user (or something else entirely). We need it cached locally since the permission filtering queries wil need to include group and membership in the join for filtering results. 3) Alter Permission model to use a polymorphic association instead of User (Grantee which can be either a User or a UserGroup, or something similar) 4) Alter permission checks, filters, etc. to take groups into account 5) Alter permissions setting UI to allow group selection in addition to user selection.
5) As a user, I should not see entries in search results that I do not have access to view by other means (i.e. by clicking on the appropriate pool/instance/etc pages) 1) Figure out appropriate place to insert permission filtering in search results and implement it (more detail needed)
6) a) As a user, I should be able to see that permissions checking, filtering, etc. is being applied to Templates 1) determine how templates will be stored (assuming an ActiveResource model pointing to katello-managed templates for now) 2) Augment Template ActiveResource model to implement any required PermissionedActiveResourceObject methods 3) Define appropriate privileges and roles for the template model
b) As a user, I should be able to see that permissions checking, filtering, etc. is being applied to Assemblies and Deployables 1) determine how templates will be stored -- impl will be dependent on this answer.
The main external prerequisites are as follows: For IWHD permissions, IWHD must have in place a permissions system and API that is, at least at a conceptual level, consistent with our underlying permisions model.
For user group permissions, we need to have identified our plan for external auth and how we're interacting with the underlying user groups functionality.
Once we're considering dealing with permissions on objects stored in katello, we'll need to deal with the same questions as above for IWHD.
Hi Scott,
On Wed, 2011-07-27 at 01:42 -0400, Scott Seago wrote:
Authorization: The main purpose of authorization (permissions) is to control access to resources based on defined permission records, once the autherntication system has determined the identity of the current user. The basic infrastructure and enforcement is already in place. What we're doing here is to make sure we're enforcing existing permissions consistently, providing a UI for admins to manipulat permission grants, and expanding the scope of the permissions system to deal with resources stored externally to the main conductor database.
Wow, this is great - seriously thorough
I'd like to see more focus on what makes this interesting for users. Like I suggested to Matt, a script for a screencast demo of this stuff really helps make sure we're focusing on the right things.
e.g.
- Andy Admin adds a new Joe Schmoe user and gives Joe "User" permissions
- Joe logs in, can select an image from a list and launch it
- Joe sees his instance but nobody else's instances
- Joe doesn't see any of the admin UI, nor any UI for adding pools etc.
- Joe logs into his instance
- Joe shuts down his instance
If we make that demo our first target, there's a lot of things we can punt on for now:
- It's fine if Joe has launch access to all images; we just need to make sure that Joe can't delete or overwrite images. Perhaps this means that Joe has no direct access to IWHD or Image Factory at all, only the images list in Conductor
- Andy doesn't need to make fine-grained changes to Joe's permissions, he just assigned Joe a coarse-grained role
- We don't need to worry so much about hiding certain actions on the admin pages. Joe just never sees those pages
- Hiding things Joe doesn't have permission to is more important than slick error messages if he does try and access other things
- Bulk operations can be omitted
- Groups can be omitted
By framing things this way, I'd be optimistic we could reduce the dependency on the IWHD work and focus the Conductor work on something achievable for a release in 3 weeks, rather than 3 months
Obviously, everything else you describe does need to be done eventually. It'd just be nice if we could greatly reduce the scope of the first iteration of this.
Cheers, Mark.
On 07/27/2011 05:30 AM, Mark McLoughlin wrote:
- It's fine if Joe has launch access to all images; we just need to make sure that Joe can't delete or overwrite images. Perhaps this means that Joe has no direct access to IWHD or Image Factory at all, only the images list in Conductor
That would be perfect but what prevents him to use IWHD CLI and access the objects directly? I was talking about this issue from the very beginning. If the plan is that only a subset of the users will be allowed to use IWHD and all the rest will have to interact with Conductor this is fine but I never seen this spelled out.
The deneral assumtion I have is that all the components are hooked into the same identity namespace (read domain or group of domains provided by LDAP, AD, IPA or mixture of those). If there is no specific restriction and grouping any user would be able to present a valid authentication when it accesses any component so it is the responsibility of every component to decide what the user is allowed to do.
On Wed, Jul 27, 2011 at 09:31:44AM -0400, Dmitri Pal wrote:
On 07/27/2011 05:30 AM, Mark McLoughlin wrote:
- It's fine if Joe has launch access to all images; we just need to make sure that Joe can't delete or overwrite images. Perhaps this means that Joe has no direct access to IWHD or Image Factory at all, only the images list in Conductor
That would be perfect but what prevents him to use IWHD CLI and access the objects directly? I was talking about this issue from the very beginning. If the plan is that only a subset of the users will be allowed to use IWHD and all the rest will have to interact with Conductor this is fine but I never seen this spelled out.
It seems to me that we could probably save the IWHD guys a lot of work if we lock down IWHD so that you can only access it if you have valid credentials in either Conductor or Katello. This is a change from what we had discussed, but if we can say that we can trust a Conductor admin to bless the images that can be launched in a given place, and that that's the only place Joe gets to see images, then that ought to be enough, at least until someone tells us something different?
--Hugh
The deneral assumtion I have is that all the components are hooked into the same identity namespace (read domain or group of domains provided by LDAP, AD, IPA or mixture of those). If there is no specific restriction and grouping any user would be able to present a valid authentication when it accesses any component so it is the responsibility of every component to decide what the user is allowed to do.
-- Thank you, Dmitri Pal
Sr. Engineering Manager IPA project, Red Hat Inc.
Looking to carve out IT costs? www.redhat.com/carveoutcosts/
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
From: "Hugh Brock" hbrock@redhat.com Date: Wed, 27 Jul 2011 16:40:50 -0400
On Wed, Jul 27, 2011 at 09:31:44AM -0400, Dmitri Pal wrote:
On 07/27/2011 05:30 AM, Mark McLoughlin wrote:
- It's fine if Joe has launch access to all images; we just need to make sure that Joe can't delete or overwrite images. Perhaps this means that Joe has no direct access to IWHD or Image Factory at all, only the images list in Conductor
That would be perfect but what prevents him to use IWHD CLI and access the objects directly? I was talking about this issue from the very beginning. If the plan is that only a subset of the users will be allowed to use IWHD and all the rest will have to interact with Conductor this is fine but I never seen this spelled out.
It seems to me that we could probably save the IWHD guys a lot of work if we lock down IWHD so that you can only access it if you have valid credentials in either Conductor or Katello.
I agree that it will save the iwhd team some work if we can settle on this architecture. In what timeframe can we get ACKs from the affected teams (katello and conductor, to my knowledge) that this is in fact the architecture that we'll go with? Or not. Hugh? Brian?
We'll need to make sure factory can also access it; I'll work with the factory team to run that issue to ground.
On 07/27/2011 05:30 AM, Mark McLoughlin wrote:
Hi Scott,
On Wed, 2011-07-27 at 01:42 -0400, Scott Seago wrote:
Authorization: The main purpose of authorization (permissions) is to control access to resources based on defined permission records, once the autherntication system has determined the identity of the current user. The basic infrastructure and enforcement is already in place. What we're doing here is to make sure we're enforcing existing permissions consistently, providing a UI for admins to manipulat permission grants, and expanding the scope of the permissions system to deal with resources stored externally to the main conductor database.
Wow, this is great - seriously thorough
I'd like to see more focus on what makes this interesting for users. Like I suggested to Matt, a script for a screencast demo of this stuff really helps make sure we're focusing on the right things.
e.g.
Andy Admin adds a new Joe Schmoe user and gives Joe "User" permissions
Joe logs in, can select an image from a list and launch it
Joe sees his instance but nobody else's instances
Joe doesn't see any of the admin UI, nor any UI for adding pools etc.
Joe logs into his instance
Joe shuts down his instance
If we make that demo our first target, there's a lot of things we can punt on for now:
- It's fine if Joe has launch access to all images; we just need to make sure that Joe can't delete or overwrite images. Perhaps this means that Joe has no direct access to IWHD or Image Factory at all, only the images list in Conductor
So there's probably 2 phases here in terms of IWHD issues: 1) where we are now -- IWHD isn't yet performing permission checks 2) IWHD fully enforces permissions and provides a permissions API
So for 1) -- the deleting/overwriting images bit isn't a problem right now, since aeolus-image only lets you build (or at least push) an image if you have write access to the providers. I'm less clear on deletion, but we could enforce similar restrictions there. As IWHD doesn't yet support permissions, any user can launch any image in IWHD by adding it to the deployable (or choosing it in the "single instance" UI that creates the deployable on the fly)
Once 2) occurs, then we have 2 choices: a) keep ignoring iwhd permissions in conductor and report errors when users attempt to do things they're not allowed to do (i.e. wait for IWHD to enforce) -- users will have to use IWHD apis to get/set permissions b) integrate permissions into the IWHD ActiveResource models, and then we get full control/view into IWHD permissions from conductor
- Andy doesn't need to make fine-grained changes to Joe's permissions, he just assigned Joe a coarse-grained role
Remember that the permissions that we're already enforcing in 0.3.0 are relatively fine-grained (user creates an instance and has permissions for this instance -- other non-admin users can't see them, etc.)
Also note, that in all cases, permission records are tied to specific objects/resources. i.e. there's no such thing as granting a role to someone in the abstract -- a user has a role on an object (i.e. on a resource, in a particular context). So a user might belong to an Admin role on one pool (i.e. can see anyone's instances there), a User role in another (i.e. can create instances there and manage those instances, once created, but no access to anyone else's instances in the pool) and no role at all in a third. For example, Hugh might be an admin on "aeolus dev pool", a user in "qe pool" and no role at all in the "web production" pool.
We do support the other extreme (course-grained as in 'all or nothing' permissions) by defining roles on the base permission object -- this is what we do for the top-level admin -- we have an "Administrator" role that defines all possible privileges and we assign this user to admin on the "site-wide" permission object. End users might get more limited site-wide roles ("image user" can launch any image, etc).
- We don't need to worry so much about hiding certain actions on the admin pages. Joe just never sees those pages
I think what you're saying is that we don't need to hide actions on the page if the people from whome those should be hidden can't get there in the first place. Yes, the page-level access is first -- every action has a minimum permission level required (either on the object being manipulated -- i.e. provider view for a provider will throw an error for users who aren't allowed to see that provider) or a site-wide level required, if the page isn't scoped to a particular resource.
The action-level hiding is for a page where there are things mixed on the same page with a different required permission level -- i.e. the 'provider view' page will only allow users to see this if they have view permission on the provider, but if they don't have modify permission, they shouldn't see the edit link. Granted, in the current 'no permission UI' state, we don't have any users with permission to see providers but not edit them (since we only have "site wide admin" and "non-admin users"). This will change once we have a permissions UI -- then it will be more important to hide 'edit' links for users that aren't allowed to edit. Also this is a lower-impact issue than the page-level checks -- what will happen if we forget this is a "view providers only" user will click "edit provider" and be promptly greeted with an error page since the edit forms _already_ have the proper checks in place.
- Hiding things Joe doesn't have permission to is more important than slick error messages if he does try and access other things
Agreed -- as long as the basic "throw exeption if user has no permission on this page" is in place, making that exception look pretty can be a lower priority. Also, much of the page-level checks are done anyway -- mostly we need to go through and make sure it's done consistently. One area we don't have this as much is on the admin side, so we definitely need to make sure that the require_privilege() call is included on each action.
- Bulk operations can be omitted
Agreed (and already identified as 'maybe out of scope')
- Groups can be omitted
Agreed (and already identified as 'maybe out of scope')
By framing things this way, I'd be optimistic we could reduce the dependency on the IWHD work and focus the Conductor work on something achievable for a release in 3 weeks, rather than 3 months
Sure -- that's why I had IWHD permissions near the end. In fact there's no dep whatsoever on IWHD for the permissions UI (perhaps the biggest task on this list) I'm not sure how many 3 week sprints we'll have in iteration 4, but it's certainly more than one 3 week sprint. We won't even begin the impl of the permissions UI until the UI design is completed in an earlier sprint.
Obviously, everything else you describe does need to be done eventually. It'd just be nice if we could greatly reduce the scope of the first iteration of this.
Cheers, Mark.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On 07/27/2011 01:11 PM, Scott Seago wrote:
Also note, that in all cases, permission records are tied to specific objects/resources. i.e. there's no such thing as granting a role to someone in the abstract -- a user has a role on an object (i.e. on a resource, in a particular context). So a user might belong to an Admin role on one pool (i.e. can see anyone's instances there), a User role in another (i.e. can create instances there and manage those instances, once created, but no access to anyone else's instances in the pool) and no role at all in a third. For example, Hugh might be an admin on "aeolus dev pool", a user in "qe pool" and no role at all in the "web production" pool.
This is great! Now the question is: "Can Hugh access IWHD via its CLI and if he can then how IWHD makes sure that Hugh does not mess with the images that are/will be deployed into "web production" pool. If he can access the image and change it then we got a big problem.
On 07/27/2011 01:42 AM, Scott Seago wrote:
The main external prerequisites are as follows: For IWHD permissions, IWHD must have in place a permissions system and API that is, at least at a conceptual level, consistent with our underlying permisions model.
For user group permissions, we need to have identified our plan for external auth and how we're interacting with the underlying user groups functionality.
As for external auth for now you should consider one LDAP identity source (DS, AD, IPA etc.) However in future (in 6 months or so) there will be an interface that will abstract multiple identity sources. This is especially important when you have multiple sources of identities for example internal served from an LDAP server or IPA and external served from company's AD. This interface will provide authentication capabilities and user and group lookup.
Once we're considering dealing with permissions on objects stored in katello, we'll need to deal with the same questions as above for IWHD.
FWIW... Katello has a running version of this already using carls "tag" model. Should be easy to either copy/paste or we could try and turn into a gem.
-- bk
On 07/27/2011 01:42 AM, Scott Seago wrote:
Authorization: The main purpose of authorization (permissions) is to control access to resources based on defined permission records, once the autherntication system has determined the identity of the current user. The basic infrastructure and enforcement is already in place. What we're doing here is to make sure we're enforcing existing permissions consistently, providing a UI for admins to manipulat permission grants, and expanding the scope of the permissions system to deal with resources stored externally to the main conductor database.
The basic components of permissions that we need are as follows. Some initial indication of what we think is in scope for this iteration is included, but this is only an initial estimate. In scope for 0.4.0 1) Always check/filter/etc for permissions: a) raise exceptions/show proper error pages on permission denied (a good bit is done) b) hide elements/links/actions based on permission (user shouldn't be presented with any option that he's not allowed to perform) c) filter lists properly based on permission (some is done already) 2) Permission setting UI a) UI design for single object grants/deletes b) Implementation for single object grants/deletes c) UI design for bulk operations (maybe out of scope) d) Implementation for bulk operations (maybe out of scope) 3) Permissions on IWHD objects Maybe in scope for 0.4.0 4) Permissions on user groups Probably not in scope for 0.4.0 5) Permission filtering of search results (if search is in scope, this must be too) 6) Additional permissions for external objects a) permissions on templates b) permissions on assemblies/deployables
User stories and tasks:
1) a) As a user, I should see an appropriate error page if I attempt to access a resource to which I do not have the appropriate level of access 1) Make sure permission checks are being applied to every page 2) Make sure error pages are being styled properly b) As a user, I should not see action links for actions that I do not have permission on (i.e. if I have 'view' permission on a provider I shouldn't see an 'edit' link, if I have 'view' permission on a deployment, I shouln't see a 'stop' action) 1) make sure links, actions, and any "privileged" content section are included conditionally (by privilege level) in views (already done in some cases) c) As a user, I should not see entries in a list of resources that I do not have access to view by other means (i.e. the pool 'instance list' should only include instances that I have 'view' permissions on, etc.) 1) Make sure we use 'list_for_user' where appropriate for any list output. 2) We may need an association-specific list_for_user, or we could re-style association queries to use existing list_for_user (i.e. instead of pool.instances, we have Instance.list_for_user(...) where the user and pool are specified. 2) a) As a Developer, I should be able to see the web UI design for single-object permission operations 1) UI design for permissions tab: * reusable across all permissioned-object types (pool, instance, provider, etc) * Shows table of existing permission grants: - user - role - whether direct or indirect -- if indirect, which object is the explicit grant on: - a direct permission is a permission defined on this resource -- i.e. the instance owner has the 'owner' role on this instance - for some object types, there's a defined hierarchy of permission grant inheritence. For example, 'view instance' permission defined on a pool lets a user view all instances in that pool - Any permission defined on BasePermissionObject is considered a site-wide permision grant and will be applicable to any object of the same type as that of the BasePermissionObject role * Actions allowed on the table of permissions (delete/change role) * "Grant additional access" action which will allow the user/admin to choose a new user and a role on which to grant permissions on this resource b) As an admin, I should be able to use the Web UI to grant and revoke access to a resource. 1) Design permission setting UI (single user/resource) 2) Implement views and controller actions for permission setting UI (single user/resource) 3) Make sure API calls are sane here too (single user/resource) 4) Repeat 1)-3) for bulk operations c) As a Developer, I should be able to see the web UI design for bulk permission operations (no tasks broken out here) d) As an admin, I should be able to use the Web UI to grant and revoke access to multiple resources at once (no tasks broken out here). 3) As a user, I should be able to see that permissions checking, filtering, etc. is being applied to Images, Builds, and Provider Images 1) Design interaction w/ IWHD api for permissions 2) Refactor PermissionedObject into a hierarchy: PermissionedObject is the base class with anything common to both AR and ActiveResource models PermissionedActiveRecordObject includes AR-specific components (from today's model) PermissionedActiveResourceObject contains the parts needed to deal with the IWHD models (at a general level) 3) Augment IWHD models to include PermissionedActiveResourceObject and implement any required methods 4) Refactor Permission model to work with ActiveResource models 5) Define appropriate privileges and roles for the new models 4) As an admin, I should be able to grant a user group access to a pool (or other resource) without identifying individual users. 1) Implement UserGroup model (figure out any integration w/ external data source) 2) Work out caching group membership from external source (cache on schedule, by trigger, or re-query a user's group memberships before performing a permission query for this user (or something else entirely). We need it cached locally since the permission filtering queries wil need to include group and membership in the join for filtering results. 3) Alter Permission model to use a polymorphic association instead of User (Grantee which can be either a User or a UserGroup, or something similar) 4) Alter permission checks, filters, etc. to take groups into account 5) Alter permissions setting UI to allow group selection in addition to user selection. 5) As a user, I should not see entries in search results that I do not have access to view by other means (i.e. by clicking on the appropriate pool/instance/etc pages) 1) Figure out appropriate place to insert permission filtering in search results and implement it (more detail needed) 6) a) As a user, I should be able to see that permissions checking, filtering, etc. is being applied to Templates 1) determine how templates will be stored (assuming an ActiveResource model pointing to katello-managed templates for now) 2) Augment Template ActiveResource model to implement any required PermissionedActiveResourceObject methods 3) Define appropriate privileges and roles for the template model b) As a user, I should be able to see that permissions checking, filtering, etc. is being applied to Assemblies and Deployables 1) determine how templates will be stored -- impl will be dependent on this answer.
The main external prerequisites are as follows: For IWHD permissions, IWHD must have in place a permissions system and API that is, at least at a conceptual level, consistent with our underlying permisions model.
For user group permissions, we need to have identified our plan for external auth and how we're interacting with the underlying user groups functionality. Once we're considering dealing with permissions on objects stored in katello, we'll need to deal with the same questions as above for IWHD.
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On Wed, 27 Jul 2011 01:42:49 -0400 Scott Seago sseago@redhat.com wrote:
3) Augment IWHD models to include PermissionedActiveResourceObject and implement any required methods
For IWHD permissions, IWHD must have in place a permissions system and API that is, at least at a conceptual level, consistent with our underlying permisions model.
Where can I find the specification for the "underlying permissions model"?
At this point, I rolled out an IWHD Authorization API design, based largely on what John transmitted verbally from various design meetings. When Dmitry saw my spec, he sent me a document that defined a "context" in such a way that is impossible to implement securely. This has to be resolved before I set out to implement Auth/Auth in IWHD. E.g. declare "context" void and rejected, or plan to modify Kerberos to have identities that span realms and write a GSSAPI library that permits it, or other.
-- Pete
On 07/27/2011 05:32 PM, Pete Zaitcev wrote:
On Wed, 27 Jul 2011 01:42:49 -0400 Scott Seago sseago@redhat.com wrote:
3) Augment IWHD models to include PermissionedActiveResourceObject and implement any required methods For IWHD permissions, IWHD must have in place a permissions system and API that is, at least at a conceptual level, consistent with our underlying permisions model.
Where can I find the specification for the "underlying permissions model"?
At this point, I rolled out an IWHD Authorization API design, based largely on what John transmitted verbally from various design meetings. When Dmitry saw my spec, he sent me a document that defined a "context" in such a way that is impossible to implement securely.
The context are essential IMO. You can't just discard it. Contexts/enviroments are a part of the real use cases (see Scott's original writeup) As I mentioned in the last section of the document (attached for reference) there is an option to make Conductor a front end to IWHD and not let direct user access to it. In this case IWHD should be counted as an internal component of the conductor IMO. The connection between the Conductor and IWHD can be based on server-to-server trust (SSL, GSSAPI, OAth - does not matter) This way the permissions would be stored as properties (tags) of the objects in the IWHD but controlled by the Conductor as it knows about environments and contexts. I was proposing it all along.
The alternative (if we insist to preserve the direct CLI to IWHD) is for IWHD to call back to Conductor on any operation to see if the user is allowed to perform an operation against the image that is currently tagged for a specific environment. Yes user would then provide the environment as a parameter but conductor would say if the user can do something or not via that call back.
John. We need to talk 2F2 about it. I am in the office on Tuesday. Would this work for you?
This has to be resolved before I set out to implement Auth/Auth in IWHD. E.g. declare "context" void and rejected, or plan to modify Kerberos to have identities that span realms and write a GSSAPI library that permits it, or other.
-- Pete _______________________________________________ aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
On 07/28/2011 04:58 PM, Dmitri Pal wrote:
On 07/27/2011 05:32 PM, Pete Zaitcev wrote:
On Wed, 27 Jul 2011 01:42:49 -0400 Scott Seagosseago@redhat.com wrote:
3) Augment IWHD models to include PermissionedActiveResourceObject and implement any required methods For IWHD permissions, IWHD must have in place a permissions system and API that is, at least at a conceptual level, consistent with our underlying permisions model.
Where can I find the specification for the "underlying permissions model"?
At this point, I rolled out an IWHD Authorization API design, based largely on what John transmitted verbally from various design meetings. When Dmitry saw my spec, he sent me a document that defined a "context" in such a way that is impossible to implement securely.
The context are essential IMO. You can't just discard it. Contexts/enviroments are a part of the real use cases (see Scott's original writeup) As I mentioned in the last section of the document (attached for reference) there is an option to make Conductor a front end to IWHD and not let direct user access to it. In this case IWHD should be counted as an internal component of the conductor IMO. The connection between the Conductor and IWHD can be based on server-to-server trust (SSL, GSSAPI, OAth - does not matter) This way the permissions would be stored as properties (tags) of the objects in the IWHD but controlled by the Conductor as it knows about environments and contexts. I was proposing it all along.
The alternative (if we insist to preserve the direct CLI to IWHD) is for IWHD to call back to Conductor on any operation to see if the user is allowed to perform an operation against the image that is currently tagged for a specific environment. Yes user would then provide the environment as a parameter but conductor would say if the user can do something or not via that call back.
John. We need to talk 2F2 about it. I am in the office on Tuesday. Would this work for you?
At the same time, the environment/context is not a part of the current conductor permissions model, as for the resources that we're currently managing, the combination of (user, resource, set of allowable actions) is sufficient. In areas where environment itself makes a difference in terms of of what actions are allowable, in some cases this means that the environment itself _is_ the resource/object that we're setting permissions on. In other cases, the effect of environment is not one of permissions but one of metadata/object associations.
For example, the 'dev' environment has a pool called "Aeolus development" and this environment is mapped to ec2 but not RHEV. That a user cannot launch an instance from Aeolus Development and deploy in RHEV isn't a permissions restriction, it's a data mapping restriction. It's not that the user doesn't have permission to launch dev instances in RHEV, it's that RHEV isn't mapped to dev at all -- even the site-wide admin can't launch an Aeolus development instance in RHEV, since it's not an allowable match. That the admin can't do it either indicates that it's not a permissions-driven restriction but based on something else.
I still haven't understood how images are so much different that they can't be handled with the same (user/resource/role) model as everyone else. I know we've had a long discussion thread in the past on this very subject, but from what I recall, it was inconclusive.
At the very least, I'd suggest that if IWHD permissions are going to be managed or enforced in any way by conductor directly (rather than simply passing requests along and letting IWHD handle it all, leaving conductor ignorant of how IWHD permissions work internally) we'd better keep the models consistent -- and only if we can reach a consensus on both the IWHD and Conductor sides to change our permissions model to add this fourth dimension should we do so here.
If IWHD is managing its own permissions and not relying on conductor to set or manage them, then I guess Conductor has less reason to worry about consistency here.
Scott
This has to be resolved before I set out to implement Auth/Auth in IWHD. E.g. declare "context" void and rejected, or plan to modify Kerberos to have identities that span realms and write a GSSAPI library that permits it, or other.
-- Pete
On 07/28/2011 05:53 PM, Scott Seago wrote:
On 07/28/2011 04:58 PM, Dmitri Pal wrote:
On 07/27/2011 05:32 PM, Pete Zaitcev wrote:
On Wed, 27 Jul 2011 01:42:49 -0400 Scott Seagosseago@redhat.com wrote:
3) Augment IWHD models to include PermissionedActiveResourceObject and implement any required methods For IWHD permissions, IWHD must have in place a permissions system and API that is, at least at a conceptual level, consistent with our underlying permisions model.
Where can I find the specification for the "underlying permissions model"?
At this point, I rolled out an IWHD Authorization API design, based largely on what John transmitted verbally from various design meetings. When Dmitry saw my spec, he sent me a document that defined a "context" in such a way that is impossible to implement securely.
The context are essential IMO. You can't just discard it. Contexts/enviroments are a part of the real use cases (see Scott's original writeup) As I mentioned in the last section of the document (attached for reference) there is an option to make Conductor a front end to IWHD and not let direct user access to it. In this case IWHD should be counted as an internal component of the conductor IMO. The connection between the Conductor and IWHD can be based on server-to-server trust (SSL, GSSAPI, OAth - does not matter) This way the permissions would be stored as properties (tags) of the objects in the IWHD but controlled by the Conductor as it knows about environments and contexts. I was proposing it all along.
The alternative (if we insist to preserve the direct CLI to IWHD) is for IWHD to call back to Conductor on any operation to see if the user is allowed to perform an operation against the image that is currently tagged for a specific environment. Yes user would then provide the environment as a parameter but conductor would say if the user can do something or not via that call back.
John. We need to talk 2F2 about it. I am in the office on Tuesday. Would this work for you?
At the same time, the environment/context is not a part of the current conductor permissions model, as for the resources that we're currently managing, the combination of (user, resource, set of allowable actions) is sufficient. In areas where environment itself makes a difference in terms of of what actions are allowable, in some cases this means that the environment itself _is_ the resource/object that we're setting permissions on. In other cases, the effect of environment is not one of permissions but one of metadata/object associations.
For example, the 'dev' environment has a pool called "Aeolus development" and this environment is mapped to ec2 but not RHEV. That a user cannot launch an instance from Aeolus Development and deploy in RHEV isn't a permissions restriction, it's a data mapping restriction. It's not that the user doesn't have permission to launch dev instances in RHEV, it's that RHEV isn't mapped to dev at all -- even the site-wide admin can't launch an Aeolus development instance in RHEV, since it's not an allowable match. That the admin can't do it either indicates that it's not a permissions-driven restriction but based on something else.
This makes sense but it is not a use case I am worried about. Let us assume that all of the dev/test/stage/prod are mapped to the same provider say EC2 or RHEV-M. Permissions model should handle this case. In addition to permissions there will be other restrictions that you mention that would be absolutely logical for a user performing an operation as it would fall into the pattern of putting a square figure into a round hole.
I still haven't understood how images are so much different that they can't be handled with the same (user/resource/role) model as everyone else. I know we've had a long discussion thread in the past on this very subject, but from what I recall, it was inconclusive.
I thought we managed to establish the problem: if the image does not have a clue in which environment it will be used someone who is not supposed to touch it can have access to it and not knowingly cause damage.
At the very least, I'd suggest that if IWHD permissions are going to be managed or enforced in any way by conductor directly (rather than simply passing requests along and letting IWHD handle it all, leaving conductor ignorant of how IWHD permissions work internally) we'd better keep the models consistent -- and only if we can reach a consensus on both the IWHD and Conductor sides to change our permissions model to add this fourth dimension should we do so here.
We need a decision. The point is that you can't have the right permissions model completely decoupling Conductor from IWHD. If they are coupled then one needs to front end another or IWDH needs to call back to Conductor. May be I am missing something but I do not see any other way.
If IWHD is managing its own permissions and not relying on conductor to set or manage them, then I guess Conductor has less reason to worry about consistency here.
Yes but the whole solution is broken if they are decoupled. I am not going to repeat the explanation. I did it several times on different lists.
Scott
This has to be resolved before I set out to implement Auth/Auth in IWHD. E.g. declare "context" void and rejected, or plan to modify Kerberos to have identities that span realms and write a GSSAPI library that permits it, or other.
-- Pete
aeolus-devel mailing list aeolus-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/aeolus-devel
aeolus-devel@lists.fedorahosted.org