Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)
Steve Martinelli steve...@ca.ibm.com wrote on 03/17/2015 12:52:33 AM: From: Steve Martinelli steve...@ca.ibm.com To: OpenStack Development Mailing List \(not for usage questions\) openstack-dev@lists.openstack.org Date: 03/17/2015 12:55 AM Subject: Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc) I like proposal 1 better, but only because I am already familiar with how plugins interact with keystoneclient. The websso work is (i think) pretty close to getting merged, and could easily be tweaked to use a token plugin (when it's ready). I think the same can be said for our k2k issue, but I'm not sure. Thanks, Steve Martinelli OpenStack Keystone Core Jamie Lennox jamielen...@redhat.com wrote on 03/15/2015 10:52:31 PM: From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 03/15/2015 10:59 PM Subject: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc) Hi All, Please note when reading this that I have no real knowledge of django so it is very possible I'm overlooking something obvious. ### Issue Django OpenStack Auth (DOA) has always been tightly coupled to the notion of a username and password. As keystone progresses and new authentication mechanisms become available to the project we need a way to extend DOA to keep up with it. However the basic processes of DOA are going to be much the same, it still needs to fetch an unscoped token, list available projects and handle rescoping and this is too much for every extension mechanism to reimplement. There is also a fairly tight coupling between how DOA populates the request and sets up a User object that we don't really want to reuse. There are a couple of authentication mechanisms that are currently being proposed that are requiring this ability immediately. * websso: https://review.openstack.org/136178 * kerberos: https://review.openstack.org/#/c/153910/ (patchset 2). and to a certain extent: * k2k: https://review.openstack.org/159910 Enabling and using these different authentication mechanisms is going to need to be configured by an admin at deployment time. Given that we want to share the basic scoping/rescoping logic between these projects I can essentially see two ways to enable this. ### Proposal 1 - Add plugins to DOA The easiest way I can see of doing this is to add a plugin model to the existing DOA structure. The initial differentiating component for all these mechanisms is the retrieval of an unscoped token. We can take the existing DOA structure and simply make that part pluggable and add interfaces to that plugin as required in the future. Review: https://review.openstack.org/#/c/153910/ Pros: * Fairly simple and extensible as required. * Small plugin interface. Cons: * Ignores that django already has an authentication plugin system. * Doesn't work well for adding views that run these backends. ### Proposal 2 - Make the existing DOA subclassable. The next method is to essentially re-use the existing Django authentication module architecture. We can extract into a base class all the current logic around token handling and develop new modules around that. Review: https://review.openstack.org/#/c/164071/ An example of using it: https://github.com/jamielennox/django-openstack-auth-kerberos Pros: * Reusing Django concepts. * Seems easier to handle adding of views. Cons: * DOA has to start worrying about public interfaces. ### Required reviews: Either way I think these two reviews are going to be required to make this work: * Redirect to login page: https://review.openstack.org/#/c/153174/ - If we want apache modules to start handling parts of auth we need to mount those at dedicated paths, we can't put kerberos login at / * Additional auth urls: https://review.openstack.org/#/c/164068/ - We need to register additional views so that we can handle the output of these apache modules and call the correct authenticate() parameters. ### Conclusion Essentially either of these could work and both will require some tweaking and extending to be useful in all situations. However I am kind of passing through on DOA and Django and would like someone with more experience in the field to comment on what feels more correct or any issues they see arising with the different approaches. Either way I think a clear approach on extensibility would be good before committing to any of the kerberos, websso and k2k definitions. Please let me know an opinion as there are multiple patches that will depend upon it. Thanks, Jamie __ OpenStack Development Mailing List (not for usage
Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)
- Original Message - From: Douglas Fish drf...@us.ibm.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Sent: Wednesday, March 18, 2015 2:07:56 AM Subject: Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc) Steve Martinelli steve...@ca.ibm.com wrote on 03/17/2015 12:52:33 AM: From: Steve Martinelli steve...@ca.ibm.com To: OpenStack Development Mailing List \(not for usage questions\) openstack-dev@lists.openstack.org Date: 03/17/2015 12:55 AM Subject: Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc) I like proposal 1 better, but only because I am already familiar with how plugins interact with keystoneclient. The websso work is (i think) pretty close to getting merged, and could easily be tweaked to use a token plugin (when it's ready). I think the same can be said for our k2k issue, but I'm not sure. Thanks, Steve Martinelli OpenStack Keystone Core Jamie Lennox jamielen...@redhat.com wrote on 03/15/2015 10:52:31 PM: From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 03/15/2015 10:59 PM Subject: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc) Hi All, Please note when reading this that I have no real knowledge of django so it is very possible I'm overlooking something obvious. ### Issue Django OpenStack Auth (DOA) has always been tightly coupled to the notion of a username and password. As keystone progresses and new authentication mechanisms become available to the project we need a way to extend DOA to keep up with it. However the basic processes of DOA are going to be much the same, it still needs to fetch an unscoped token, list available projects and handle rescoping and this is too much for every extension mechanism to reimplement. There is also a fairly tight coupling between how DOA populates the request and sets up a User object that we don't really want to reuse. There are a couple of authentication mechanisms that are currently being proposed that are requiring this ability immediately. * websso: https://review.openstack.org/136178 * kerberos: https://review.openstack.org/#/c/153910/ (patchset 2). and to a certain extent: * k2k: https://review.openstack.org/159910 Enabling and using these different authentication mechanisms is going to need to be configured by an admin at deployment time. Given that we want to share the basic scoping/rescoping logic between these projects I can essentially see two ways to enable this. ### Proposal 1 - Add plugins to DOA The easiest way I can see of doing this is to add a plugin model to the existing DOA structure. The initial differentiating component for all these mechanisms is the retrieval of an unscoped token. We can take the existing DOA structure and simply make that part pluggable and add interfaces to that plugin as required in the future. Review: https://review.openstack.org/#/c/153910/ Pros: * Fairly simple and extensible as required. * Small plugin interface. Cons: * Ignores that django already has an authentication plugin system. * Doesn't work well for adding views that run these backends. ### Proposal 2 - Make the existing DOA subclassable. The next method is to essentially re-use the existing Django authentication module architecture. We can extract into a base class all the current logic around token handling and develop new modules around that. Review: https://review.openstack.org/#/c/164071/ An example of using it: https://github.com/jamielennox/django-openstack-auth-kerberos Pros: * Reusing Django concepts. * Seems easier to handle adding of views. Cons: * DOA has to start worrying about public interfaces. ### Required reviews: Either way I think these two reviews are going to be required to make this work: * Redirect to login page: https://review.openstack.org/#/c/153174/ - If we want apache modules to start handling parts of auth we need to mount those at dedicated paths, we can't put kerberos login at / * Additional auth urls: https://review.openstack.org/#/c/164068/ - We need to register additional views so that we can handle the output of these apache modules and call the correct authenticate() parameters. ### Conclusion Essentially either of these could work and both will require some tweaking and extending to be useful in all situations. However I am kind of passing through on DOA and Django and would like someone with more experience in the field to comment on what feels more
Re: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)
I like proposal 1 better, but only because I am already familiar with how plugins interact with keystoneclient. The websso work is (i think) pretty close to getting merged, and could easily be tweaked to use a token plugin (when it's ready). I think the same can be said for our k2k issue, but I'm not sure. Thanks, Steve Martinelli OpenStack Keystone Core Jamie Lennox jamielen...@redhat.com wrote on 03/15/2015 10:52:31 PM: From: Jamie Lennox jamielen...@redhat.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Date: 03/15/2015 10:59 PM Subject: [openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc) Hi All, Please note when reading this that I have no real knowledge of django so it is very possible I'm overlooking something obvious. ### Issue Django OpenStack Auth (DOA) has always been tightly coupled to the notion of a username and password. As keystone progresses and new authentication mechanisms become available to the project we need a way to extend DOA to keep up with it. However the basic processes of DOA are going to be much the same, it still needs to fetch an unscoped token, list available projects and handle rescoping and this is too much for every extension mechanism to reimplement. There is also a fairly tight coupling between how DOA populates the request and sets up a User object that we don't really want to reuse. There are a couple of authentication mechanisms that are currently being proposed that are requiring this ability immediately. * websso: https://review.openstack.org/136178 * kerberos: https://review.openstack.org/#/c/153910/ (patchset 2). and to a certain extent: * k2k: https://review.openstack.org/159910 Enabling and using these different authentication mechanisms is going to need to be configured by an admin at deployment time. Given that we want to share the basic scoping/rescoping logic between these projects I can essentially see two ways to enable this. ### Proposal 1 - Add plugins to DOA The easiest way I can see of doing this is to add a plugin model to the existing DOA structure. The initial differentiating component for all these mechanisms is the retrieval of an unscoped token. We can take the existing DOA structure and simply make that part pluggable and add interfaces to that plugin as required in the future. Review: https://review.openstack.org/#/c/153910/ Pros: * Fairly simple and extensible as required. * Small plugin interface. Cons: * Ignores that django already has an authentication plugin system. * Doesn't work well for adding views that run these backends. ### Proposal 2 - Make the existing DOA subclassable. The next method is to essentially re-use the existing Django authentication module architecture. We can extract into a base class all the current logic around token handling and develop new modules around that. Review: https://review.openstack.org/#/c/164071/ An example of using it: https://github.com/jamielennox/django-openstack-auth-kerberos Pros: * Reusing Django concepts. * Seems easier to handle adding of views. Cons: * DOA has to start worrying about public interfaces. ### Required reviews: Either way I think these two reviews are going to be required to make this work: * Redirect to login page: https://review.openstack.org/#/c/153174/ - If we want apache modules to start handling parts of auth we need to mount those at dedicated paths, we can't put kerberos login at / * Additional auth urls: https://review.openstack.org/#/c/164068/ - We need to register additional views so that we can handle the output of these apache modules and call the correct authenticate() parameters. ### Conclusion Essentially either of these could work and both will require some tweaking and extending to be useful in all situations. However I am kind of passing through on DOA and Django and would like someone with more experience in the field to comment on what feels more correct or any issues they see arising with the different approaches. Either way I think a clear approach on extensibility would be good before committing to any of the kerberos, websso and k2k definitions. Please let me know an opinion as there are multiple patches that will depend upon it. Thanks, Jamie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon][DOA] Extending OpenStack Auth for new mechanisms (websso, kerberos, k2k etc)
Hi All, Please note when reading this that I have no real knowledge of django so it is very possible I'm overlooking something obvious. ### Issue Django OpenStack Auth (DOA) has always been tightly coupled to the notion of a username and password. As keystone progresses and new authentication mechanisms become available to the project we need a way to extend DOA to keep up with it. However the basic processes of DOA are going to be much the same, it still needs to fetch an unscoped token, list available projects and handle rescoping and this is too much for every extension mechanism to reimplement. There is also a fairly tight coupling between how DOA populates the request and sets up a User object that we don't really want to reuse. There are a couple of authentication mechanisms that are currently being proposed that are requiring this ability immediately. * websso: https://review.openstack.org/136178 * kerberos: https://review.openstack.org/#/c/153910/ (patchset 2). and to a certain extent: * k2k: https://review.openstack.org/159910 Enabling and using these different authentication mechanisms is going to need to be configured by an admin at deployment time. Given that we want to share the basic scoping/rescoping logic between these projects I can essentially see two ways to enable this. ### Proposal 1 - Add plugins to DOA The easiest way I can see of doing this is to add a plugin model to the existing DOA structure. The initial differentiating component for all these mechanisms is the retrieval of an unscoped token. We can take the existing DOA structure and simply make that part pluggable and add interfaces to that plugin as required in the future. Review: https://review.openstack.org/#/c/153910/ Pros: * Fairly simple and extensible as required. * Small plugin interface. Cons: * Ignores that django already has an authentication plugin system. * Doesn't work well for adding views that run these backends. ### Proposal 2 - Make the existing DOA subclassable. The next method is to essentially re-use the existing Django authentication module architecture. We can extract into a base class all the current logic around token handling and develop new modules around that. Review: https://review.openstack.org/#/c/164071/ An example of using it: https://github.com/jamielennox/django-openstack-auth-kerberos Pros: * Reusing Django concepts. * Seems easier to handle adding of views. Cons: * DOA has to start worrying about public interfaces. ### Required reviews: Either way I think these two reviews are going to be required to make this work: * Redirect to login page: https://review.openstack.org/#/c/153174/ - If we want apache modules to start handling parts of auth we need to mount those at dedicated paths, we can't put kerberos login at / * Additional auth urls: https://review.openstack.org/#/c/164068/ - We need to register additional views so that we can handle the output of these apache modules and call the correct authenticate() parameters. ### Conclusion Essentially either of these could work and both will require some tweaking and extending to be useful in all situations. However I am kind of passing through on DOA and Django and would like someone with more experience in the field to comment on what feels more correct or any issues they see arising with the different approaches. Either way I think a clear approach on extensibility would be good before committing to any of the kerberos, websso and k2k definitions. Please let me know an opinion as there are multiple patches that will depend upon it. Thanks, Jamie __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
