[openstack-dev] [keystone] Federation testing
Hi, Within the Edge Computing Group we have a few people interested in Keystone federation testing starting with general federation and moving to edge specific test cases onwards. In case you are interested in this activity, we are organizing a call for next Thursday to talk about basic testing in OpenStack including identifying tasks and volunteers to complete them. We would like to use the time to clarify questions about Keystone federation capabilities if there’s any. We are also collaborating with the OPNFV Edge Cloud project for advanced test scenarios which we will also discuss on the call. The call details are here: https://wiki.openstack.org/wiki/Edge_Computing_Group#Federation_Testing_Call Please check out the materials on this etherpad prior to the call if you plan to join: https://etherpad.openstack.org/p/ECG_Keystone_Testing Please let me know if you have any questions. Thanks and Best Regards, Ildikó __ 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
Re: [openstack-dev] [keystone federation] some questions about keystone IDP with SAML supported
Hello, On 14.10.2015 13:10, wyw wrote: hello, keystoners. please help me Here is my use case: 1. use keystone as IDP , supported with SAML Remember that Keystone is not a fully fledged Identity Provider. For instance it cannot handle WebSSO. To be even more specific it will only handle "IdP Initiated authentication workflow" and it's one of the variant SAML2 authentication work. 2. keystone integrates with LDAP 3. we use a java application as Service Provider, and to integrate it with keystone IDP. 4. we use a keystone as Service Provider, and to integrate it withe keystone IDP. Did you try that already? Did it work? The problems: in the k2k federation case, keystone service provider requests authentication info with IDP via Shibboleth ECP. Yes. Why is that a problem? K2K architecture assumes two Keystones - Keystone-IdP and Keystone-SP . Communication between them leverages on SAML2 and ECP. in the java application, we use websso to request IDP, for example： as mentioned earlier - no websso in keystone-idp. idp_sso_endpoint = http://10.111.131.83:5000/v3/OS-FEDERATION/saml2/sso but, the java redirect the sso url , it will return 404 error. so, if we want to integrate a java application with keystone IDP, should we need to support ECP in the java application? pretty much - yes! Luckily for you the reference libraries (shibboleth) are written in Java so it should be easier to integrate with your application. here is my some references: 1. http://docs.openstack.org/developer/keystone/configure_federation.html 2. http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo 3. http://docs.openstack.org/developer/keystone/extensions/federation.html https://gist.githubusercontent.com/zaccone/3c3d4c8f39a19709bcd7/raw/d938f2f9d1cf06d29a81d57c8069c291fed66cab/k2k-env.sh https://gist.githubusercontent.com/zaccone/4bbc07d215c0047738b4/raw/75295fe32df88b24576ece69994270dc4eb19a6e/k2k-ecp-client.py my keystone version is kilo help me, thanks I hope I did! :-) -- Marek Denis __ 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
Re: [openstack-dev] [keystone federation] some questions about keystone IDP with SAML supported
On 10/14/2015 07:10 AM, wyw wrote: hello, keystoners. please help me Here is my use case: 1. use keystone as IDP , supported with SAML 2. keystone integrates with LDAP 3. we use a java application as Service Provider, and to integrate it with keystone IDP. 4. we use a keystone as Service Provider, and to integrate it withe keystone IDP. Keystone is not an identity provider, or at least it's trying to get out of that business, the goal is to have keystone utilize actual IdP's instead for authentication. K2K utilizes a limited subset of the SAML profiles and workflow. Keystone is not a general purpose SAML IdP supporting Web SSO. Keystone implements those portions of various SAMLv2 profiles necessary to support federated Keystone and derive tokens from federated IdP's. Note this distinctly different than Keystone being a federated IdP. The problems: in the k2k federation case, keystone service provider requests authentication info with IDP via Shibboleth ECP. Nit, "Shibboleth ECP" is a misnomer, ECP (Enhanced Client & Proxy) is a SAMLv2 profile, a SAML profile Shibboleth happens to implement, however there other SP's and IdP's that also support ECP (e.g. mellon, Ipsilon) in the java application, we use websso to request IDP, for example： idp_sso_endpoint = http://10.111.131.83:5000/v3/OS-FEDERATION/saml2/sso but, the java redirect the sso url , it will return 404 error. so, if we want to integrate a java application with keystone IDP, should we need to support ECP in the java application? You're misapplying SAML, Keystone is not a traditional IdP, if it were your web application could use SAML HTTP-Redirect or it could also function as an ECP client, but not against Keystone. Why? Keystone is not a general purpose federated IdP. -- John __ 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
Re: [openstack-dev] [keystone federation] some questions about keystone IDP with SAML supported
On 10/14/2015 11:58 AM, Marek Denis wrote: pretty much - yes! Luckily for you the reference libraries (shibboleth) are written in Java so it should be easier to integrate with your application. Only the Shibboleth IdP is written in Java. Shibboleth the SP is written in C++. If you're trying to implement an ECP client you'll probably find more support in the C++ SP implementation libraries for what you need. Actually writing an ECP client is not difficult, you could probably cobble one together pretty easily from the standard Java libraries. An ECP client only needs to be able to parse and generate XML and communicate via HTTP. It does not need to be able to read or generate any SAML specific XML because an ECP client encapsulates the SAML in other XML (e.g. SOAP). -- John __ 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] [keystone federation] some questions about keystone IDP with SAML supported
hello, keystoners. please help me Here is my use case: 1. use keystone as IDP , supported with SAML 2. keystone integrates with LDAP 3. we use a java application as Service Provider, and to integrate it with keystone IDP. 4. we use a keystone as Service Provider, and to integrate it withe keystone IDP. The problems: in the k2k federation case, keystone service provider requests authentication info with IDP via Shibboleth ECP. in the java application, we use websso to request IDP, for example?? idp_sso_endpoint = http://10.111.131.83:5000/v3/OS-FEDERATION/saml2/sso but, the java redirect the sso url , it will return 404 error. so, if we want to integrate a java application with keystone IDP, should we need to support ECP in the java application? here is my some references: 1. http://docs.openstack.org/developer/keystone/configure_federation.html 2. http://blog.rodrigods.com/it-is-time-to-play-with-keystone-to-keystone-federation-in-kilo 3. http://docs.openstack.org/developer/keystone/extensions/federation.html https://gist.githubusercontent.com/zaccone/3c3d4c8f39a19709bcd7/raw/d938f2f9d1cf06d29a81d57c8069c291fed66cab/k2k-env.sh https://gist.githubusercontent.com/zaccone/4bbc07d215c0047738b4/raw/75295fe32df88b24576ece69994270dc4eb19a6e/k2k-ecp-client.py my keystone version is kilo help me, thanks__ 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] ?????? [keystone federation] some questions aboutkeystone IDP with SAML supported
Many Thanks! John, I agree with you. Keystone is not a general purpose federated IdP. "Web application could use SAML HTTP-Redirect or it could also function as an ECP client." Now Keystone supports token, saml2, oauth1. There is aslo a keystone plugin project try to support oauth2. But Keystone's goal is not to support Web SSO BTW, if I still want to utilize Keystone, such as token authentication and SCIM and integration with LDAP functionalities. Could I use some SAMLv2 SSO Server, such as UAA or WSO2 Identity Server , to integrate with Keystone? the case maybe like this: A Java Service Provider ==SAMLv2 SSO==>UAA/WSO2 Identity Server UAA/WSO2 Identity Server ==IDP integrate with==> Keystone ==datastore==>LDAP Certainly, A Java Service Provider ==> UAA/WSO2 Identity Server ==> LDAP maybe make sense. I means , Could we integrate any SSO Server for Keystone solution? I think it can do by implementing a java websso service, that integrated with Keystone's token auth. Although it is not a standard SAMLv2 IDP solution. Java SP ==sso==> Java WEBSSO Service(RestAPI) ==token==> Keystone(token auth/SCIM API) Thanks for more help. -- -- ??: "John Dennis";<jden...@redhat.com>; : 2015??10??15??(??) 1:05 ??: "OpenStack Development Mailing List (not for usage questions)"<openstack-dev@lists.openstack.org>; "wyw"<93425...@qq.com>; : Re: [openstack-dev] [keystone federation] some questions aboutkeystone IDP with SAML supported On 10/14/2015 07:10 AM, wyw wrote: > hello, keystoners. please help me > > Here is my use case: > 1. use keystone as IDP , supported with SAML > 2. keystone integrates with LDAP > 3. we use a java application as Service Provider, and to integrate it > with keystone IDP. > 4. we use a keystone as Service Provider, and to integrate it withe > keystone IDP. Keystone is not an identity provider, or at least it's trying to get out of that business, the goal is to have keystone utilize actual IdP's instead for authentication. K2K utilizes a limited subset of the SAML profiles and workflow. Keystone is not a general purpose SAML IdP supporting Web SSO. Keystone implements those portions of various SAMLv2 profiles necessary to support federated Keystone and derive tokens from federated IdP's. Note this distinctly different than Keystone being a federated IdP. > The problems: > in the k2k federation case, keystone service provider requests > authentication info with IDP via Shibboleth ECP. Nit, "Shibboleth ECP" is a misnomer, ECP (Enhanced Client & Proxy) is a SAMLv2 profile, a SAML profile Shibboleth happens to implement, however there other SP's and IdP's that also support ECP (e.g. mellon, Ipsilon) > in the java application, we use websso to request IDP, for example?? > idp_sso_endpoint = http://10.111.131.83:5000/v3/OS-FEDERATION/saml2/sso > but, the java redirect the sso url , it will return 404 error. > so, if we want to integrate a java application with keystone IDP, > should we need to support ECP in the java application? You're misapplying SAML, Keystone is not a traditional IdP, if it were your web application could use SAML HTTP-Redirect or it could also function as an ECP client, but not against Keystone. Why? Keystone is not a general purpose federated IdP. -- John__ 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] [keystone] federation
Hi I am testing the feasibility of federated token to access another federated resource. For this purpos, I setup three devstack kilo instances as: kilo1 (IdP) - kilo2 (SP / IdP) - kilo3 (SP) 1. get a federated scoped token for a project in kilo2. 2. using this federated token, get federated scoped token for a project in kilo3. I get 500 internal server error from kilo2. If I remove service provider in kilo2 (registered for kilo3), i can get federated scoped token. So far I know for issuing v3 token, the error is within webob python /usr/local/lib/python2.7/dist-packages/webob/dec.py while authenticating the token in /keystone/auth/controllers.py. the following link is the stack trace: http://paste.openstack.org/show/422584/ The issue is when a SP is setup to be idp as well service provider (for kilo3) in kilo2, then i get http 500 internal server error. The response unscoped token from kilo2 is the following link: http://paste.openstack.org/show/412951/ I wanted to know if somebody tested similar scenarios or had similar issues. Thanks for your response -Navid Pustchi __ 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] [Keystone] federation
Hi I am setting up three keystones to be federated, getting a federated token with a federated token. I have three devstack kilo instances as: kilo1 (IdP) - kilo2 (SP / IdP) - kilo3 (SP) 1. get a federated scoped token for a project in kilo2. 2. use this federated token and get federated scoped token for kilo3. The issue is when a SP is setup to be idp as well service provider (for kilo3) in kilo2, then i get http 500 internal server error. The responses up to the error is in the following link:http://paste.openstack.org/show/412951/ I realized if remove service provider (form kilo2) then it works fine, service provider is in line 18 of the results. Thank you Navid Pustchi __ 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
Re: [openstack-dev] [keystone][federation] Coordination for Juno
Hello, I have just tried the new specs proposal. Hope it is not too bad (maybe the text could be better but english is not my language) :) I have also included some of you involved with federations as reviewers. Cheers, Marco On Tue, May 27, 2014 at 09:15:31AM -0500, Dolph Mathews wrote: On Tue, May 27, 2014 at 8:12 AM, Marco Fargetta marco.farge...@ct.infn.itwrote: On Tue, May 27, 2014 at 07:39:01AM -0500, Dolph Mathews wrote: On Tue, May 27, 2014 at 6:30 AM, Marco Fargetta marco.farge...@ct.infn.itwrote: Hi All, • Federated Keystone and Horizon □ Completely open-ended, there isn't much an expectation that we deliver this in Juno, but it's something we should start thinking about. □ I have just registered a new blueprint for this point: https://blueprints.launchpad.net/keystone/+spec/saml-web-authn Could you have a look and let me know if it make sense for the integration with keystone before I start with the code? That's a comparable blueprint to how we've written them historically, but you're about to be bitten by a change in process (sorry!). Starting with work landing in Juno milestone 2, we're going to start requiring that design work be done using the following template: https://github.com/openstack/keystone-specs/blob/master/specs/template.rst And proposed against the release during which the work is intended to ship, for example: https://github.com/openstack/keystone-specs/tree/master/specs/juno Therefore, this means that I have to write the specs using the template you sent and submit for review, correct? Yes - the impact of your proposal (un?)fortunately happens to be a great use case for the design detail required by the new template. Poke us in #openstack-keystone if you need any help getting a formal spec up! Since we're new to this as well, I'd also suggest referencing nova's -specs repo which has a head start on keystone's (and is where we're copying the overall process from): https://github.com/openstack/nova-specs Cheers, Marco (NOTE: this is my first bp here so let me know if I miss something in the process) ___ 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 ___ 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 -- Eng. Marco Fargetta, PhD Istituto Nazionale di Fisica Nucleare (INFN) Catania, Italy EMail: marco.farge...@ct.infn.it 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][federation] Coordination for Juno
Hi All, • Federated Keystone and Horizon □ Completely open-ended, there isn't much an expectation that we deliver this in Juno, but it's something we should start thinking about. □ I have just registered a new blueprint for this point: https://blueprints.launchpad.net/keystone/+spec/saml-web-authn Could you have a look and let me know if it make sense for the integration with keystone before I start with the code? Cheers, Marco (NOTE: this is my first bp here so let me know if I miss something in the process) 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][federation] Coordination for Juno
On Tue, May 27, 2014 at 6:30 AM, Marco Fargetta marco.farge...@ct.infn.itwrote: Hi All, • Federated Keystone and Horizon □ Completely open-ended, there isn't much an expectation that we deliver this in Juno, but it's something we should start thinking about. □ I have just registered a new blueprint for this point: https://blueprints.launchpad.net/keystone/+spec/saml-web-authn Could you have a look and let me know if it make sense for the integration with keystone before I start with the code? That's a comparable blueprint to how we've written them historically, but you're about to be bitten by a change in process (sorry!). Starting with work landing in Juno milestone 2, we're going to start requiring that design work be done using the following template: https://github.com/openstack/keystone-specs/blob/master/specs/template.rst And proposed against the release during which the work is intended to ship, for example: https://github.com/openstack/keystone-specs/tree/master/specs/juno Since we're new to this as well, I'd also suggest referencing nova's -specs repo which has a head start on keystone's (and is where we're copying the overall process from): https://github.com/openstack/nova-specs Cheers, Marco (NOTE: this is my first bp here so let me know if I miss something in the process) ___ 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
Re: [openstack-dev] [keystone][federation] Coordination for Juno
On Tue, May 27, 2014 at 07:39:01AM -0500, Dolph Mathews wrote: On Tue, May 27, 2014 at 6:30 AM, Marco Fargetta marco.farge...@ct.infn.itwrote: Hi All, • Federated Keystone and Horizon □ Completely open-ended, there isn't much an expectation that we deliver this in Juno, but it's something we should start thinking about. □ I have just registered a new blueprint for this point: https://blueprints.launchpad.net/keystone/+spec/saml-web-authn Could you have a look and let me know if it make sense for the integration with keystone before I start with the code? That's a comparable blueprint to how we've written them historically, but you're about to be bitten by a change in process (sorry!). Starting with work landing in Juno milestone 2, we're going to start requiring that design work be done using the following template: https://github.com/openstack/keystone-specs/blob/master/specs/template.rst And proposed against the release during which the work is intended to ship, for example: https://github.com/openstack/keystone-specs/tree/master/specs/juno Therefore, this means that I have to write the specs using the template you sent and submit for review, correct? Since we're new to this as well, I'd also suggest referencing nova's -specs repo which has a head start on keystone's (and is where we're copying the overall process from): https://github.com/openstack/nova-specs Cheers, Marco (NOTE: this is my first bp here so let me know if I miss something in the process) ___ 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
Re: [openstack-dev] [keystone][federation] Coordination for Juno
On Tue, May 27, 2014 at 8:12 AM, Marco Fargetta marco.farge...@ct.infn.itwrote: On Tue, May 27, 2014 at 07:39:01AM -0500, Dolph Mathews wrote: On Tue, May 27, 2014 at 6:30 AM, Marco Fargetta marco.farge...@ct.infn.itwrote: Hi All, • Federated Keystone and Horizon □ Completely open-ended, there isn't much an expectation that we deliver this in Juno, but it's something we should start thinking about. □ I have just registered a new blueprint for this point: https://blueprints.launchpad.net/keystone/+spec/saml-web-authn Could you have a look and let me know if it make sense for the integration with keystone before I start with the code? That's a comparable blueprint to how we've written them historically, but you're about to be bitten by a change in process (sorry!). Starting with work landing in Juno milestone 2, we're going to start requiring that design work be done using the following template: https://github.com/openstack/keystone-specs/blob/master/specs/template.rst And proposed against the release during which the work is intended to ship, for example: https://github.com/openstack/keystone-specs/tree/master/specs/juno Therefore, this means that I have to write the specs using the template you sent and submit for review, correct? Yes - the impact of your proposal (un?)fortunately happens to be a great use case for the design detail required by the new template. Poke us in #openstack-keystone if you need any help getting a formal spec up! Since we're new to this as well, I'd also suggest referencing nova's -specs repo which has a head start on keystone's (and is where we're copying the overall process from): https://github.com/openstack/nova-specs Cheers, Marco (NOTE: this is my first bp here so let me know if I miss something in the process) ___ 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 ___ 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
[openstack-dev] [keystone][federation] Coordination for Juno
Hey Everyone, I've received a couple emails from folks interested in federation for Keystone, ranging from testing federation to fix bugs and implement blueprints. I've been keeping a list of Federation specific work items for Keystone, I've tried to attach names to some of the items that have already been started. If you're interested in helping out, find an item below and shoot me an email (cc dolphm) with details about how you can help. Keystone to Keystone Federation blueprint here: https://blueprints.launchpad.net/keystone/+spec/keystone-to-keystone-federation Lots of interested parties here, but no one has yet to post a patch about this If anyone can help implement this part, or help in crafting the API please let me know. Doc'ing this portion would be extremely important, too. Supporting different protocols OpenIDConnect support blueprint here: https://blueprints.launchpad.net/keystone/+spec/auth-plugin-openid-connect Implementation from stevemar here: https://review.openstack.org/#/c/61662/15 Reviews wanted! ABFAB protocol support Waiting on an apache module SAML Client work in keystoneclient Active patch from marekd here: https://review.openstack.org/#/c/92166/ Reviews wanted! How can we gate on federation configurations and perform real tempest tests? If anyone has *any* ideas on this, please share - the keystone team is stumped on this one. Auditing support for federated users Need a blueprint for this topic Any takers for implementation? Mapping engine enhancements Trusted Attributes blueprint here: https://blueprints.launchpad.net/keystone/+spec/trusted-attribute-issuing-policy ksiu has the API spec here: https://review.openstack.org/#/c/60489/ Bugs (brought up by others as possible optimizations) Prioritize users / groups rules Add domain support Make groups a wildcard Federated Keystone and Horizon Completely open-ended, there isn't much an expectation that we deliver this in Juno, but it's something we should start thinking about. Docs for everything! Regards, Steve Martinelli Software Developer - Openstack Keystone Core Member Phone: 1-905-413-2851 E-mail: steve...@ca.ibm.com 8200 Warden Ave Markham, ON L6G 1C7 Canada ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
