Re: [openstack-dev] [keystone] SAML consumption Blueprints
Hi Dolph, On 21 Feb 2014, at 03:05, Dolph Mathews dolph.math...@gmail.com wrote: On Thu, Feb 20, 2014 at 4:18 AM, Marco Fargetta marco.farge...@ct.infn.it wrote: Dear all, I am interested to the integration of SAML with keystone and I am analysing the following blueprint and its implementation: https://blueprints.launchpad.net/keystone/+spec/saml-id https://review.openstack.org/#/c/71353/ Looking at the code there is something I cannot undertand. In the code it seems you will use apache httpd with mod_shib (or other alternatives) to parse saml assertion and the code inside keystone will read only the values extrapolated by the front-end server. That's correct (for icehouse development, at least). If this is the case, it is not clear to me why you need to register the IdPs, with its certificate, in keystone using the new federation API. You can filter the IdP in the server so why do you need this extra list? What is the use of the IdP list and the certificate? This reflects our original design, and it has evolved a bit from the original design to be a bit more simplified. With the additional dependency on mod_shib / mod_mellon, we are no longer implementing the certificates API, but we do still need the IdP API. The IdP API specifically allows us to track the source of an identity, and apply the correct authorization mapping (producing the project- and domain-based role assignments that OpenStack is accostomed to to) to the federated attributes coming from mod_shib / mod_mellon. The benefit is that federated identities from one source can have a different level of authorization than those identities from a different source, even if they (theoretically) had the exact same SAML assertions. The idea to distinguish the IdPs make sense but for SAML I think it is better to work with the attributes only. If the SAML is the same you may work at mod_shib level to create attributes containing the value you want so it is easier to create a new attribute in the SP having the authorisation level. In this way you can define authorisation rules using only assertion instead of mixing assertion with IdP names, with …… . I do not know if you can exploit the same approach with OpenId and/or other authentication framework. Nevertheless, it seems that I am late for icehouse so I will better analyse what you provide now and think what could be done in Juno. Cheers, Marco Is still this implementation open to discussion or the design is frozen for the icehouse release? It is certainly still open to discussion (and the implementation open to review!), but we're past feature proposal freeze; anything that would require new development (beyond what is already in review) will have to wait a few weeks for Juno. Thanks in advance, Marco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [keystone] SAML consumption Blueprints
Dear all, I am interested to the integration of SAML with keystone and I am analysing the following blueprint and its implementation: https://blueprints.launchpad.net/keystone/+spec/saml-id https://review.openstack.org/#/c/71353/ Looking at the code there is something I cannot undertand. In the code it seems you will use apache httpd with mod_shib (or other alternatives) to parse saml assertion and the code inside keystone will read only the values extrapolated by the front-end server. If this is the case, it is not clear to me why you need to register the IdPs, with its certificate, in keystone using the new federation API. You can filter the IdP in the server so why do you need this extra list? What is the use of the IdP list and the certificate? Is still this implementation open to discussion or the design is frozen for the icehouse release? Thanks in advance, Marco smime.p7s Description: S/MIME cryptographic signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] SAML consumption Blueprints
On Thu, Feb 20, 2014 at 4:18 AM, Marco Fargetta marco.farge...@ct.infn.itwrote: Dear all, I am interested to the integration of SAML with keystone and I am analysing the following blueprint and its implementation: https://blueprints.launchpad.net/keystone/+spec/saml-id https://review.openstack.org/#/c/71353/ Looking at the code there is something I cannot undertand. In the code it seems you will use apache httpd with mod_shib (or other alternatives) to parse saml assertion and the code inside keystone will read only the values extrapolated by the front-end server. That's correct (for icehouse development, at least). If this is the case, it is not clear to me why you need to register the IdPs, with its certificate, in keystone using the new federation API. You can filter the IdP in the server so why do you need this extra list? What is the use of the IdP list and the certificate? This reflects our original design, and it has evolved a bit from the original design to be a bit more simplified. With the additional dependency on mod_shib / mod_mellon, we are no longer implementing the certificates API, but we do still need the IdP API. The IdP API specifically allows us to track the source of an identity, and apply the correct authorization mapping (producing the project- and domain-based role assignments that OpenStack is accostomed to to) to the federated attributes coming from mod_shib / mod_mellon. The benefit is that federated identities from one source can have a different level of authorization than those identities from a different source, even if they (theoretically) had the exact same SAML assertions. Is still this implementation open to discussion or the design is frozen for the icehouse release? It is certainly still open to discussion (and the implementation open to review!), but we're past feature proposal freeze; anything that would require new development (beyond what is already in review) will have to wait a few weeks for Juno. Thanks in advance, Marco ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
